# Process

> Orchestrate the end-to-end development workflow with autonomous quality gates. Use when users ask to implement/run workflow phases, start or continue development, handle review/QA findings, or process actionable comments by routing through create-work-items -> plan-work-items -> run-work-items. Enforces TDD by default for implementation work and only pauses for genuine decisions.

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

---


# Development Process

**AUTONOMOUS EXECUTION.** This process runs automatically. It only pauses when human input is genuinely required.

## Triggering

Use this skill when the request needs end-to-end orchestration of tracked development work.

Use this skill when prompts include:
- start, continue, or run development workflow phases
- implement/fix work that should be tracked and executed with gates
- handle actionable findings/comments from review, PR feedback, QA, regressions, or defect reports
- execute non-preemptive create -> plan -> run flow without manual per-skill invocation

Do not use this skill for:
- explanation-only prompts with no implementation or workflow action
- status-only prompts that only request reporting without execution
- isolated one-off questions unrelated to tracked development work

## Acceptance Tests

| Test ID | Type | Prompt / Condition | Expected Result |
| --- | --- | --- | --- |
| PRC-T1 | Positive trigger | "Address these 6 PR review comments end-to-end." | skill triggers |
| PRC-T2 | Positive trigger | "Start work on this bug and follow the workflow." | skill triggers |
| PRC-T3 | Negative trigger | "Explain why this check failed." | skill does not trigger |
| PRC-T4 | Negative trigger | "Show backlog summary only." | skill does not trigger |
| PRC-T5 | Behavior | skill triggered for actionable findings/comments | routes through create-work-items -> plan-work-items -> run-work-items using configured pipeline mode and non-preemptive WIP lock |
| PRC-T6 | Behavior | missing `autonomy.system_level` in user `ica.config.json` | asks user, persists `autonomy.system_level`, then proceeds |
| PRC-T7 | Behavior | missing `autonomy.project_level` in project `ica.config.json` | asks user, persists `autonomy.project_level`, then proceeds |
| PRC-T8 | Behavior | project autonomy is `follow-system` | resolves effective autonomy from system level and applies it to create/plan/run confirmation behavior |
| PRC-T9 | Behavior | workflow cycle starts with no new findings | still invokes `create-work-items` + `plan-work-items` in normalize/no-op mode before `run-work-items` |
| PRC-T10 | Behavior | any actionable-work orchestration cycle executes | all three skills (`create-work-items`, `plan-work-items`, `run-work-items`) are involved and recorded; missing one fails closed |

## Canonical Actionable Findings Definition

Treat these as actionable findings/comments:
- review findings
- PR comments requesting code/documentation changes
- QA findings
- regressions
- explicit defect reports

Do not create or run work for non-actionable commentary (questions, explanations, praise, status updates).

## Branch Workflow (CRITICAL)

```
main     ← STABLE ONLY (releases from dev)
  ↑
dev      ← INTEGRATION (all work merges here first)
  ↑
feature/* ← WHERE WORK HAPPENS
```

**ALL changes go to dev first. Main is ALWAYS stable.**

| Action | Target Branch |
|--------|---------------|
| Feature work | PR to `dev` |
| Bug fixes | PR to `dev` |
| Releases | PR from `dev` to `main` |

## Autonomous Principles

1. **Fix issues automatically** - Don't ask permission for obvious fixes
2. **Implement safe improvements automatically** - Low effort + safe = just do it
3. **Loop until clean** - Keep fixing until tests pass and no findings
4. **TDD by default** - RED -> GREEN -> REFACTOR before production code
5. **Only pause for genuine decisions** - Ambiguity, architecture, risk
6. **PR to dev by default** - Never PR to main unless releasing

## Work Management Actions (Human-Friendly)

Use these action names consistently:
- **create** - create typed work items (epic/story/feature/bug/finding/work-item)
- **plan** - prioritize, add dependencies, and establish parent/child structure
- **run** - execute next actionable item and update state continuously

Skill mapping:
- `create` -> `create-work-items` (with `pm` support as needed)
- `plan` -> `plan-work-items` (with `github-state-tracker` support as needed)
- `run` -> `run-work-items` (with `autonomy` + `parallel-execution` support as needed)

