Core

Software development lifecycle (SDLC)

Full development lifecycle from idea to production. 8 phases, complexity-driven process, quality gates.

Software development lifecycle (SDLC)

Purpose: Defines how work flows from idea to production across eight lifecycle phases. Covers issue capture, design depth by complexity, build/verify/review workflow, and deployment.

How work flows from idea to production.

Quick reference:

8 phases — Discovery → Strategy & Design → Foundation → Build → Harden → Ship → Launch → Operate (3 active, 5 planned)

Pipeline commands — /new (capture) → /go (execute) → /approve (merge or graduate) → /batch (multi-issue)

Trust gradient — type × complexity → auto / confirm-brief / confirm-pr / confirm-both

Design depth — Scales with complexity: none (trivial) → brief (standard) → brief + prototype + tech spec (complex)

Build — Implement → verify (pnpm type-check && pnpm lint && pnpm test:run && pnpm build) → PR → Claude Code review → merge

Ship — Push → preview deploy → test → merge to main → verify main preview → promote to production

Status mapping — See linear-lifecycle.md for transitions

Pipeline commands

Four commands orchestrate the full development lifecycle. Each is a standalone slash command that delegates to sub-agents through defined steps.

`/new` — Issue capture

Creates a fully-enriched Linear issue in a single shot.

Flow:

Collect title, type, estimate from user (or prompt interactively)
Generate structured description (Summary, Acceptance Criteria, Scope)
Process any attached media URLs via process-media
Delegate to create-enriched-issue (which calls validate-issue internally)
Output identifier, URL, type, estimate, complexity

Usage: /new "add retry logic to webhook handler" or /new (interactive)

Issue lands in Backlog. Run /go to start work immediately or move to To-Do to schedule later.

`/go` — Work execution

11-step pipeline that takes a single Linear issue from Backlog to Done.

Steps: VALIDATE → ROUTE → BRANCH → DESIGN → BUILD → SHIP → CI-POLL → GATE → MERGE → VERIFY DONE → LOG

Flow summary:

Validates the issue (calls validate-issue)
Routes: planning issues → stop with /approve suggestion; spikes → stop with investigation guidance; code issues → continue
Creates branch, derives trust level, moves issue to In Design
Designs per complexity (trivial = skip, standard = brief, complex = brief + prototype + tech spec)
Implements via engineer sub-agent, runs review matrix (see Phase 4 Build: Review matrix)
Commits, pushes, opens PR
Polls CI checks
Gates on PR review (if trust level requires it)
Merges, verifies merge landed
Verifies issue moves to Done
Logs telemetry to activity-log.json

Usage: /go ORC-455

For multiple issues, use /batch instead.

`/approve` — Merge gate and planning graduation

Type-routed approval. Detects the issue type and routes to the appropriate flow.

Code issues (bug, feature, chore, docs): Merge gate — review PR summary, verify CI, squash merge, verify deployment, confirm Done.

Planning issues (type=planning): Graduation flow:

Parse issue description headings as phases
Present phases with inferred types/estimates for interactive reorder
Create enriched sub-issues via create-enriched-issue (sequential, not parallel)
Chain blocking relations (issue N blocks issue N+1)
Mark parent planning issue Done
Suggest /batch for executing the sub-issues

Usage: /approve ORC-455 (or auto-detects from current branch)

`/batch` — Multi-issue execution

Execution planner for 2+ Linear issues. Reads blocking relations, builds a dependency graph, and generates a shell script that runs each issue in the correct order via fresh claude sessions.

Flow:

Fetch all issues and their blocking relations
Build wave groups (Wave 1: no blockers, Wave N: blockers all in prior waves)
Sort within each wave by priority, then complexity ascending, then estimate ascending
Present execution plan for user approval
Generate shell script: parallel claude --dangerously-skip-permissions calls within a wave, sequential between waves
Execute or output script based on user choice

Usage: /batch ORC-481 ORC-482 ORC-483

Parallel issues each get a fresh claude session (isolated context window). This is the safe path for parallel execution.

Planning issue lifecycle

Planning issues follow a distinct flow from code issues. They produce decisions, specs, or research — not code.

/new (type=planning)  →  Triage  →  In Design  →  /approve (graduation)  →  Done
                                                         |
                                                         v
                                                   sub-issues created
                                                         |
                                                         v
                                                   /batch to execute

Key rules:

