@polymorphism-tech/morph-spec 4.22.0 → 6.0.0

package/framework/skills/level-0-meta/morph-tool-usage-guide/SKILL.md

@@ -1,243 +0,0 @@
----
-name: morph-tool-usage-guide
-description: Decision flowchart and per-phase reference for selecting the right Claude Code tool (Read, Grep, Glob, Bash, Task) or MCP tool in MORPH-SPEC workflows. Use when unsure which tool to use for a given action, when choosing between native tools and MCPs, or when deciding whether to use a subagent vs direct tools.
-user-invocable: true
-allowed-tools: Read, Write, Edit, Bash, Glob, Grep
----
-
-# Tool Usage Guide for MORPH Workflows
-
-> Operational guide for selecting the correct Claude Code tools and MCP tools at each morph-spec phase. Each phase uses a distinct set of tools optimized for its goals.
->
-> **Ref:** `framework/standards/integration/mcp/mcp-tools.md` for detailed MCP examples.
-
----
-
-## Decision Flowchart
-
-```
-┌──────────────────────────────┐
-│ I need to complete an action │
-└──────────────┬───────────────┘
-               │
-               ▼
-┌───────────────────────────────────────┐
-│ Is it a SEARCH for a specific file,   │
-│ keyword, or function?                 │
-└──────┬──────────────────┬─────────────┘
-       │ YES              │ NO
-       ▼                  ▼
-  Use Glob/Grep     ┌─────────────────────────┐
-  or Read            │ Does it need STRUCTURED  │
-                     │ external data (schema,   │
-                     │ API docs, design tokens)?│
-                     └──┬──────────────┬────────┘
-                        │ YES          │ NO
-                        ▼              ▼
-                   Use MCP tool   ┌──────────────────────────────┐
-                   (+ fallback)   │ Does it involve MULTIPLE      │
-                                  │ independent specialist tasks  │
-                                  │ (domain analysis + schema,   │
-                                  │ backend + frontend tasks)?   │
-                                  └──┬───────────────┬───────────┘
-                                     │ YES           │ NO
-                                     ▼               ▼
-                              Dispatch parallel  ┌──────────────────┐
-                              Task subagents     │ Does it require   │
-                              (see below)        │ MULTI-STEP        │
-                                                 │ exploration of    │
-                                                 │ many files?       │
-                                                 └──┬──────────┬─────┘
-                                                    │ YES      │ NO
-                                                    ▼          ▼
-                                                Use Task     Do it
-                                                (subagent)   directly
-```
-
-### When to use Task subagents for agent dispatch
-
-Dispatch specialist agents as **Task subagents** when ALL conditions are met:
-- Phase is `design`, `tasks`, or `implement`
-- Feature has **2+ active specialist agents** (check `activeAgents` in state.json)
-- Work can be divided into **independent parallel tasks** with clear outputs
-
-```
-Feature with multiple active agents?
-   │
-   ├─ design phase    → Dispatch architect (complexity analysis)
-   │                    + tech leads (spec validation) — in PARALLEL
-   │
-   ├─ tasks phase     → Dispatch per-domain task planners (if spec has 50+ reqs
-   │                    OR 3+ independent domains detected)
-   │
-   └─ implement phase → Dispatch per-domain implementers when tasks.total ≥ 6
-                        AND feature spans multiple domains (backend + frontend,
-                        or backend + infra, etc.)
-```
-
-**Key principle (from real-world usage):** Define subagents by **TASK**, not by **ROLE**.
-- ✅ "Analyze this proposal for complexity and return level + blueprint" (task)
-- ✅ "Implement backend tasks T001-T005 for feature X" (task)
-- ❌ "Be an architect" (vague role assignment — poor results)
-
----
-
-## User Communication
-
-### AskUserQuestion vs. Plain Text
-
-| Situation | Tool |
-|---|---|
-| ≥2 mutually exclusive options | `AskUserQuestion` (options[]) |
-| Binary yes/no choice | `AskUserQuestion` (2 options) |
-| Plan approval | `ExitPlanMode` |
-| Explanation, progress, confirmation | Direct text |
-
-**Rule:** NEVER present multiple options as plain text. Use `AskUserQuestion` with `options[]` to ensure structured, unambiguous choices.
-
-### EnterPlanMode
-
-Use **BEFORE** starting implementation when:
-- Refactor touches ≥5 files or changes architecture
-- Estimated tasks ≥20
-- Choosing between ≥2 significantly different design approaches
-
-Do NOT use for:
-- Point fix of 1-3 files
-- User already specified detailed approach
-- Implement phase with tasks.md already approved
-
----
-
-### Parallel Read Rule (CRITICAL)
-
-Independent files = a single message with multiple Read calls.
-
-```
-# WRONG (sequential)
-Read: state.json → Read: spec.md → Read: tasks.md  # 3 round-trips
-
-# CORRECT (parallel, 1 round-trip)
-Read: state.json + Read: spec.md + Read: tasks.md
-```
-
-Criterion: if reading file B does not depend on the CONTENT of file A, read both together.
-
-**Independence examples:** spec.md ↔ decisions.md ↔ contracts.cs ↔ tasks.md (all read together when investigating a phase).
-
----
-
-## Tools Per Phase
-
-> For detailed per-phase tool tables, see `references/tools-per-phase.md`
-
-**Quick summary by phase:**
-
-| Phase | Primary MCPs | Dispatch subagents? |
-|-------|-------------|---------------------|
-| Proposal | GitHub (optional) | No |
-| UI/UX | Playwright, Context7 | No |
-| Design | Neon CLI, Context7, GitHub | Yes (architect + schema in parallel) |
-| Plan | Context7, GitHub | No |
-| Tasks | Context7, GitHub | Yes (when spec has 20+ reqs or 3+ domains) |
-| Implement | Neon CLI, Context7, Playwright, GitHub | Yes (when tasks.total ≥ 6 and 2+ domains) |
-
----
-
-## Tool Selection Rules
-
-### Claude Code Native Tools
-
-| Tool | When to Use | When NOT to Use |
-|------|-------------|-----------------|
-| **Read** | Read 1-3 specific known files | Don't use for searching |
-| **Glob** | Find files by name pattern | Don't use Bash `find` |
-| **Grep** | Search content across files | Don't use Bash `grep` or `rg` |
-| **Edit** | Modify existing files | Don't use Bash `sed` or `awk` |
-| **Write** | Create new files | Don't use Bash `echo >` or heredoc |
-| **Bash** | CLI commands, build, test, git | Don't use for file read/write/search |
-| **WebSearch** | Current external information | Don't use for local codebase info |
-| **WebFetch** | Specific URL content | Don't use for authenticated services |
-| **Task** (subagent) | Multi-file exploration, complex analysis | Don't use for single-file operations |
-
-### MCP Tools
-
-| MCP | When to Use | Fallback |
-|-----|-------------|----------|
-| **Neon CLI (`neonctl`) + `psql`** | Schema analysis, migrations, RLS | Grep + Read code files |
-| **GitHub** | Issues, PRs, repo metadata, code search | Bash `gh` CLI |
-| **Context7** | Library documentation lookups | WebSearch + WebFetch |
-| **Playwright** | Browser automation, screenshots, page inspection, smoke tests | WebFetch (read-only), Manual testing |
-| **Azure** | Cloud resource management | Bash `az` CLI |
-| **Docker** | Container management | Bash `docker` CLI |
-
-### The 3-Question Test
-
-Before choosing a tool, ask:
-
-1. **Is the data local or external?**
-   - Local → Read/Grep/Glob
-   - External structured → MCP
-   - External unstructured → WebSearch/WebFetch
-
-2. **Am I reading or writing?**
-   - Reading → Read/Grep/Glob/MCP
-   - Writing → Write/Edit/Bash (for CLI)
-
-3. **How many files are involved?**
-   - 1-3 files → Direct tools (Read, Edit, Write)
-   - 4+ files of known names → Parallel Read calls
-   - Unknown files needing exploration → Glob/Grep, then Read
-   - Complex multi-step analysis → Task subagent
-
-### Global Anti-Patterns
-
-- ❌ **WebFetch for GitHub URLs** → Use `gh api` or `gh` CLI
-  - Correct: `gh api repos/owner/repo/git/trees/main --field recursive=1`
-  - Correct: `gh pr view 123`, `gh issue view 456`
-  - WebFetch for GitHub returns HTML/redirect; `gh` uses the authenticated API
-- ❌ **Multi-option questions as plain text** → Use `AskUserQuestion` with `options[]`
-  - Correct: `AskUserQuestion({ question: "Which approach?", options: [{label: "A"}, {label: "B"}] })`
-  - Plain text creates ambiguity and requires manual response parsing
-
----
-
-## MCP Registry
-
-For the canonical list of MCPs, their tools, phase relevance, and fallbacks, see:
-
-**`framework/skills/level-0-meta/mcp-registry.json`**
-
-### Phase → MCP Quick Reference
-
-| Phase | Primary MCPs | Fallback |
-|-------|-------------|----------|
-| Proposal | Context7 | WebSearch |
-| Setup | GitHub | `gh` CLI |
-| UI/UX | Playwright, Context7 | WebFetch, Read CSS |
-| Design | Neon CLI, Context7, GitHub | Grep + Read code |
-| Tasks | Context7, GitHub | WebSearch, `gh` CLI |
-| Implement | Neon CLI, Context7, Playwright, GitHub | CLI tools |
-
-### Detected Plugins & MCPs
-
-If `morph-spec init` was run with Claude Code environment detection, check `.morph/config/integrations.json` for the detected plugins and MCPs available in this project.
-
----
-
-## Superpowers Integration
-
-When the `superpowers` plugin is installed, additional skills enhance each phase:
-
-| Phase | Superpowers Skill | Purpose |
-|-------|------------------|---------|
-| Setup | `using-git-worktrees` | Isolate feature work |
-| Design | `writing-plans`, `brainstorming` | Structure approach, explore alternatives |
-| Tasks | `writing-plans`, `executing-plans` | Plan and execute implementation |
-| Implement | `test-driven-development`, `systematic-debugging`, `requesting-code-review` | TDD, debug failures, review |
-
-See each phase skill for detailed integration instructions.
-
----
-
-*MORPH-SPEC by Polymorphism Tech*