## Create-Plan-Run Enforcement (MANDATORY)

For every process orchestration cycle, all three work-item skills MUST be involved:
1. `create-work-items`
2. `plan-work-items`
3. `run-work-items`

Hard rules:
- Never jump directly to implementation/execution without create+plan involvement in the same cycle.
- If no new findings exist, `create-work-items` and `plan-work-items` still run in normalize/no-op mode and record that outcome.
- If WIP lock blocks switching, `run-work-items` still runs dispatch evaluation and records `deferred` (not skipped).
- Missing any one of the three invocations is a fail-closed gate violation.

## Work-Item Pipeline Settings (ICA Config)

Read these values from `ica.config.json` hierarchy:
- `autonomy.work_item_pipeline_enabled` (default `true`)
- `autonomy.work_item_pipeline_mode` (`batch_auto` | `batch_confirm` | `item_confirm`, default `batch_auto`)

Effective autonomy level modifies pipeline behavior:
- `L1`: confirm before each create/plan/run transition and next-item dispatch
- `L2`: balanced default; auto-continue routine steps with non-preemptive rules
- `L3`: autonomous execution with non-preemptive continuation and configured interrupt policy

Mode behavior for actionable findings/comments:
- `batch_auto`: run create -> plan automatically, then run only if there is no active `in_progress` item
- `batch_confirm`: ask once for grouped confirmation, then run create -> plan; defer run while `in_progress` exists
- `item_confirm`: confirm each candidate item before creation, then run plan; defer run while `in_progress` exists

## In-Progress Non-Interrupt Rule (MANDATORY)

- If any item is already `in_progress`, newly detected findings/comments are intake-only (`create` + `plan`), not immediate `run`.
- Do not preempt active work for newly created items unless interrupt policy allows it.
- Default interrupt policy is fail-safe: only `p0`/security/data-loss/production-outage items may preempt.
- If interruption criteria are not met, queue and continue current item to completion before dispatching next.

## Workspace + Branch Isolation (ICA Config, MANDATORY)

Read `git.worktree_branch_behavior` from `ica.config.json` hierarchy.

Allowed values:
- `always_new` - always create a dedicated worktree + branch before implementation changes
- `ask` - ask per scoped work unit whether to create a dedicated worktree + branch
- `current_branch` - allow current branch workflow (still subject to large-change confirmation gate)

If `git.worktree_branch_behavior` is missing:
- ask explicitly which behavior to use for this project
- persist the chosen value in project `ica.config.json` (preferred) or user `ica.config.json`

Default branch naming when creating a new branch:
- `<resolved-prefix><short-scope-slug>-<YYYYMMDDHHMMSS>`

Branch prefix resolution (no hardcoding):
- if `git.worktree_branch_prefix` is set, use it (examples: `agent/`, `claude/`, `cursor/`)
- else derive from the active agent runtime (`codex/`, `claude/`, `cursor/`, `gemini/`, `antigravity/`)
- if runtime cannot be determined, use agent-agnostic default `agent/`

Mandatory behavior:
- if `always_new`, do not implement on the current branch; create and switch to the new worktree/branch first
- never perform implementation changes directly on `main` or `dev`
- if release work is requested, use a dedicated release worktree/branch before release actions

## Phase Overview

```
┌─────────────────────────────────────────────────────────────────┐
│ WORK MANAGEMENT PHASE (AUTONOMOUS)                              │
│ create → plan → run-ready                                        │
│ Ensure typed items, priorities, dependencies, parent/child links │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ DEVELOPMENT PHASE (AUTONOMOUS)                                  │
│ Implement → Test → Review+Fix → Loop                            │
│ Run suggest once after queue drain by default                   │
│ Pause only for: ambiguous requirements, architectural decisions │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ DEPLOYMENT PHASE (if applicable)                                │
│ Deploy → Test → Review+Fix → Commit                             │
│ Pause only for: deployment failures needing human intervention  │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ PR PHASE (to dev)                                               │
│ Create PR to dev → Review+Fix → WAIT for approval               │
│ Pause for: merge approval (ALWAYS requires explicit user OK)    │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ RELEASE PHASE (dev → main, only when requested)                 │
│ Stabilize dev → Create release PR → Tag → WAIT for approval     │
│ Pause for: release approval (requires explicit "release" cmd)   │
└─────────────────────────────────────────────────────────────────┘
```

