Understanding the EQ Workflow Pipeline

Overview

The EQ workflow pipeline is a structured approach to feature development that combines TDD, atomic commits, and automated review. Every step has a hard approval gate — nothing proceeds without your explicit confirmation.

The Pipeline

Plan doc → /eq-init → /eq-create-issues → /eq-execute → /eq-analyze → /eq-review → /eq-finalize → PR

1. /eq-init — Workspace Setup

Creates a feature workspace — worktree, branch, plan doc, anchor commit — in one step.

What it does:

• Scans ~/.claude/plans/ for session plans
• Creates a git worktree at .claude/worktrees/<topic>/ from main
• Copies the plan to docs/plans/YYYY-MM-DD-<topic>.md
• Commits the anchor and pushes the branch

The anchor commit follows a specific pattern that other skills rely on for resume:

Initialize feature/<topic> from docs/plans/<file>.md

When to skip: Quick fixes where a plan doc is overkill. Create a branch manually and go straight to /eq-execute.

2. /eq-create-issues — Issue Creation

Turns a plan doc into GitHub issues with project board tracking. Enforces a hard approval gate — no issues are created until you explicitly approve the proposed groupings.

What it does:

• Reads the plan doc and identifies all tasks
• Groups tasks into 3-5 logical issues and presents groupings — stops and waits
• After approval: creates issues via gh issue create
• Adds an Issue Mapping table to the plan doc (bidirectional link)

Grouping principles:

• Each issue should be an independently deployable unit of work
• Dependency chain flows forward, never circular
• Issue titles use [Feature]: [Noun phrase], not imperative sentences

When to skip: Small changes with 1-2 tasks where issues add overhead.

3. /eq-execute — TDD Implementation

The core implementation phase. Every task follows strict RED → GREEN → REFACTOR.

The TDD cycle:

RED     → Write failing tests from plan behavior lines
GREEN   → Write minimum code to pass tests
REFACTOR → Clean up, run lint + tests
VERIFY  → Full verification (lint, type-check, test)
COMMIT  → Atomic commit with (#N) in title, push

The Iron Law: No production code without a failing test. This is non-negotiable.

Execution modes:

Session resume: Progress is tracked via git commits — each completed task has (#N) in the title. On resume, the skill reads git log main..HEAD and picks up the next uncovered task. Most work lost on a session drop is one in-flight task.

Pre-flight check: Before any work, runs the full verification chain to establish a green baseline. If baseline is broken, you choose: fix first, proceed with pre-existing failures tracked, or rebase on main.

4. /eq-analyze — Mid-flight Check

Cross-validates plan, code, issues, and tests for consistency. Use mid-implementation to catch drift.

What it checks:

• Coverage — Does every plan task have an issue? Does every issue have code? Does every file have tests?
• Alignment — Missing issues, orphan issues, incomplete implementations, undocumented changes
• Drift — Scope creep, stale TODOs, debug artifacts, dependency order violations

When to run: After completing 3+ tasks, or when you’re unsure if you’ve covered everything. Not needed for small features.

Mid-implementation vs finalization: Mid-implementation, incomplete coverage is expected — the skill distinguishes “not done yet” from “done wrong.”

5. /eq-review — Pre-PR Review

The orchestrator. Runs convention scanner, launches 3 parallel review agents, filters findings by confidence, and auto-fixes mechanical issues.

The review pipeline:

1. Convention scanner (grep-based, milliseconds) — catches CLAUDE.md “Never” rules
2. Three parallel agents: patterns, quality, security
3. Confidence filtering — only actionable findings surface
4. Auto-fix cycle for mechanical issues (up to 3 iterations)
5. Verification after fixes

Review sub-agents:

Run any sub-agent standalone for a focused mid-development check.

Runtime: 5-15 min depending on diff size.

6. /eq-finalize — PR Creation

Verifies everything is complete, ensures a review pass exists, and creates the PR with a hard approval gate.

The pipeline:

Step 0: Verify review pass (/eq-review auto-runs if missing)
Step 1: Consistency analysis (plan ↔ issues ↔ code ↔ tests)
Step 2: Full verification (lint, type-check, test, build)
Step 3: Ensure all commits pushed
Step 4: Present PR draft — STOP and wait (Gate G3)
Step 5: Create PR with Closes #N for each issue
Step 6: Update issue statuses → "in review"

Closes #N goes in the PR body only — never in commit messages. This triggers automatic issue closure on merge.

Pipeline Hooks

These run automatically — no manual invocation needed:

session-context (SessionStart hook)

Fires at the start of every session. Injects branch name, worktree location, commits ahead of main, and existing worktree detection. This is how /eq-execute resumes seamlessly after a session drop.

branch-guard (PreToolUse hook)

Intercepts every Bash command before execution. Blocks destructive git operations (reset --hard, push --force, checkout ., clean -f) on protected branches. Silent when commands are safe.

convention-scan (shared script)

Grep-based scanner for CLAUDE.md “Never” rules. Runs in milliseconds as part of every /eq-review pass. Catches: as type casting, any types, single-character variables, debug artifacts, missing blank lines, unjustified biome-ignore.

Customizing the Pipeline

Skipping Steps

Adding the Benchmark

Install separately: npx skills add mclaude95/eq-foundry -s benchmark

Runs Lighthouse CI with 3-run median when page-level files change. Measures against industry budgets (FCP < 1.8s, LCP < 2.5s) and detects regressions vs main baseline.

Troubleshooting

Pre-existing failures on resume

The pre-flight check may find failures from main. Track them separately — don’t fix unrelated issues in a feature branch.

Worktree already exists

Either resume (cd .claude/worktrees/<topic> + /eq-execute) or clean up (git worktree remove .claude/worktrees/<topic>).

Build fails at finalization

Usually a type error from a later task not caught per-task, or a missing dependency. Fix, commit, re-run /eq-finalize.

Review found unresolvable issues

/eq-review auto-runs during finalization. If it can’t fix issues in 3 iterations, finalization halts. Fix manually, then re-run.

”Grouping is obvious, why ask?”

The approval gate on /eq-create-issues exists because agents skip approval when groupings feel mechanical. The overhead is one confirmation message.