package/framework/skills/level-0-meta/morph-tool-usage-guide/references/tools-per-phase.md

@@ -1,169 +0,0 @@
-# Tools Per Phase — Detailed Reference
-
-> Detailed tool selection tables for each MORPH-SPEC phase.
-> For the decision flowchart and selection rules, see the main `SKILL.md`.
-
----
-
-## Phase 0 — Proposal
-
-**Goal:** Understand the feature request and create proposal.md
-
-| Action | Tool | Why |
-|--------|------|-----|
-| Read project context | **Read** `.morph/context/README.md` | Single known file |
-| Read config | **Read** `.morph/config.json` | Single known file |
-| Find existing features | **Glob** `.morph/features/*/0-proposal/proposal.md` | Pattern search |
-| Detect project stack | **Read** `.morph/framework/agents.json` → match keywords → **Bash** `morph-spec state add-agent` | agents.json is the source of truth |
-| Research external requirement | **WebSearch** | Current information needed |
-| Render proposal template | **Bash** `morph-spec template render docs/proposal ...` | CLI command |
-| Update state | **Bash** `morph-spec state mark-output {feature} proposal` | CLI command |
-
-**MCPs used:** None typically. GitHub MCP if feature comes from an issue.
-
-**Anti-patterns:**
-- ❌ Task agent to read proposal template (just use Read)
-- ❌ Bash `cat` to read files (use Read tool)
-- ❌ Bash `find` to locate files (use Glob tool)
-
----
-
----
-
-## Phase 2 — UI/UX Design
-
-**Goal:** Create UI mockups, design system, component specs, user flows
-
-| Action | Tool | Why |
-|--------|------|-----|
-| Check existing design system | **Read** `.morph/context/design-system.md` | Single file |
-| Read user-provided screenshots | **Read** (image files) | Claude Code reads images natively |
-| Search for existing CSS variables | **Grep** `--root:` or `--color-` in `*.css,*.scss` | Find existing design tokens |
-| Find existing UI components | **Glob** `**/Components/**/*.razor` or `**/components/**/*.tsx` | Existing patterns |
-| Look up component library API | **Context7 MCP** `query_docs({ libraryId, query })` | Accurate component props/events |
-| Preview de página existente | **Playwright MCP** `browser_navigate()` + `browser_take_screenshot()` | **WebFetch** URL |
-| Inspecionar estrutura da página | **Playwright MCP** `browser_snapshot()` | **WebFetch** + parse manual |
-| Testar layout responsivo | **Playwright MCP** `browser_resize()` + `browser_take_screenshot()` | Manual testing |
-| Search for design references | **WebSearch** + **WebFetch** | External inspiration |
-| Render UI templates | **Bash** `morph-spec template render docs/ui-mockups ...` | CLI command |
-| Generate design system from CSS | **Bash** `morph-spec generate design-system --scan` | CLI command |
-| Update state | **Bash** `morph-spec state mark-output {feature} uiDesignSystem && morph-spec state mark-output {feature} uiMockups && morph-spec state mark-output {feature} uiComponents && morph-spec state mark-output {feature} uiFlows` | CLI command |
-
-**MCPs used:** Playwright (live preview, page inspection), Context7 (component docs).
-
-**Anti-patterns:**
-- ❌ WebSearch for MudBlazor docs (use Context7 MCP — more accurate)
-- ❌ Task agent to read a single screenshot (just use Read tool on the image)
-- ❌ Manually guessing component props (use Context7 to get real API)
-
----
-
-## Phase 3 — Design (Technical Spec)
-
-**Goal:** Analyze schema, create spec.md, contracts-level{N}.cs, decisions.md
-
-| Action | Tool | Why |
-|--------|------|-----|
-| Read proposal + UI specs | **Read** output files | Single known files |
-| **Get dispatch config** | **Bash** `morph-spec dispatch-agents {feature} design` | Which agents to spawn + their task prompts |
-| **Dispatch architecture analyst** (parallel) | **Task** subagent with prompt from dispatch config | Analyze architecture complexity independently |
-| **Dispatch tech leads** (parallel) | **Task** subagents (dotnet-senior, nextjs-expert, etc.) | Validate architecture independently |
-| Get database schema | **Bash** `pg_dump $(neonctl connection-string)` or `psql <DB_URL>` | **PREFERRED** — real schema |
-| Get table relationships | **Bash** `psql <DB_URL>` FK queries | Real FK/constraint data |
-| Get RLS policies | **Bash** `psql <DB_URL>` pg_policies query | Security analysis |
-| **Fallback:** Find query files | **Grep** `\.from\(` or `\.select\(` in `*.ts,*.tsx,*.js,*.cs` | When no DB MCP available |
-| **Fallback:** Find type definitions | **Glob** `src/**/types/**/*.ts` or `**/Entities/**/*.cs` | When no DB MCP available |
-| **Fallback:** Read query/type files | **Read** each matched file | Extract field names manually |
-| Look up library for ADR | **Context7 MCP** `query_docs()` | Compare library capabilities |
-| Check existing code patterns | **GitHub MCP** `search_code()` | Find patterns in large repos |
-| **Fallback:** Search codebase | **Grep** patterns across project | When no GitHub MCP |
-| Render contracts template (detected level) | **Bash** `morph-spec template render code/dotnet/contracts/contracts-level{N}.cs ...` where N = level detected | CLI command |
-| Render spec template | **Bash** `morph-spec template render docs/spec ...` | CLI command |
-| Render decisions template | **Bash** `morph-spec template render docs/decisions ...` | CLI command |
-| Create schema-analysis.md | **Write** to output directory | Document findings |
-| Update state | **Bash** `morph-spec state mark-output {feature} schemaAnalysis && morph-spec state mark-output {feature} spec && morph-spec state mark-output {feature} contracts && morph-spec state mark-output {feature} decisions` | CLI command |
-
-**Tools used:** Neon CLI (`neonctl`) / psql (schema analysis), Context7 (library research), GitHub (code search).
-
-**Parallel dispatch opportunity:** Architecture complexity analysis and schema analysis (phase-codebase-analysis) are **independent** — run them as parallel Task subagents to cut design phase time.
-
-**Anti-patterns:**
-- ❌ Guessing field names without checking schema (use MCP or Grep first!)
-- ❌ Task agent to read a single spec file (use Read directly)
-- ❌ WebSearch for database schema (use Neon CLI/psql or code analysis)
-- ❌ Manually writing contracts-level{N}.cs from scratch (use template render)
-- ❌ Running domain analysis and schema analysis sequentially (they're independent — run in parallel)
-
----
-
----
-
-## Phase 6 — Tasks
-
-**Goal:** Break spec into tasks, define dependencies, set checkpoints
-
-| Action | Tool | Why |
-|--------|------|-----|
-| Read spec + contracts + decisions | **Read** all output files | Full context needed |
-| **Get dispatch config** | **Bash** `morph-spec dispatch-agents {feature} tasks` | Which domain experts to consult |
-| Analyze implementation complexity | **Grep** patterns in existing code | Estimate effort from codebase size |
-| Count existing similar patterns | **Glob** `**/Services/**/*.cs` | Understand scope |
-| **Dispatch domain experts** (when spec is complex) | **Task** subagents per domain | Parallel per-domain task planning |
-| Look up implementation patterns | **Context7 MCP** `query_docs()` | Estimate task complexity accurately |
-| Create GitHub issues from tasks | **GitHub MCP** `create_issue()` | Sync tasks to project management |
-| **Fallback:** Create issues via CLI | **Bash** `gh issue create ...` | When no GitHub MCP |
-| Render tasks template | **Bash** `morph-spec template render docs/tasks ...` | CLI command |
-| Mark tasks output | **Bash** `morph-spec state mark-output {feature} tasks` | CLI command |
-| Update state with task count | **Bash** `morph-spec state set ... tasks.total N` | CLI command |
-
-**MCPs used:** Context7 (complexity estimation), GitHub (issue creation).
-
-**Anti-patterns:**
-- ❌ Task agent to break down a simple 1-domain spec (do it directly)
-- ✅ Task agent for complex multi-domain specs (backend + frontend + infra = 3 independent planners)
-- ✅ Task agent when spec has 20+ requirements across multiple bounded contexts
-- ❌ Manually writing tasks.json without reading all outputs first
-
----
-
-## Phase 7 — Implement
-
-**Goal:** Implement tasks, checkpoint every 3, create recap
-
-| Action | Tool | Why |
-|--------|------|-----|
-| Read task details | **Read** tasks.json, spec.md, contracts.cs | Implementation reference |
-| **Check parallelization viability** | **Bash** `morph-spec dispatch-agents {feature} implement` | Whether to dispatch parallel implementers |
-| **Dispatch per-domain implementers** (when viable) | **Task** subagents — one per domain group | Backend tasks + frontend tasks run in parallel |
-| Create new files | **Write** new source files | New entities, services, pages |
-| Modify existing files | **Edit** existing source files | Add features to existing code |
-| Look up API during coding | **Context7 MCP** `query_docs()` | Accurate library usage |
-| Run database migrations | **Bash** `dotnet ef database update` | DDL via psql |
-| **Fallback:** Run migrations | **Bash** `dotnet ef ...` or `psql` | CLI tools |
-| Build project | **Bash** `dotnet build` or `npm run build` | Verify compilation |
-| Run tests | **Bash** `dotnet test` or `npm test` | Verify implementation |
-| Checkpoint validation | **Bash** `morph-spec checkpoint ...` | Every 3 tasks |
-| Create RLS policies | **Bash** write SQL migration + `dotnet ef database update` | Security policies |
-| Manage containers | **Bash** `docker ps`, `docker logs`, `docker compose` | Container health + debugging |
-| Create infrastructure | **Bash** `az bicep ...` or Bicep files via Write | IaC |
-| Create PR | **GitHub MCP** `create_pull_request()` or **Bash** `gh pr create` | Ship code |
-| Mark task done | **Bash** `morph-spec task done T001` | State tracking |
-| Smoke test feature no browser | **Playwright MCP** `browser_navigate()` + `browser_snapshot()` | Manual testing |
-| Verificar erros de console | **Playwright MCP** `browser_console_messages()` | Browser DevTools |
-| Screenshot para recap.md | **Playwright MCP** `browser_take_screenshot()` | Manual screenshot |
-| Mark recap output | **Bash** `morph-spec state mark-output {feature} recap` | CLI command |
-
-**Tools used:** Neon CLI (`neonctl`) / EF Core CLI (migrations), Context7 (API lookup), GitHub (PRs), Playwright (smoke test, verification).
-
-**Parallel dispatch threshold:**
-- `tasks.total ≥ 6` AND feature spans 2+ domains (e.g. `dotnet-senior` + `nextjs-expert`) → dispatch parallel implementers
-- Each subagent gets its own task group (backend T001-T005, frontend T006-T009) with isolated file scope
-
-**Anti-patterns:**
-- ❌ Task agent for a single file edit (use Edit directly)
-- ✅ Task agent for implementing a full service layer across 5+ files
-- ✅ Task agent for each domain group when feature has 6+ tasks across multiple domains
-- ❌ Bash `cat` to create files (use Write tool)
-- ❌ Bash `sed` to modify code (use Edit tool)
-- ❌ Implementing without reading contracts.cs first (contracts are the source of truth)
-- ❌ Implementing backend and frontend tasks sequentially when they have no cross-dependencies

package/framework/skills/level-0-meta/morph-verification-before-completion/SKILL.md

@@ -1,148 +0,0 @@
----
-name: morph-verification-before-completion
-description: Phase-specific verification checklists and morph-spec validation commands for confirming MORPH-SPEC outputs are complete and correct. Use before marking any task done, before advancing to the next phase, before committing, or before creating PRs.
-user-invocable: true
-argument-hint: "[feature-name] [phase?]"
-allowed-tools: Read, Bash, Glob, Grep
----
-
-# Verification Before Completion — MORPH-SPEC Integrated
-
-> Never claim work is complete without running verification. Evidence before assertions.
->
-> **Script:** Run `node .claude/skills/morph-verification-before-completion/scripts/check-phase-outputs.mjs <feature> [phase]` to check required output files exist.
-
-## When to Use
-
-- Before marking any task as done (`morph-spec task done`)
-- Before advancing to the next phase
-- Before claiming a feature is complete
-- Before creating a PR or commit
-
----
-
-## Phase-Specific Checklists
-
-### Phase 0 — Proposal
-
-- [ ] `proposal.md` exists in `.morph/features/{feature}/0-proposal/`
-- [ ] Proposal contains: Goal, Scope, Constraints, Success Criteria
-- [ ] `morph-spec state get {feature}` shows `phase: proposal`
-- [ ] `morph-spec state mark-output {feature} proposal` was called
-
-### Phase 1 — UI/UX (if applicable)
-
-- [ ] `design-system.md` exists with color tokens, typography, spacing
-- [ ] `mockups.md` exists with wireframes/ASCII mockups
-- [ ] `morph-spec validate-feature {feature} --phase uiux` passes
-
-### Phase 2 — Design
-
-- [ ] `spec.md` contains: Overview, Functional Requirements, Technical Architecture, Data Model
-- [ ] `contracts.cs` exists with DTOs matching `schema-analysis.md`
-- [ ] `decisions.md` contains at least 1 ADR
-- [ ] Quality + satisfaction score ≥ 85 (or user finalized)
-- [ ] `morph-spec validate-feature {feature} --phase design` passes
-
-### Phase 3 — Plan
-
-- [ ] `plan.md` exists in `.morph/features/{feature}/3-plan/`
-- [ ] Plan contains: Goal, Architecture, Execution Strategy, Task Groups
-- [ ] Each task has exact file paths and complete code
-- [ ] Execution strategy defined (single / subagents / agent-teams)
-- [ ] `morph-spec state mark-output {feature} plan` was called
-- [ ] User approved plan via `morph-spec approve {feature} plan`
-
-### Phase 6 — Tasks
-
-- [ ] `tasks.md` exists
-- [ ] All tasks have: ID, title, description, dependencies
-- [ ] Checkpoints defined (every 3 tasks)
-- [ ] `morph-spec state set {feature} tasks.total N` called
-
-### Phase 7 — Implement
-
-- [ ] All tasks marked as completed
-- [ ] Build succeeds (`npm run build` or `dotnet build`)
-- [ ] Tests pass (`npm test` or `dotnet test`)
-- [ ] `recap.md` generated with implementation summary
-- [ ] `morph-spec validate-feature {feature}` passes all checks
-
----
-
-## Verification Commands
-
-```bash
-# Run full feature validation
-morph-spec validate-feature {feature-name}
-
-# Check feature state and phase
-morph-spec state get {feature-name}
-
-# Check approval gates
-morph-spec approval-status {feature-name}
-
-# Check overall project status
-morph-spec status
-```
-
----
-
-## Integration with Task Done
-
-Before running `morph-spec task done`:
-
-1. **Run the relevant test** for the task being completed
-2. **Run `morph-spec validate-feature`** if completing a checkpoint task
-3. **Read the task spec** and verify all acceptance criteria are met
-4. **Check for build errors** — run build command
-
-```bash
-# Verify before marking done
-morph-spec validate-feature {feature}
-morph-spec task done {feature} T001
-```
-
----
-
-## Integration with Checkpoints
-
-Every 3 tasks, run full checkpoint validation:
-
-```bash
-morph-spec checkpoint-save {feature}
-morph-spec validate-feature {feature}
-```
-
-If validation fails:
-1. **Do NOT mark the task as done**
-2. **Fix the issues** identified by validation
-3. **Re-run validation** until it passes
-4. **Then** mark the task as done
-
----
-
-## Integration with Superpowers
-
-> Available when the `superpowers` plugin is installed.
-
-This skill replaces `superpowers:verification-before-completion` within morph-spec workflows. It adds:
-- Phase-specific checklists (not just generic verification)
-- `morph-spec validate-feature` integration
-- Checkpoint system integration
-- State tracking verification
-
-For verification **outside** morph-spec workflows, the original `superpowers:verification-before-completion` skill remains available.
-
----
-
-## Anti-patterns
-
-- Never claim "tests pass" without actually running them
-- Never skip validation because "the change is small"
-- Never mark a task done if build is broken
-- Never advance phases without checking the phase checklist
-
----
-
-*MORPH-SPEC by Polymorphism Tech*

package/framework/skills/level-0-meta/morph-verification-before-completion/scripts/check-phase-outputs.mjs

@@ -1,110 +0,0 @@
-#!/usr/bin/env node
-/**
- * check-phase-outputs.mjs
- *
- * Verifies that required MORPH-SPEC output files exist for a feature/phase.
- * Executed locally by Claude via Bash — output is returned to Claude.
- *
- * Usage:
- *   node check-phase-outputs.mjs <feature> [phase]
- *
- * Examples:
- *   node check-phase-outputs.mjs photo-processing design
- *   node check-phase-outputs.mjs photo-processing        # checks all phases
- *
- * Output: JSON array of { phase, file, exists, required }
- */
-
-import { existsSync } from 'fs';
-import { join } from 'path';
-
-const PHASE_OUTPUTS = {
-  proposal: [
-    { file: '0-proposal/proposal.md', required: true },
-  ],
-  design: [
-    { file: '2-design/spec.md', required: true },
-    { file: '2-design/contracts.cs', required: true },
-    { file: '2-design/decisions.md', required: true },
-    { file: '2-design/schema-analysis.md', required: false },
-  ],
-  uiux: [
-    { file: '1-ui/design-system.md', required: true },
-    { file: '1-ui/mockups.md', required: true },
-    { file: '1-ui/components.md', required: true },
-    { file: '1-ui/flows.md', required: false },
-  ],
-  tasks: [
-    { file: '4-tasks/tasks.md', required: true },
-  ],
-  implement: [
-    { file: '5-implement/recap.md', required: true },
-  ],
-};
-
-const feature = process.argv[2];
-const targetPhase = process.argv[3];
-
-if (!feature) {
-  console.error(JSON.stringify({ error: 'Usage: check-phase-outputs.mjs <feature> [phase]' }));
-  process.exit(1);
-}
-
-// Walk up to find .morph/ directory
-let cwd = process.cwd();
-let morphDir = null;
-for (let i = 0; i < 5; i++) {
-  const candidate = join(cwd, '.morph');
-  if (existsSync(candidate)) {
-    morphDir = candidate;
-    break;
-  }
-  const parent = join(cwd, '..');
-  if (parent === cwd) break;
-  cwd = parent;
-}
-
-if (!morphDir) {
-  console.error(JSON.stringify({ error: '.morph/ directory not found. Run from inside a MORPH-SPEC project.' }));
-  process.exit(1);
-}
-
-const featureDir = join(morphDir, 'features', feature);
-if (!existsSync(featureDir)) {
-  console.error(JSON.stringify({ error: `Feature directory not found: .morph/features/${feature}` }));
-  process.exit(1);
-}
-
-const phases = targetPhase
-  ? { [targetPhase]: PHASE_OUTPUTS[targetPhase] }
-  : PHASE_OUTPUTS;
-
-if (targetPhase && !PHASE_OUTPUTS[targetPhase]) {
-  console.error(JSON.stringify({ error: `Unknown phase: ${targetPhase}. Valid: ${Object.keys(PHASE_OUTPUTS).join(', ')}` }));
-  process.exit(1);
-}
-
-const results = [];
-let missingRequired = 0;
-
-for (const [phase, outputs] of Object.entries(phases)) {
-  for (const { file, required } of outputs) {
-    const fullPath = join(featureDir, file);
-    const exists = existsSync(fullPath);
-    if (required && !exists) missingRequired++;
-    results.push({ phase, file, exists, required });
-  }
-}
-
-const summary = {
-  feature,
-  featureDir: featureDir.replace(/\\/g, '/'),
-  checks: results.length,
-  passed: results.filter(r => r.exists).length,
-  missingRequired,
-  ready: missingRequired === 0,
-  results,
-};
-
-console.log(JSON.stringify(summary, null, 2));
-process.exit(missingRequired > 0 ? 1 : 0);

package/framework/skills/level-1-workflows/README.md

@@ -1,7 +0,0 @@
-# Level 1: Workflows
-
-Phase orchestration and workflow management.
-
-**Purpose:** Skills that implement MORPH workflow phases (FASE 0-6).
-
-**Examples:** phase-design, phase-uiux, phase-plan, phase-implement