## Phase 0: Work Management (AUTONOMOUS)

### Step 0.1: Resolve Tracking Backend
```
Use create/plan/run config-first routing:
  1) .agent/tracking.config.json
  2) ${ICA_HOME}/tracking.config.json
  3) $HOME/.codex/tracking.config.json or $HOME/.claude/tracking.config.json
  4) auto-detect GitHub
  5) fallback to .agent/queue/
```

### Step 0.1a: Resolve Autonomy Levels (MANDATORY)
```
Resolve autonomy settings from `ica.config.json` hierarchy (not tracking config):
  user config:
    - ${ICA_HOME}/ica.config.json
    - $HOME/.codex/ica.config.json
    - $HOME/.claude/ica.config.json
  project config:
    - ./ica.config.json

Required keys:
  - autonomy.system_level: L1 | L2 | L3 (default L2)
  - autonomy.project_level: follow-system | L1 | L2 | L3 (default follow-system)

Bootstrap prompts (if missing):
  - if autonomy.system_level missing:
      ask: "No system autonomy level is configured. Set system autonomy level to L2 (recommended), L1, or L3?"
      persist in user ica.config.json
  - if autonomy.project_level missing:
      ask: "No project autonomy level is configured. Set project autonomy level to follow-system (recommended), L1, L2, or L3?"
      persist in project ica.config.json

Compatibility:
  - if legacy autonomy.level exists and autonomy.system_level is missing, treat it as system level for this run and persist to autonomy.system_level

Effective level resolution:
  - if project_level is L1/L2/L3, use project level
  - if project_level is follow-system, use system level
```

### Step 0.1b: Bootstrap Tracking Config (MANDATORY)
```
If project config is missing, ask explicitly:
  "Use system tracking config for this project, or create a project-specific backend config?"

If selected config file is missing:
  - ask for backend default (`github` or `file-based`)
  - create config file immediately
  - persist and use selected provider for the run

Minimum persisted shape:
{
  "issue_tracking": { "enabled": true, "provider": "github" },
  "tdd": { "enabled": false }
}

If user asks to change backend later:
  - update the same config file
  - confirm active provider after update
```

### Step 0.1c: TDD Activation Confirmation (MANDATORY)
```
If TDD skill is active (locally or globally):
  ask explicitly:
    "TDD is active. Apply TDD for this work scope? (yes/no)"

Persistence rules:
  - If `tdd.enabled` is missing in selected config, ask for default and persist it.
  - Scope-level answer overrides stored default for current run.
  - If user requests default change, update `tdd.enabled` in selected config.
```

### Step 0.1d: Resolve Work-Item Pipeline Mode (MANDATORY)
```
Resolve from ICA config hierarchy:
  - autonomy.work_item_pipeline_enabled (default true)
  - autonomy.work_item_pipeline_mode (default batch_auto)
  - autonomy.interrupt_policy (p0_only | always_confirm | never_preempt, default p0_only)
  - autonomy.dispatch_trigger (on_completion | immediate_if_idle, default on_completion)
  - autonomy.system_level (L1 | L2 | L3)
  - autonomy.project_level (follow-system | L1 | L2 | L3)
  - effective autonomy level (resolved in Step 0.1a)

Effective-level behavior:
  - L1: require confirmation before create/plan/run transitions and before dispatching next item
  - L2: run configured pipeline mode with non-preemptive WIP lock
  - L3: run configured pipeline mode fully automatically with non-preemptive WIP lock

When actionable findings/comments are detected:
  - If pipeline is disabled: do not auto-orchestrate; wait for explicit create/plan/run instruction
  - If enabled:
      batch_auto    -> create + plan automatically; run only when no active in_progress item
      batch_confirm -> ask once, then create + plan; run only when no active in_progress item
      item_confirm  -> ask per item, then create + plan; run only when no active in_progress item

If an item is already `in_progress`:
  - do NOT auto-dispatch new items unless interrupt policy criteria are met
  - queue and triage them, then dispatch on completion of the active item
```