Planning issues skip the Build phase entirely (no In Process, no In Review, no Preview Testing)
/go detects a planning issue in Step 2 (ROUTE) and stops, directing the user to /approve
/approve graduates the plan into enriched sub-issues via create-enriched-issue
Sub-issues are chained with blocking relations so dependency order is explicit
After graduation, run /batch on the sub-issues to execute them in order

Trust gradient

Trust level is derived from issue type × complexity. It controls how much human review happens before merge. Derived automatically by /go in Step 3 (BRANCH) — not user-configurable.

Type	Trivial	Standard	Complex
`chore`	auto	auto	auto
`bug`	auto	auto	confirm-pr
`docs`	auto	auto	confirm-pr
`feature`	auto	confirm-brief	confirm-both

Trust levels:

Level	Human gate in `/go`	Effect
`auto`	None	Pipeline runs end-to-end without pausing
`confirm-brief`	After DESIGN (Step 4c)	User approves the brief before implementation
`confirm-pr`	After CI passes (Step 8)	User reviews PR diff before merge
`confirm-both`	After DESIGN + after CI	User approves brief and reviews PR diff

/approve is the manual merge gate for confirm-pr and confirm-both issues — it can also be called standalone outside the /go pipeline.

Shared functions

Three shared functions are called internally by the pipeline commands. They are not user-facing commands — they are procedures invoked by /new, /go, and /approve.

`validate-issue` — Issue normalization

Validates and normalizes a Linear issue to meet Definition of Ready (DoR). Called by /go at VALIDATE (Step 1) and by create-enriched-issue after every new issue is created.

What it does (V1–V8):

Reads .linear.json for label UUIDs and team config
Fetches the issue from Linear
Infers and applies type label if missing (from title prefix or default feature)
Defaults estimate to M / 3pts if null
Derives and applies complexity label (from type × estimate table)
Validates description structure (Summary, Acceptance Criteria, Scope headings); auto-heals if missing
Applies monochrome prefix to title if missing (★, ✕, ⚙, ☰, ◎, ↯)
Checks assignee and project are set; applies awaiting-input label and stops if either is null

Called by: /go Step 1, create-enriched-issue Step E3

`create-enriched-issue` — Issue creation with enrichment

Creates a Linear issue with full enrichment: wraps create-issue.sh, runs validate-issue, validates DoR, and posts a Prep Summary comment.

What it does (E1–E7):

Reads .linear.json
Calls create-issue.sh with title, description, type, estimate
Runs validate-issue (V1–V8) against the new issue
Posts a Prep Summary comment (9/9 DoR checklist)
Links as sub-issue (if parent_id provided)
Applies extra labels (if provided)
Returns identifier, url, id to the caller

Called by: /new Phase 2, /go Step 5e (new findings), /approve Planning Graduation G3

`process-media` — Media URL processing

Detects and processes media URLs (video, image, Linear attachment) into structured output.

What it does (M1–M3):

Detects URL type: video (YouTube, Vimeo, Loom, yt-dlp-compatible), image (.png/.jpg/etc), or Linear attachment (uploads.linear.app)
Processes by type: video via process_video.sh → transcript + keyframes; image via curl → file path; Linear attachment via curl with auth → file path
Returns structured output: type, content (transcript/path), metadata

Called by: /new Step 7 (if media URL in args), /go before Step 4 DESIGN (scans issue description)

The eight phases

Three phases are active — used on every project. Five are planned — stubs that activate when the corresponding lifecycle stage begins.

[DISCOVERY]  ->  STRATEGY &   ->  [FOUNDATION]  ->  BUILD  ->  [HARDEN]  ->  SHIP  ->  [LAUNCH]  ->  [OPERATE]
 Planned          DESIGN            Planned          Active    Planned      Active    Planned       Planned
                  Active

See standards/core/linear-lifecycle.md for the phase-to-status mapping and transition rules.

Phase 1 (planned): Discovery

Status: Planned — not yet active Activate when: A new product idea needs market validation before committing to build. Departments: CPO (Product), Strategy Planned phase -- playbook will be created when this phase activates.

Purpose: Validate market opportunity before committing engineering resources.

Key activities:

User interviews — Surveys and direct conversations
Competitive analysis
Market sizing
Problem-solution fit — Hypothesis formulation
Go/no-go decision — With documented rationale

Quality gate: Documented go/no-go decision with evidence. If "go," output feeds Phase 2 as a discovery brief.

Phase 2: Strategy & design

Status: Active — runs on every project

Purpose: Capture, triage, and validate approach before writing code.

Issue capture and triage

