Executing Plans (Inline)

Execute implementation plans directly in the current session. Use this when tasks are tightly coupled and share context. For independent tasks, use mbscode:subagent-driven-development instead.

When to use this vs subagent-driven-development:

• Tasks share files or state → this skill (shared context avoids conflicts)
• Tasks are independent, ≥3 tasks → subagent-driven-development (fresh context, parallel review)
• Unsure → subagent-driven-development (safer default)

The Process

Step 1: Load and Review

1. Read plan file completely
2. Check the Resume section — pick up where the last session left off
3. Resume integrity check: Compare Resume's "Last completed" with actual checkbox state. If they disagree, trust the checkboxes (updated per-step; Resume updates per-task). If a step is [x] but its verification step is NOT [x], re-run the verification. Log discrepancies to LESSONS_LEARNED.md.
   • Missing Resume section → reconstruct from checkboxes (find last [x] step)
   • Malformed YAML frontmatter → infer status from checkboxes, fix frontmatter
   • Referenced files that don't exist → note in Resume as blocker
4. Review critically — identify questions, gaps, or concerns
5. If concerns → raise with user before starting. Autonomous default: If running non-interactively, document the concern in SESSION.md, make the smallest reversible assumption, and proceed unless the concern invalidates the plan's core architecture.
6. If no concerns → extract remaining tasks, track remaining tasks
7. Update plan frontmatter: status: in_progress

Do NOT start implementation on main/master. Create a feature branch first (per GATES.md Pre-Task Gates).

Step 2: Per-Task Execution

For each task:

1. Note the current task in SESSION.md; ensure plan frontmatter is status: in_progress
2. CHECK Pre-Task Gates (read GATES.md, verify all items)
3. Execute each step exactly as written in the plan
   • Follow bite-sized steps as specified
   • Run verifications at each step
   • Mark each step [x] in the plan file immediately when done
   • If blocked → see When to Stop and Ask / When to Proceed Autonomously section below
4. CHECK Post-Task Gates (read GATES.md, provide evidence for each)
5. Mark task as done — all steps must be [x]
6. Update the plan's Resume section (after each task, not each step)
7. Update SESSION.md pointer if needed

Step 3: Milestone Review

When a milestone boundary is reached:

1. Run full test suite — capture output
2. Invoke mbscode:autonomous-review
3. Fix any issues → re-review until all dimensions pass
4. Update plan's Resume section
5. Continue to next milestone

Step 4: Completion

After all tasks:

1. Invoke mbscode:verification-before-completion — full evidence
2. Update plan frontmatter: status: done
3. Update MAP.md with new/modified files
4. Update SESSION.md — move plan from Active to Completed
5. Invoke mbscode:finishing-a-development-branch

When to Stop and Ask / When to Proceed Autonomously

Interactive sessions — STOP immediately when:

• Test fails and you don't understand why
• Plan has a gap preventing the next step
• You don't understand an instruction
• Verification fails after 2 attempts

Autonomous/non-interactive sessions:

• If the missing detail can be inferred from existing code, tests, or docs, make the smallest reversible assumption, record it in SESSION.md, and continue.
• If proceeding risks data loss, architectural drift, or violating an explicit requirement, stop and report the blocker with full context.

Plan Modifications

If a plan step is incorrect, blocked, or the approach must change during execution:

1. Document WHY — add a note under the affected step explaining the reason
2. Mark the step — use - [~] Step N: SKIPPED — [reason] for skipped steps
3. Add replacement steps if needed, clearly marked as additions
4. Update the Resume section to reflect the change
5. Interactive sessions: inform the user before continuing
6. Autonomous sessions: record the change and continue if the modification doesn't alter the plan's architecture

Major Plan Mutations

If a discovery during execution invalidates 2+ upcoming tasks:

1. STOP — do not continue with invalidated tasks
2. Checkpoint — commit current state: git commit -m "wip: checkpoint before plan revision"
3. Mark invalidated — in the plan file, mark affected tasks: [~] INVALIDATED — [reason]
4. Write replacements — add new tasks with full detail (as if writing a new plan section)
5. Update Resume — reflect the mutation in the plan's Resume section
6. Continue — in autonomous mode: proceed if no architectural drift. In interactive mode: present the mutation to the user before continuing.

Do NOT silently deviate from the plan. Do NOT follow a step you know is wrong.

Conflict Recovery

If git commit, git merge, or git rebase fails with merge conflicts:

1. Resolve the conflict — prefer accepting both changes for additive edits (e.g., checkbox updates)
2. Re-run the project's test suite to verify the merged result
3. Log the conflict and resolution to LESSONS_LEARNED.md

Red Flags

Thought	Reality
"I'll check gates at the end"	Gates are per-task. Check every time.
"This gate doesn't apply to this task"	If it's in GATES.md, it applies.
"Tests probably pass"	Run them. Show output.
"I'll update docs later"	Update SESSION.md now. MAP.md now.
"I'm blocked but I'll try something"	STOP. Ask. Don't guess.

Transitions

Called by: mbscode:writing-plans (when user chooses inline execution) During: mbscode:autonomous-review at milestone boundaries After all tasks: mbscode:finishing-a-development-branch