### Step 0.1e: Resolve Worktree/Branch Behavior (MANDATORY)
```
Resolve from ICA config hierarchy:
  - git.worktree_branch_behavior (always_new | ask | current_branch)

If missing:
  - ask user which behavior to use
  - persist in project or user ica.config.json

If value is always_new:
  - create a new worktree + prefixed branch before implementation
  - continue all implementation on that branch/worktree only

If value is ask:
  - ask for this work scope before implementation
  - if approved, create a new worktree + prefixed branch
```

### Step 0.2: create (Typed Work Items)
```
Invoke create-work-items.

Create or normalize work items as typed units:
  epic, story, feature, bug, finding, work-item

When actionable findings/comments are present and
`autonomy.work_item_pipeline_enabled=true`, this step is mandatory
even without an explicit "create" command.

Creation behavior for newly detected findings/comments:
  - create as intake work (`pending_triage` or backend equivalent), not `in_progress`
  - if another item is currently `in_progress`, this step MUST NOT trigger preemptive execution

If GitHub backend is active:
  - Use github-issues-planning workflow to create typed issues

If TDD is being performed for this scope:
  - MUST create explicit phase work items: RED, GREEN, REFACTOR
  - MUST plan them for execution in dependency order
```

### Step 0.3: plan (Priorities + Relationships)
```
Invoke plan-work-items.

Prioritize and define dependencies.

When actionable findings/comments were captured in Step 0.2, planning is
mandatory before any execution starts.

Planning behavior while work is active:
  - preserve the currently `in_progress` item as execution lock
  - triage and reprioritize new intake items for subsequent dispatch
  - do not replace active `in_progress` selection unless interrupt policy criteria are met

If parent/child hierarchy exists on GitHub:
  - Create native GitHub relationship (sub-issue/parent-child link)
  - Do NOT treat "Parent: #123" body text as a native link
  - Verify link exists before marking planning complete
```

### Step 0.4: run (Select + Execute Next Actionable Item)
```
Invoke run-work-items after create + plan are complete.

run-work-items MUST:
  - continue the current `in_progress` item first (WIP lock)
  - if no `in_progress` item exists, select next unblocked actionable item
  - never preempt current work for newly added findings unless interrupt policy allows
  - execute with process quality gates
  - update backend state transitions continuously
```

### Step 0.5: run-ready Check
```
Proceed to Phase 1 only when:
  - autonomy level is resolved (`system_level` + `project_level` -> effective level)
  - Next actionable item is identified
  - current WIP lock is respected (or explicit interrupt gate has passed)
  - Blockers/dependencies are known
  - Tracking state is current
  - run-work-items has a selected next item
  - create-work-items invocation evidence exists for this cycle (`created` or `normalized-noop`)
  - plan-work-items invocation evidence exists for this cycle (`reprioritized` or `validated-noop`)
  - run-work-items invocation evidence exists for this cycle (`selected` | `deferred` | `blocked` | `done`)
  - backend-aware tracking verification passes for the selected backend
  - if TDD is being performed: explicit RED/GREEN/REFACTOR items exist and are sequenced
```

### Step 0.6: Validation + Check Gate (MANDATORY)
```
Run `validate` skill before implementation starts.

Gate must confirm:
  - selected work item is typed and prioritized
  - dependency graph has no unresolved prerequisite for selected item
  - tracking backend state is synchronized
  - parent-child linkage is valid for backend in use
  - backend-aware tracking verification passes

Fail-closed:
  IF gate fails:
    - DO NOT start implementation
    - mark item blocked with concrete reason
    - route back to create/plan steps until gate passes
```

## Phase 1: Development (AUTONOMOUS)

### Step 1.0: Memory Check (AUTOMATIC)
```
BEFORE implementing, search memory:

  # Portable: resolve memory CLI location (prefers ICA_HOME when set)
  MEMORY_CLI=""
  for d in "${ICA_HOME:-}" "$HOME/.codex" "$HOME/.claude"; do
    if [ -n "$d" ] && [ -f "$d/skills/memory/cli.js" ]; then
      MEMORY_CLI="$d/skills/memory/cli.js"
      break
    fi
  done

  if [ -n "$MEMORY_CLI" ]; then
    node "$MEMORY_CLI" search "relevant keywords"
  elif [ -d "memory/exports" ]; then
    # Fallback: search shareable markdown exports (git-trackable)
    if command -v rg >/dev/null 2>&1; then
      rg -n "relevant keywords" memory/exports
    else
      grep -R "relevant keywords" memory/exports
    fi
  fi

IF similar problem solved before:
  - Review the solution
  - Apply or adapt it
  - Skip re-solving known problems

This step is SILENT - no user notification needed.
```