Every task starts as a Linear issue.

Capture immediately — Create a Linear issue
Apply type label — type: feature, type: bug, type: chore, type: docs, type: planning
Triage state — Issue goes to Triage

Weekly ritual: Triage (15 min) — Every Monday, review Triage:

Decision	Action
Promote	Worth doing -> Set priority -> Move to Backlog
Kill	Not worth it -> Cancel with note
Clarify	Need more info -> Add questions -> Keep in Triage

Rule: When in doubt, create an issue. Over-capturing is better than losing context.

Design

Decision tree

                    What kind of work?
                          |
          +---------------+---------------+
          v               v               v
     UI Feature      API Change       Complex Feature
          |               |               |
          v               v               v
    Full Agent      Standard CRUD?    Multi-file?
    Workflow             |            Architectural?
    (includes       +----+----+            |
    prototype)      v         v            v
          |       Yes: Skip  No: Plan  Full Agent Workflow
          |       Design     Required   Plan -> Tech -> Issue
          v
   Plan -> Prototype
   -> Tech -> Issue

Agent workflow (for complex work)

Team / Agent	Purpose	Output
Plan agent	Gather requirements & define problem	`docs/specs/[id]-brief.md`
Prototype + Tech agents (sequential)	Design & validate UX + architecture	Prototype + `docs/specs/[id]-tech.md`
Issue agent	Break into issues	Linear issues + dependency graph
Orchestrator / Engineer agent	Implement	Production code
Claude Code Review	Async PR review (GitHub Action)	Formal review on PR

Human checkpoint: After Plan (brief) for complex features.

Phase 0: Manual setup

New projects require Phase 0 issues for manual infrastructure setup (databases, auth providers, API credentials, env config) before development begins. Phase 0 issues must include step-by-step instructions, exact env vars, and acceptance criteria. Development issues (Phase 1+) are blocked until Phase 0 is complete.

Use /new to create Phase 0 issues with proper type labels, estimates, and structured descriptions.

Design depth by complexity

All work follows the full pipeline. Design depth scales with complexity, but no phases are skipped. Complexity is determined by the issue's Complexity label (trivial, standard, complex) — see standards/core/linear-lifecycle.md § Labels for the auto-derivation heuristic.

Complexity Label	Design Depth	Diagram	Pipeline Behavior
trivial	No design — proceed to BUILD	None	Skip DESIGN phase, skip BUILD review agents
standard	Brief in issue comment, 1 reviewer	Recommended	Standard pipeline
complex	Brief + prototype (if UI) + tech spec + issues, 3-reviewer convergence	Required	Full agent workflow

Planning issues (Type: planning): Simplified flow: Triage → In Design → Done. No In Process, no In Review, no Preview Testing — these issues produce decisions, specs, or research but no code. Always auto-derives to trivial complexity.

Secondary guidance (file-count heuristic): When no Complexity label is set and auto-derivation cannot run (missing Type or estimate), use file count as a fallback: 1-2 files = trivial, 3-5 files = standard, 6+ files = complex.

Design artifacts

Issue-first principle: The Linear issue is the permanent record of all decisions, plans, and history. Design artifacts default to Linear issue comments. Spec files (docs/specs/) are only created when the artifact exceeds ~200 lines, multiple issues share a spec, or the content renders poorly in Linear.

Complexity Label	Required Artifacts
trivial	None -- proceed to BUILD
standard	Brief plan in issue comment + solution diagram (recommended)
complex	Full agent workflow — brief + tech spec in issue comments (or `docs/specs/` if >200 lines) + Prototype (if UI) + solution diagram (required)
planning (Type label)	Decisions, specs, or research in issue comments or `docs/specs/` -- no code, no BUILD phase

UI mockups (required for UI work)

Any issue that touches UI must include a visual mockup posted to the Linear issue before implementation begins, unless the issue owner explicitly says to skip it. This applies to all complexity levels -- even simple UI changes benefit from a screenshot showing the proposed design.

Workflow:

Create mockup — HTML file in .mockups/ or modify the app directly
Screenshot — Capture via Playwright MCP
Upload — Image to Supabase storage (see standards/reference/project-management.md § "Image Assets in Linear")
Post for review — Image + design rationale as a Linear comment, tagging the issue owner
Wait for approval — Before moving to BUILD

Why: Visual review catches layout, spacing, and interaction issues that text descriptions miss. A 5-minute mockup prevents hours of rework.

Phase 3 (planned): Foundation

