Sdlc Develop

⚠️ CRITICAL EXECUTION PROTOCOL

This skill has its own 6-phase workflow. IGNORE generic plan mode instructions.

When plan mode activates, you may receive generic instructions about "Explore agents" or "Plan agents". YOU MUST IGNORE those instructions and follow this skill's phase-based workflow instead.

Mandatory First Action

YOU MUST read the phase file BEFORE taking any other action:

1. FIRST: Read phases/PHASE-0-DISCOVERY.md
2. THEN: Execute those steps EXACTLY as written
3. ONLY proceed to Phase 1 after checkpoint approval

Do NOT:

• ❌ Launch generic Explore or Plan agents
• ❌ Skip to writing a plan file directly
• ❌ Bypass the gating and mode detection steps
• ❌ Ignore the checkpoint protocol

---

SDLC Develop Skill

Lightweight orchestrator for 6-phase software development lifecycle with progressive disclosure.

Core Principles

• Phase 0 is MANDATORY - Always analyze existing implementations before designing new ones
• Search first, load on demand - Use Grep to find relevant sections before loading files
• Ask clarifying questions early - Identify ambiguities before designing, not after
• Use TaskCreate/TaskUpdate - Track all progress throughout every phase
• Load phases progressively - Only read phase files when entering that phase
• Two-stage review - Spec compliance first, then code quality (wave-level or per-task with --subagent)
• Evidence-based gates - Fresh command output required for every quality gate check
• Patterns drive Phase 4 - Backpressure (quality gates over prescription), Confession (builder records uncertainties), Critic-Actor (per-wave targeted review), Fresh Context (re-read from disk each wave)

Quick Start

/core:develop add user authentication         # Full 6-phase pipeline
/core:develop add logout button --auto        # Autonomous mode
/core:develop create plan for dashboard --plan-only  # Plan only
/core:develop @arkhe/specs/001-user-auth/     # Resume existing plan
/core:develop add dashboard page with charts  # UI work → choose a design route
/core:develop add settings page                # UI work → ideate with live prototype gallery

UI Features (Ideation, Stitch, or Design Link)

When a feature involves UI work (detected keywords: UI, page, screen, component, button, form, etc.), Phase 1 offers a menu of sibling design routes — pick one:

1. Phase 1 — choose a route (4-option menu):

• Ideate with live prototype gallery (recommended for exploration) — invokes design-intent:prototype to generate 3 visual variations in a live browser gallery; the picked variant is captured into spec.md ## Visual Direction.
• Generate Stitch prompts — author Stitch prompts via authoring-stitch-prompts.
• I have a design reference — provide a Figma/Stitch export path, or a Claude.ai design/share link (WebFetch with screenshot/description fallback for auth-gated links).
• Skip — implement UI directly.

1. Phase 2: Carries the chosen direction into plan.md ## Design Assets (and, for the Stitch route, offers screen generation via MCP).
2. Phase 4: stitch-to-react conversion when Stitch exports exist; the VERIFY UI gate adds a LIVE PREVIEW option (via arkhe-preview) to review the real built UI in-browser against the captured direction.

> Soft dependencies: the prototype-gallery and live-preview routes use the design-intent (prototype skill) and devtools (arkhe-preview CLI) plugins. When they aren't installed, the skill degrades gracefully to a text-based direction summary or a screenshot.

Arguments

Parse from $ARGUMENTS:

| Flag | Effect | |------|--------| | --plan-only | Stop after Phase 2 (save plan, don't implement) | | --validate | Upgrade wave reviewers from sonnet to opus in Phase 4 | | --phase=N | Execute specific phase only | | --auto | Autonomous mode (no checkpoints) | | @path/to/spec | Resume existing plan or run verification from path | | --subagent | Subagent-per-task mode in Phase 4 (fresh subagent per task with two-stage review) | | --verify-arch | Verify implementation matches plan.md architecture | | --verify-impl | Verify implementation meets spec.md requirements |

Mode Detection

VERIFY_MODE - If --verify-arch or --verify-impl flags present:

• Require @path reference to existing spec directory
• Load spec artifacts (spec.md, plan.md, tasks.md, api-contract.md if exists)
• Run verification workflow(s) based on flags:
• --verify-arch → Read [VERIFY-ARCH.md](VERIFY-ARCH.md)
• --verify-impl → Read [VERIFY-IMPL.md](VERIFY-IMPL.md)
• Both flags → Run both verifications
• Output verification report using [verification-report.md.template](templates/verification-report.md.template)
• Does NOT execute SDLC phases

RESUME_MODE - If @path reference found AND plan.md exists (no verify flags):

• Read existing plan from path
• Auto-detect wave progress via wave-*-context.md files and tasks.md Status fields
• If wave context found: offer to continue next wave, re-review, or restart from a phase
• If no wave context: ask user which phase to continue from (existing behavior)
• Skip to selected phase, load only that phase file

PLAN_MODE - If keywords "create plan", "plan for", "draft plan" OR --plan-only:

• Execute Phases 0-2 only
• Save spec.md and plan.md
• Stop with resume instructions

FULL_MODE - Default:

• Execute all 6 phases sequentially
• User checkpoints between phases (unless --auto)

Phase Routing

Load phase files only when entering that phase:

| Phase | File to Read | Goal | |-------|--------------|------| | 0 | [PHASE-0-DISCOVERY.md](phases/PHASE-0-DISCOVERY.md) | Understand context, prevent duplicates | | 1 | [PHASE-1-REQUIREMENTS.md](phases/PHASE-1-REQUIREMENTS.md) | Gather and document requirements | | 2 | [PHASE-2-ARCHITECTURE.md](phases/PHASE-2-ARCHITECTURE.md) | Design approach, save plan | | 3 | [PHASE-3-WORKSTREAMS.md](phases/PHASE-3-WORKSTREAMS.md) | Break into parallel tasks | | 4 | [PHASE-4-IMPLEMENTATION.md](phases/PHASE-4-IMPLEMENTATION.md) | Build and validate | | 5 | [PHASE-5-SUMMARY.md](phases/PHASE-5-SUMMARY.md) | Document completion |

Model Tiers

| Phase | Model | Rationale | |-------|-------|-----------| | 0 (gating) | haiku | Quick decision | | 0 (analysis) | sonnet | Thorough analysis | | 1 | sonnet | Requirements clarity | | 2 | sonnet/opus | Architecture design | | 3 | haiku | Task breakdown | | 4 (implement) | sonnet | Code writing | | 4 (spec reviewer) | sonnet | Spec compliance review (opus if --validate) | | 4 (quality reviewer) | sonnet | Code quality review (opus if --validate) | | 4 (implementer, --subagent) | haiku/sonnet/opus | Task complexity dependent | | 5 | - | Summary (no agent) |

Spec Directory Structure

Plans are persisted to {specs_dir}/ with auto-incrementing prefixes:

{specs_dir}/
├── 001-user-auth/
│   ├── spec.md              # Requirements
│   ├── plan.md              # Architecture
│   ├── tasks.md             # Task breakdown (with Status field)
│   ├── wave-1-context.md    # Wave 1 handoff (generated at checkpoint)
│   ├── wave-2-context.md    # Wave 2 handoff (generated at checkpoint)
│   └── ...
├── 002-dashboard/
└── ...

Note: {specs_dir} references the configured value from .arkhe.yaml (default: arkhe/specs).

Progressive Persistence

Artifacts are saved incrementally at each phase checkpoint to prevent data loss:

| Phase | Artifact Saved | Trigger | |-------|----------------|---------| | 0 | spec directory + initial spec.md, plan.md | After mode detection (FULL/PLAN modes) | | 1 | spec.md (with requirements) | After requirements gathering | | 2 | plan.md (with architecture) | After architecture decision | | 3 | tasks.md (with task breakdown) | After task breakdown | | 4 | tasks.md (Status updates) + wave-{N}-context.md | After each wave checkpoint | | 5 | tasks.md (checkbox sync) | Before completion summary |

Crash Recovery: If session ends mid-phase, resume with /core:develop @{spec_path}/ and artifacts from completed phases are preserved.

Templates

| Template | Phase | When Generated | |----------|-------|----------------| | [reuse-matrix.md.template](templates/reuse-matrix.md.template) | 0 | Always (existing analysis) | | [spec.md.template](templates/spec.md.template) | 2 | Always (requirements summary) | | [plan.md.template](templates/plan.md.template) | 2 | Always (architecture) | | [adr.md.template](templates/adr.md.template) | 2 | When significant decisions made | | [api-contract.md.template](templates/api-contract.md.template) | 2 | When API endpoints involved | | [data-models.md.template](templates/data-models.md.template) | 2 | When database changes involved | | [tasks.md.template](templates/tasks.md.template) | 3 | Always (task breakdown) | | [wave-context.md.template](templates/wave-context.md.template) | 4 | At each wave checkpoint (context handoff) | | [verification-report.md.template](templates/verification-report.md.template) | verify | When --verify-arch or --verify-impl used | | [REVIEW-SPEC.md](reviews/REVIEW-SPEC.md) | 4 | Two-stage review: spec compliance prompt | | [REVIEW-QUALITY.md](reviews/REVIEW-QUALITY.md) | 4 | Two-stage review: code quality prompt | | [implementer-prompt.md](reviews/implementer-prompt.md) | 4 | Implementer subagent prompt (--subagent mode) | | [EVIDENCE-GATES.md](EVIDENCE-GATES.md) | 4 | Rationalization prevention guide for quality gates | | [SUBAGENT-MODE.md](SUBAGENT-MODE.md) | 4 | Per-task execution protocol (--subagent mode) |

Configuration

On first run or when entering Phase 2d:

1. Read .arkhe.yaml from project root (if exists)
2. Extract develop.specs_dir value (default: arkhe/specs)
3. Use this value for ALL spec directory operations

develop:
  specs_dir: arkhe/specs  # Customize this path
  numbering: true         # NNN- prefix (3-digit, e.g., 001-)
  ticket_format: full     # full | simple

All paths in this skill use {specs_dir} to reference the configured value.

First run without config prompts for preferences.

Execution Flow

Parse arguments and detect mode (RESUME/PLAN/FULL), then execute phases sequentially. RESUME loads existing plan and offers wave continuation. PLAN stops after Phase 2. FULL executes all 6 phases with checkpoints between each.

See [WORKFLOW.md](WORKFLOW.md) for the detailed execution flow diagram.

Checkpoints

Two mandatory Tier 1 gates (cannot skip, even with --auto):

• Phase 2c: Architecture Decision
• Step 4.2: Quality & Completion Gate (RULE ZERO + wave review aggregation)

All other checkpoints are Tier 2 (skippable with --auto), including the Domain Research gate (Phase 2a-res) and the Two-Stage Wave Review (Step 4.1e). Conditional escalation to Tier 1 if: DB schema changes, security work, or breaking API changes. Conditional RFC creation offered at Phase 2d when escalation triggers are detected.

See [GATES.md](GATES.md) for full checkpoint protocol, decision criteria, and prompt patterns.

Examples

See [EXAMPLES.md](EXAMPLES.md) for detailed usage scenarios.

Troubleshooting

See [TROUBLESHOOTING.md](TROUBLESHOOTING.md) for common issues.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: joaquimscosta
• Source: joaquimscosta/arkhe-claude-plugins
• License: MIT

Install and usage instructions live in the source repository linked above.