### Step 1.1: TDD Gate + Implement
```
Run tdd skill for implementation tasks:
  - Define a small test plan (happy path, edge, error, regression).
  - Write failing test first (RED) and record failing evidence.
  - Implement the minimum code change to pass (GREEN).
  - Refactor safely while tests stay green.

Only skip this step if the user explicitly says tests are out of scope.
```

### Step 1.2: Test Loop
```
Run tests
IF tests fail:
    Analyze failure
    Fix automatically if clear
    GOTO Step 1.2
IF tests pass:
    Continue to Step 1.3
```

### Step 1.3: Review + Auto-Fix
```
Run reviewer skill
- Finds: logic errors, regressions, security issues, file placement
- FIXES AUTOMATICALLY (don't ask permission)

IF fixes made:
    GOTO Step 1.2 (re-test)
IF needs human decision:
    PAUSE - present options, wait for input
IF clean:
    Continue to Step 1.4
```

### Step 1.4: Suggest + Auto-Implement (Queue-Drain Default)
```
Run suggest skill when backlog execution reaches queue-drain (`run-work-items` reports `done`).
- Default behavior: defer suggest until all actionable work items are completed.
- Optional behavior: per-item suggest only if explicitly requested by user.

IF backlog is not drained and per-item suggest was not explicitly requested:
    SKIP suggest for this item
    Continue run-work-items execution loop

When suggest runs:
- Identifies improvements
- AUTO-IMPLEMENTS safe ones (low effort, no behavior change)
- PRESENTS risky ones to user

IF auto-implemented:
    GOTO Step 1.2 (re-test)
IF needs human decision:
    PAUSE - present suggestions, wait for input
    User chooses: implement some/all/none
    IF implementing: GOTO Step 1.2
IF clean or user says proceed:
    Continue to Phase 2 or 3
```

### Step 1.5: Memory Save (AUTOMATIC)
```
IF key decision was made (architecture, pattern, fix):
  # Portable: resolve memory CLI location (prefers ICA_HOME when set)
  MEMORY_CLI=""
  for d in "${ICA_HOME:-}" "$HOME/.codex" "$HOME/.claude"; do
    if [ -n "$d" ] && [ -f "$d/skills/memory/cli.js" ]; then
      MEMORY_CLI="$d/skills/memory/cli.js"
      break
    fi
  done

  if [ -n "$MEMORY_CLI" ]; then
    node "$MEMORY_CLI" write \
      --title "..." --summary "..." \
      --category "architecture|implementation|issues|patterns" \
      --importance "high|medium|low"
  else
    # Fallback: write a shareable export (no SQLite/embeddings).
    # Use a timestamp-based ID to avoid collisions.
    CATEGORY="architecture" # or implementation|issues|patterns
    SLUG="short-title-slug"
    TS="$(date -u +%Y%m%d%H%M%S)"
    mkdir -p "memory/exports/$CATEGORY"
    cat > "memory/exports/$CATEGORY/mem-$TS-$SLUG.md" << 'EOF'
---
id: mem-YYYYMMDDHHMMSS-short-title-slug
title: "..."
tags: []
category: architecture
importance: medium
created: YYYY-MM-DDTHH:MM:SSZ
---

# ...

## Summary
...
EOF
  fi

This step is SILENT - auto-saves significant decisions.
```

### Step 1.6: Completion Validation Gate (MANDATORY)
```
Before marking work complete:
  - run `validate` skill checks
  - verify test/review evidence is present
  - run backend-aware tracking verification
  - ensure work-item state transition is valid in selected backend

IF gate fails:
  - keep item in `in_progress` or move to `blocked` with reason
  - DO NOT mark complete
  - resolve failure, then re-run gate
```

**Exit:** Tests pass, no review findings, suggestions addressed