Status: Planned — not yet active Activate when: A greenfield project needs infrastructure provisioned before development begins. Departments: CTO (Engineering, DevOps), COO (PM) Planned phase -- playbook will be created when this phase activates.

Purpose: Stand up all infrastructure before the first line of feature code.

Key activities:

CI/CD pipeline — GitHub Actions setup
Database — Provisioning and migration tooling
Auth provider — Clerk setup
Environment config — Dev/staging/prod
Deployment pipeline — Vercel
Seed data — Local dev tooling

Quality gate: Development environment runs cleanly (pnpm dev → no errors). CI pipeline green. All env vars documented.

[!NOTE] Currently handled as "Phase 0 manual setup" in this SDLC. When formalized, this phase replaces that manual process.

Phase 4: Build

Status: Active — runs on every project

Purpose: Execute the plan with AI assistance, verify before shipping.

Workflow

Orchestrator implements directly (or via engineer agent), then pushes a PR for async Claude Code review.

Summary: Orchestrator implements (directly or via engineer agent) (TDD) → runs verification → pushes PR → Claude Code reviews async (formal GitHub review) → auto-fix loop → merge when approved.

Key rules:

Local verification — Run before pushing (pnpm type-check && pnpm lint && pnpm test:run && pnpm build)
Address all findings — Fix or reply with rationale before merging. Admins can dismiss reviews.
Branch naming — Follow conventions in standards/reference/project-management.md

External service failures

If an external service (MCP, API, database) fails 3 consecutive times, pause with awaiting-input label and report the failure. Do not retry indefinitely or work around the failure silently.

Scope changes during implementation

A scope change occurs when implementation discovers work not anticipated by the spec. These triggers require pausing to update the plan:

Unlisted files — Modifying files not listed in the tech spec's file changes
New dependencies — Introducing dependencies not in the spec
Architectural changes — Discovering the approach requires them
Unmet criteria — Finding that acceptance criteria cannot be met as specified

For small scope additions (< 15 min work), document in the implementation summary and proceed. For larger scope changes, add awaiting-input label and propose the change to the human.

Sequential execution protocol

For a single issue, use /go. For multiple issues, use /batch.

Single issue (/go):

/go runs the 11-step pipeline for one issue at a time. It always follows this exact sequence:

Start from latest main (git pull)
Create branch (git checkout -b feat/<id-slug>)
Implement → verify → commit → push → open PR
Merge PR (gh pr merge --squash --delete-branch) — wait for merge confirmation
Verify merge landed (gh pr view --json state)
Switch back to main (git checkout main && git pull)

Multiple issues (/batch):

/batch reads blocking relations across issues, builds a dependency wave graph, and generates a shell script that executes each issue in the correct order. Each issue gets its own fresh claude session.

Cross-wave execution: Always sequential. Wave N must complete before Wave N+1 starts.
Within-wave execution: Parallel when issues are in the same wave (no shared blockers). Each parallel session runs in an isolated git worktree.
Default is sequential. Speed comes from good issue breakdown and clean dependency graphs, not from forcing parallelism.

When parallel is safe (within /batch waves):

Condition	Safe
No shared files between issues	Yes
Issues touch completely different domains	Yes
Different repositories	Yes
Read-only operations (reviews, research, planning)	Yes
Issues share files or have overlapping scope	No — keep sequential

/batch handles the wave-grouping automatically using blocking relations from Linear. If no blocking relations exist, all issues land in Wave 1 and run in parallel.

Conflict re-review: Any issue that required manual merge conflict resolution must re-enter In Review before merging. Conflict resolution can silently drop security-critical code.

Review matrix

Pre-merge review agents are selected by complexity × work type. Invoked in parallel where multiple reviewers are listed. Applied during /go Step 5c.

Complexity	Backend	UI	Docs/Standards
Trivial	None	None	None
Standard	Critic	Critic + Standards	Standards
Complex	Critic + Standards + Security (parallel)	Critic + Standards + Security (parallel)	Standards + Simplifier (parallel)

Reviewer agents:

Agent	Model	Role
Critic	sonnet	Code quality, logic, architecture correctness
Standards	haiku	Standards compliance, drift detection
Security	opus	Threat modeling, auth, injection, RLS
Simplifier	haiku	Scope creep, over-engineering checks

For parallel reviewer invocations: all agents receive the same implementation output simultaneously. Findings are collected and applied before re-running verification.

Standards enforcement

