# Run Impl Loop

> > **Serena MCP is mandatory for code (read-only here).** First call `mcp__serena__initial_instructions` to load the Serena tool manual, then use Serena for ALL code reading / searching / navigation — prefer symbol navigation (`get_symbols_overview` / `find_symbol` / `find_referencing_symbols`) over whole-file reads. (This skill mostly delegates to workflows/agents.)

- Skill: `atherio-danp/run-impl-loop` (Agent Skill)
- Install (CLI): `npx skillmds@latest add atherio-danp/run-impl-loop`
- Raw SKILL.md: https://api.skillmd.com/api/skills/atherio-danp/run-impl-loop/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: atherio-danp (https://skillmd.com/u/atherio-danp)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/atherio-danp/run-impl-loop

---


> **Serena MCP is mandatory for code (read-only here).** First call `mcp__serena__initial_instructions` to load the Serena tool manual, then use Serena for ALL code reading / searching / navigation — prefer symbol navigation (`get_symbols_overview` / `find_symbol` / `find_referencing_symbols`) over whole-file reads. (This skill mostly delegates to workflows/agents.)

# Run the implementation loop

**YOU (the main agent) drive this loop and OWN the judgment steps**; the mechanical fan-out runs in saved
workflows. This is the hybrid operating model: the main agent keeps the judgment steps (1, 5, 7, 9) and
calls saved workflows for the mechanical stages (steps 2–4, 6, 8). Plan format:
`docs/projectStandards/implementation-plan-format.md`.

`$ARGUMENTS` = the path to an **approved** plan in `docs/plans/`, optionally a scope hint. Do the steps in
order. **Do not skip or delegate the judgment steps (1, 5, 7, 9) — they are yours, not a subagent's.**

## 1. Analyze (you)
- Read the plan FULLY.
- Cross-check that **every symbol it references actually exists** with the stated signature (Serena
  `find_symbol` / `search_for_pattern` for `.cs`). List every inconsistency.
- If there are inconsistencies or unresolved OPEN QUESTIONS, **STOP** — fix the plan or surface the gaps to
  Dan before building. Never implement against a broken plan.
- Determine the **scope** (backend / frontend / fullstack) from the files the plan touches.

## 2–4. Implement → validate → test (workflow)
Run the **`impl-build`** workflow:
`Workflow({ name: 'impl-build', args: { planPath: '<plan>', focus: 'the entire plan' } })`
It spawns the implementer, loops implement→validate until the validator passes (or the fix budget is
exhausted — if `exhaustedFixBudget`, STOP and report to Dan), then the testing-expert writes the plan's
exact test list.

- **If it returns `blocked: true`** — the implementer hit a **material divergence** (the plan's assumptions
  no longer hold: a locked decision invalidated, the approach broken, a new dependency needed). **STOP**:
  surface the `blocker` + `recommendedOptions` to Dan, get a decision, **update the plan**, then re-run. Never
  let a subagent improvise a large unplanned change — that decision is Dan's.

## 5. Evaluate tests + review deviations (you)
- Read the **`deviations`** list — everything the implementer did off-plan to reconcile with the real code
  (the plan goes stale; small adaptations are expected). Sanity-check each is sound and in the plan's spirit;
  if one is actually wrong or oversteps, treat it as a finding to fix.
- Read the `tests` result; if a test surfaced a real defect, re-run `impl-build` with `focus` = that defect.
- Confirm **exact** pass/fail/skip counts.

## 6. Architect review (workflow)
Run the **`architect-review`** workflow with the scope from step 1:
`Workflow({ name: 'architect-review', args: { scope: [...], changedPaths: '<changed files>', planPath: '<plan>' } })`
It runs the relevant reviewers in parallel (rule-adherence + bug hunt) and adversarially verifies each finding.
**Include `'security'` in scope for any backend change** — it runs the backend security auditor (OWASP Top 10,
tenant isolation, secret handling, EU data residency).

## 7. Triage (you)
Take the returned findings and analyze them **ONE BY ONE, reading the actual code line by line**. Keep only
the ones that genuinely add up; discard noise (even some marked `real` — the verdicts are a pre-filter, the
decision is yours). Produce the precise list of findings to fix.

## 8. Fix (workflow)
If any findings add up, run `impl-build` again with `focus` = a precise description of those findings
(implement→validate→test loop). Repeat 7–8 if the fixes warrant another review.

## 9. Summary (you)
Present Dan a concise summary: what was implemented, **what was done off-plan and why** (the deviations —
call these out clearly, never bury them), validation status, **exact** test counts, findings triaged (kept
vs discarded, one-line reasons), and what was fixed. **Do not commit or push** — git is ask-gated and happens
only on Dan's explicit word.