## Phase 2: Deployment (AUTONOMOUS)

Skip if no deployment required.

### Step 2.1: Deploy
```
Deploy to target environment
```

### Step 2.2: Test Loop
```
Run deployment tests
IF fail:
    Analyze and fix if clear
    GOTO Step 2.1
```

### Step 2.3: Review + Auto-Fix
```
Run reviewer skill
FIXES AUTOMATICALLY
IF fixes made: GOTO Step 2.2
```

### Step 2.4: Commit
```
Run commit-pr skill
Ensure git-privacy rules followed
```

**Exit:** Deployment tests pass, no findings, committed

## Phase 3: Pull Request (to dev)

**PRs go to `dev` branch, NOT `main`.**

### Step 3.1: Create PR to dev
```
Run commit-pr skill
MUST use: gh pr create --base dev
NEVER: gh pr create --base main (unless releasing)
```

### Step 3.2: Review + Auto-Fix (in temp folder)
```
TEMP_DIR=$(mktemp -d)
cd "$TEMP_DIR"
gh pr checkout <PR-number>

Run reviewer skill (post-PR stage)
- Run project linters (Ansible, HELM, etc.)
- FIXES AUTOMATICALLY
- Push fixes to PR branch

IF fixes made: GOTO Step 3.2 (re-review)
IF needs human: PAUSE
IF clean: Continue
```

**Required behavior (closed-loop):**
- Stage 3 MUST be executed by a dedicated reviewer subagent (recommended: a reviewer-only subagent via your Task/sub-agent mechanism).
- Reviewer Stage 3 MUST loop until the PR is clean:
  - If findings exist: fix + push commits to the PR branch, then restart Stage 3 in a fresh temp checkout.
  - When clean: post `ICA-REVIEW-RECEIPT` with `Findings: 0` and `NO FINDINGS` for the current head SHA.
  - Optional GitHub approvals (GitHub-style approvals mode):
    - Default is self-review-and-merge: **GitHub required approvals may remain at 0**, while ICA Stage 3 receipt remains
      the required review gate.
    - If `workflow.require_github_approval=true`, the reviewer subagent should also try to add a GitHub approval using
      `gh pr review <PR-number> --approve ...` (skip if already approved).
      - If PR author == current authenticated `gh` user: GitHub forbids approving your own PR (server-side rule). Skip.
        If repo rules require approvals, a second GitHub identity/bot is required for approvals.

### Step 3.3: Suggest + Auto-Implement
```
Run suggest skill on full PR diff
- AUTO-IMPLEMENTS safe improvements
- Push to PR branch
- PRESENTS risky ones to user

IF auto-implemented: GOTO Step 3.2 (re-review)
IF needs human: PAUSE, wait for decision
IF clean or user says proceed: Continue
```

### Step 3.4: Merge Approval (Default: Pause, Optional Auto-Merge)
Default behavior:
```
WAIT for explicit user approval
DO NOT merge without: "merge", "approve", "LGTM", or similar
```

Optional auto-merge (Skills-level standing approval):
- If `workflow.auto_merge=true` in the current AgentTask/workflow context
- AND the PR targets `dev`
- AND the reviewer Stage 3 ICA-REVIEW receipt exists for the current head SHA (PASS)
- AND the receipt includes `Findings: 0` and `NO FINDINGS`
- AND checks are green

Then the agent MAY proceed to merge without an additional chat approval.

**Never auto-merge to `main`** unless performing an explicitly requested release workflow.

**Exit:** No findings, suggestions addressed, user approved, merged to dev

## Phase 4: Release (dev → main)

**Only when user explicitly requests a release.**

### Step 4.1: Verify dev is stable
```
Ensure dev branch:
- All tests pass
- No pending critical issues
- User confirms ready for release
```

### Step 4.2: Create Release PR
```
gh pr create --base main --title "release: vX.Y.Z"
Include release notes and changelog
```

### Step 4.3: Await Release Approval
```
WAIT for explicit user approval
User must say "release", "merge to main", or similar
```

### Step 4.4: Tag and Publish
```
After merge to main:
git tag vX.Y.Z
git push origin vX.Y.Z
gh release create vX.Y.Z
```

**Exit:** Released to main, tagged, published