Level	How
Implementation	`CLAUDE.md` instructions, TypeScript strict mode, ESLint
Verification	`pnpm type-check && pnpm lint && pnpm test:run && pnpm build`
Review	Claude Code async on PR (security, quality, standards via `review-protocol.md`)

Phase 5 (planned): Harden

Status: Planned — not yet active Activate when: A feature is production-bound and needs a formal quality/security gate. Departments: CTO (Security, QA & Testing) Planned phase -- playbook will be created when this phase activates.

Purpose: Catch security vulnerabilities, performance regressions, and accessibility failures before shipping to users.

Key activities:

Security audit — OWASP, auth, injection, RLS policies
Performance benchmarking — Core Web Vitals, API latency
Accessibility audit — WCAG 2.1 AA
Load testing — Expected peak traffic
Penetration testing — For high-value targets

Quality gate: All Critical and High findings fixed. Performance within SLA. Accessibility score ≥ AA. Signed off by Security Engineer and Reality Checker.

Phase 6: Ship

Status: Active — runs on every project

Purpose: Get code to production safely.

Pull request flow

Push to Feature Branch -> Create PR
  |                        |
  v                        v
CI Runs Automatically    Vercel Deploys Preview
  |                        |
  v                        v
Claude Code Reviews     Test on Preview
  |
  v
Address Findings -> Merge to main -> Vercel Deploys to Preview (main branch)
                                            |
                                            v
                                    Test on Preview -> Promote to Production
                                                      (Vercel dashboard, manual step)

For deployment details, rollback procedures, and database migration patterns, see standards/reference/environments.md.

Phase 7 (planned): Launch

Status: Planned — not yet active Activate when: A product is ready to go to market and needs marketing and sales activation. Departments: CMO (Content, China, Paid Media), CRO (Sales) Planned phase -- playbook will be created when this phase activates.

Purpose: Drive awareness, acquisition, and initial revenue for a newly shipped product.

Key activities:

Launch announcement — Blog, social, press
Paid media — Campaign activation
SEO — App store optimization
Sales outreach — Pipeline generation
Partnerships — Influencer activation
China market — Launch if applicable

Quality gate: Launch KPIs defined and tracking in place. First 30-day acquisition targets set. Sales team enabled with pitch materials.

Phase 8 (planned): Operate

Status: Planned — not yet active Activate when: A product is live with paying users and needs continuous monitoring and improvement. Departments: COO (Support & Ops), CTO (Infra) Planned phase -- playbook will be created when this phase activates.

Purpose: Measure, learn, and continuously improve a live product.

Key activities:

Production monitoring — Sentry, Axiom, uptime
Customer support — Operations
Analytics review — Insight generation
Incident response — Post-mortems
Continuous improvement — PostHog → Linear issues

Quality gate: SLA defined and monitored. Incident response runbook in place. Support queue response time within target. Weekly analytics review ritual established.

Implementation reference

When Phase 8 activates, configure PostHog (analytics), Sentry (errors), and Axiom (logging) per their official documentation and the framework's Locked Decisions. Detailed setup patterns, dashboard templates, and weekly review rituals are archived in docs/plans/archive/phase8-operate-examples.md.

Issue scoping

When a standards or documentation requirement touches multiple files or areas, decide upfront whether to create one issue or several. (This guidance applies to standards and docs changes; code PRs follow separate size norms.)

Decision heuristic:

Condition	Action
All changes serve the same criterion AND total ≤ 50 changed lines AND touch ≤ 5 files	Single issue — one branch, one PR, one review cycle
Changes serve different concepts OR touch different subsystems with independent review needs	Multiple issues — one per concept or subsystem
Same concept but > 50 lines or > 5 files	Judgment call — default to splitting; bias toward smaller PRs

If splitting: link issues via Linear's "relatedTo" field and reference sibling issues in each description so reviewers have full context.

Case study — Nav registration (RAJ-291–294): The requirement "user-reachable pages must be registered in nav" touched 4 files across milestone-planning.md and linear-lifecycle.md (rules) plus two cross-reference additions. All changes served the same criterion, totaling ~15 lines across 4 files. Under the heuristic this was a single-issue scope; 4 separate issues and 4 review cycles added unnecessary overhead. Lesson: cross-references to the same standard should be bundled into the issue that introduces the rule.

Exceptions: Security-critical multi-file changes may warrant splitting when each file needs independent security review. Cross-repo changes always require separate issues (different branches, different CI).

Linear integration

