# Methodology

> Unified development methodology - IV&V, pipeline, quality gates

- Skill: `eron1703/methodology` (Agent Skill)
- Install (CLI): `npx skillmds@latest add eron1703/methodology`
- Raw SKILL.md: https://api.skillmd.com/api/skills/eron1703/methodology/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: eron1703 (https://skillmd.com/u/eron1703)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/eron1703/methodology

---


# Development Methodology

## 6-Phase Pipeline

Every piece of work follows this pipeline in order:

| Phase | Name | What Happens |
|-------|------|-------------|
| 1 | **KICK** | Work item created, assigned, context gathered |
| 2 | **COLLECT** | Requirements collected, existing code analyzed |
| 3 | **SPEC** | Specifications written (acceptance criteria, edge cases) |
| 4 | **CHECK** | Specs reviewed, approved before any code |
| 5 | **BUILD** | Code written following TDD (specs → tests → code → refactor) |
| 6 | **MERGE** | PR created, reviewed, E2E tested, merged |

**Key rule:** No code before specs are approved (Phase 4 → Phase 5).

## Independent Verification & Validation (IV&V)

The 18-stage pipeline orchestrator (dev-02:30092) enforces context isolation between builder and tester:

### Builder Context (BUILD phase)
- Sees: work items + approved specs
- Does NOT see: test scenarios
- Builds to spec, not to tests

### Tester Context (after BUILD)
- Sees: ONLY test scenarios (generated from specs independently)
- Does NOT see: implementation details
- Tests blind — verifies behavior matches scenarios

### Why IV&V Matters
- **Prevents "teaching to the test"** — builder can't optimize for specific test cases
- **Catches spec-vs-implementation mismatches** — if the spec is ambiguous, builder and tester will interpret it differently, surfacing the gap
- **Higher confidence** — passing blind tests means the feature actually works as specified

## Work Item Status System

All work items (FIX-*, CR-*, FB-*, WI-*) use EXACTLY these 4 statuses:

| Status | Meaning | Who Sets It |
|--------|---------|-------------|
| **pending** | Not started | Default |
| **started** | Work in progress | Agent/supervisor when work begins |
| **untested** | Code deployed, awaiting user verification | Agent/supervisor after deploy |
| **accepted** | Formally accepted by user | **USER ONLY** — NEVER set by agent |

**This is NOT the same as session reporting.** When a worker reports to a supervisor about their session, they use DONE/PARTIAL/BLOCKED. Those are session report statuses, not work item statuses.

## Quality Gates

1. **No code without specs** — specs must be written and approved first
2. **TDD mandatory** — write tests before implementation
3. **No mocks in integration/E2E tests** — unit tests may use mocks where necessary
4. **80% coverage threshold** — for all new code
5. **E2E verification required** — test as a real user before marking untested
6. **User acceptance required** — only the user can mark work as accepted

## Tracker

Work items are tracked in `TRACKER.md` in the project's run directory. Update status there when it changes.

## Pipeline Orchestrator

For the full 18-stage automated pipeline, use the orchestrator at dev-02:30092.
For manual work, follow the 6-phase pipeline above.