## Quality Gates (BLOCKING)

**These gates are MANDATORY. You CANNOT proceed without passing them.**

| Gate | Requirement | Blocked Actions |
|------|-------------|-----------------|
| Pre-implementation | Work item exists, prioritized, dependencies known, tracking backend updated | Start implementation |
| Pre-run transition | autonomy level resolved + `validate` checks pass + backend-aware tracking verification passes | Move item to `in_progress` |
| Pre-commit | Tests pass + reviewer skill clean + `validate` checks pass + backend-aware tracking verification passes | `git commit`, `git push` |
| Pre-PR-create | target branch valid + `validate` checks pass + backend-aware tracking verification passes | `gh pr create` |
| Pre-deploy | Tests pass + reviewer skill clean | Deploy to production |
| Pre-complete transition | `validate` checks pass + state transition rules satisfied + tracking verification passes | Mark item `completed` |
| Pre-merge | reviewer Stage 3 PASS receipt + checks green + `validate` checks pass + backend-aware tracking verification passes + user approval | `gh pr merge` |
| Pre-release-publish | release PR merged + tag pushed + release validation checks pass + explicit publish approval (non-draft) | publish non-draft release |

### Gate Enforcement

```
IF attempting commit/push/PR without running reviewer skill:
  STOP - You are violating the process
  GO BACK to Step 1.3 (Review + Auto-Fix)
  DO NOT proceed until reviewer skill passes

IF attempting commit/push/PR/merge/release without validation + tracking checks:
  STOP - Transition gate failed
  RUN validate skill + backend-aware tracking verification
  DO NOT proceed until gate passes

IF any orchestration cycle misses create/plan/run involvement evidence:
  STOP - create-plan-run enforcement failed
  RUN missing skill step(s) in order: create -> plan -> run
  DO NOT proceed until all three steps are recorded for the current cycle
```

**Skipping review is a process violation, not a shortcut.**

## When to Pause

**PAUSE for:**
- Architectural decisions affecting multiple components
- Ambiguous requirements needing clarification
- Multiple valid approaches with trade-offs
- High-risk changes that could break things
- Large changes (always ask before proceeding)
- **Merge approval** (always)

**DO NOT pause for:**
- Fixing typos, formatting, naming
- Adding missing error handling
- Fixing security vulnerabilities
- Moving misplaced files
- Removing unused code
- Extracting duplicated code
- Adding null checks

## Large-Change Confirmation Gate (MANDATORY)

You MUST ask for explicit confirmation before larger changes, regardless of other settings.

Treat as larger changes:
- cross-repository changes
- creation of new branches/worktrees or branch strategy changes
- broad refactors spanning multiple components
- release operations (merge to `main`, tagging, publishing)
- any change set with non-obvious blast radius

## Validation Checklist

- [ ] Acceptance tests include create/plan/run enforcement behavior
- [ ] Effective autonomy level is resolved before work-item orchestration
- [ ] Every orchestration cycle records create + plan + run invocation evidence
- [ ] Missing create/plan/run involvement fails closed before implementation
- [ ] WIP lock prevents preemptive run unless interrupt policy criteria pass
- [ ] Output contract reports invocation evidence and gate outcomes

## Output Contract

When this skill runs, produce:
1. whether actionable findings/comments were detected and why
2. autonomy resolution (`system_level`, `project_level`, effective level, and whether defaults were bootstrapped)
3. pipeline setting resolution (`work_item_pipeline_enabled`, `work_item_pipeline_mode`, `interrupt_policy`, `dispatch_trigger`)
4. create/plan/run invocation evidence for the cycle (including no-op or deferred reasons)
5. orchestration summary for create -> plan -> run (including non-preempt decisions and any confirmations required by mode/effective autonomy)
6. selected next actionable item and current state transition result (including WIP lock status)
7. gate summary (validation, TDD phase status, tracking verification)
8. final suggest status (`deferred` / `ran-clean` / `ran-with-changes`)
9. next action (`continue` / `blocked` / `done`)

## Commands

**Start (runs autonomously):**
```
process skill
```

**Force pause at every step (L1 mode):**
```
process skill with L1 autonomy
```

**Check status:**
```
Where am I in the process?
```