Only the orchestrator (main session) interacts with Linear directly. Delegated agents receive issue context via their Agent tool prompt. The orchestrator posts all Linear comments and status changes.

Status mapping

Issues use the same 10 statuses in every phase. Lifecycle phases are tracked as Linear Project statuses (not issue statuses). See standards/core/linear-lifecycle.md for statuses and transitions.

For branch naming, issue formatting, and automation, see standards/reference/project-management.md.

Worked example: complex feature

User says: "Build a member settings page" (Linear issue RAJ-300).

Assess — UI feature, new page + API routes + database changes = complex (6+ files). Full workflow.
Move to In Design.
Plan — Invoke Agent (agent: .claude/agents/planner.md) with issue description. Agent returns a brief -- problem statement, scope, acceptance criteria. Post brief as Linear comment.
Checkpoint — Tag @Ameet on Linear comment for brief approval. Apply awaiting-input label. Wait.
Mockup — This is a new page with clear interaction patterns -- mockup (not full prototype). Invoke Agent (agent: .claude/agents/engineering-frontend-developer.md) to create HTML mockup. Screenshot via Playwright, upload to Supabase, post to Linear. Tag @Ameet for approval.
Tech spec — Invoke Agent (agent: .claude/agents/engineering-backend-architect.md) with approved brief + mockup. Agent returns architecture, file changes, data model, Mermaid diagram. Post as Linear comment.
Move to In Process.
Implement — Invoke Agent (agent: .claude/agents/engineering-senior-developer.md) with tech spec + acceptance criteria. Agent writes code with TDD, runs verification. Or implement directly if simpler.
Verify — Run pnpm type-check && pnpm lint && pnpm test:run && pnpm build. Fix failures.
Move to In Review. Push PR.
GitHub Action reviews. Address findings (fix or reply with rationale).
Move to Preview Testing. Merge PR.
Verify merge landed — git log origin/main --oneline -1. Verify preview deployment.
Move to Done.

For simple tasks, skip steps 3-6 and go straight from assess to implement.

Related standards

standards/core/review-protocol.md -- Review protocol
standards/core/epic-milestones.md -- Epic and milestone implementation
standards/core/linear-lifecycle.md -- Linear status definitions and SDLC mapping
standards/reference/project-management.md -- Linear setup, branch naming, issue formatting
standards/reference/environments.md -- Deployment, secrets, environments
standards/core/testing.md -- Test standards
CLAUDE.md § "Agent Delegation" -- Agent delegation rules and patterns
.claude/skills/agent-delegation/SKILL.md -- Delegation pattern details
.claude/commands/go.md -- Full /go pipeline specification (11 steps)
.claude/commands/new.md -- Full /new issue creation specification
.claude/commands/approve.md -- Full /approve merge gate and graduation specification
.claude/commands/batch.md -- Full /batch multi-issue execution specification
.claude/skills/validate-issue/SKILL.md -- validate-issue shared function (V1–V8)
.claude/skills/create-enriched-issue/SKILL.md -- create-enriched-issue shared function (E1–E7)
.claude/skills/process-media/SKILL.md -- process-media shared function (M1–M3)

Framework SDLC v13.0 -- March 2026

Software development lifecycle (SDLC)

Software development lifecycle (SDLC)

Pipeline commands

/new — Issue capture

/go — Work execution

/approve — Merge gate and planning graduation

/batch — Multi-issue execution

Planning issue lifecycle

Trust gradient

Shared functions

validate-issue — Issue normalization

create-enriched-issue — Issue creation with enrichment

process-media — Media URL processing

The eight phases

Phase 1 (planned): Discovery

Phase 2: Strategy & design

Issue capture and triage

Design

Decision tree

Agent workflow (for complex work)

Phase 0: Manual setup

Design depth by complexity

Design artifacts

UI mockups (required for UI work)

Phase 3 (planned): Foundation

Phase 4: Build

Workflow

External service failures

Scope changes during implementation

Sequential execution protocol

Review matrix

Standards enforcement

Phase 5 (planned): Harden

Phase 6: Ship

Pull request flow

Phase 7 (planned): Launch

Phase 8 (planned): Operate

Implementation reference

Issue scoping

Linear integration

Status mapping

Worked example: complex feature

Related standards

Search Framework Explorer

`/new` — Issue capture

`/go` — Work execution

`/approve` — Merge gate and planning graduation

`/batch` — Multi-issue execution

`validate-issue` — Issue normalization

`create-enriched-issue` — Issue creation with enrichment

`process-media` — Media URL processing