In the previous posts, we established:

• Designing agentic workflows: where agents fail and where we fail
• Designing agentic workflows: a practical example
• Designing agentic workflows: the core loop

The core execution loop:

1. Define gates
2. Plan one bounded task
3. Implement exactly one task
4. Repeat until all gates pass
5. Run cleanup

That loop is the default path. Most issues go straight into it.

The supplementary commands do not replace the loop. They address two pressures: context degradation and intent drift.

If neither pressure is present, skip them. If either appears, use them deliberately.

Pressure 1: Context degrades

/wf-summarise

Long sessions degrade gradually. Repeated corrections appear. Previously rejected approaches reappear. Architectural decisions get lost. Small logic mistakes creep in.

The core loop assumes sessions are disposable.

The "50% rule" is a heuristic, not a hard stop. Finish the current bounded unit of work and exit before automatic compaction occurs, corrections begin looping, or state reconstruction becomes unreliable.

Compaction compresses earlier reasoning. Each compression step discards detail. After several rounds, subtle constraints disappear.

/wf-summarise prevents that erosion.

What /wf-summarise does

When you decide to reset:

1. Finish the current task or step.
2. Run /wf-summarise.
3. It generates a structured temporary handover document and a phase-aware continuation prompt for the next session.

The handover captures:

• Issue objective and scope
• Gate status
• Completed tasks
• Remaining work
• Key architectural decisions
• Relevant constraints
• Important discoveries

Handover documents are temporary. They bridge sessions, not commits.

The command output includes a continuation block tailored to the current phase:

---
You are resuming work on `issue-47-user-validation`.

Before proceeding:
1. Read `.agents/issues/issue-47-user-validation/handover.md`
2. Confirm gate status
3. Identify next task

Current phase: Implementation
Tasks completed: task-1, task-2
Tasks remaining: task-3, task-4
---

You paste that into a fresh session along with the handover document. The new session reconstructs state from artifacts and the handover. Once alignment is confirmed, the handover can be discarded.

Examples

Task almost complete, context around 60%

Tests nearly passing. Work coherent.

Finished the task. Committed. Started a fresh session for the next task.

Corrections looping, context around 60%

Agent repeating rejected approaches. Failing to resolve something cleanly. Constraints being restated.

Degradation has started.

Stopped iterating. Ran /wf-summarise. Reset deliberately instead of brute-forcing through polluted context.

Mid-work, context near 70%

Mid-design or mid-implementation. Significant work remaining.

Context near compaction.

Checkpoint. Reset. Continue in a fresh session.

/wf-summarise is a pressure valve for context. It makes resets controlled instead of lossy.

Pressure 2: Intent must be explicit

Starting point: Issue with clear success criteria

Before entering the core loop, you need an issue with verifiable success criteria.

Most teams already have issues from GitHub, JIRA, product specs, or bug reports. If your issue has clear, verifiable criteria, proceed to the litmus test below.

If you need to create or enrich an issue, use /wf-issue-plan. It will check for investigation, design, or ADR gaps and suggest the appropriate on-demand command before proceeding.

The on-demand trio

Once you have an issue defined, ask:

Can I define verification gates for this right now?

If the answer is unclear, do not enter the core loop yet.

• Yes, clearly - Go straight to gates and enter the core loop.
• Yes, but I need to define interfaces first - Use /wf-design.
• Yes, but this requires an architectural decision that constrains future work - Use /wf-adr.
• No, I don't understand the issue or codebase well enough - Use /wf-investigate.

These commands make intent explicit before implementation begins.

/wf-investigate

Use this when:

• The issue description is vague.
• You are debugging unfamiliar code.
• You need to explore before defining "fixed."

Not needed for:

• Clear bugfixes with known root cause.
• Features in familiar code with obvious implementation path.
• Changes where you can immediately define "done."

A bug report says "Authentication sometimes fails." You cannot define gates yet. "Sometimes" is not verifiable.

Investigation might reveal it fails when token expiry falls within a 5-second race window and only affects a specific middleware branch.

Now you can define concrete gates:

• expired_token_within_grace_period_rejected
• valid_token_within_window_accepted

Investigation exists to make gates possible. If you cannot define "done," you do not understand the problem well enough.

/wf-design

Use this when introducing new interfaces, changing public contracts, or adding cross-cutting abstractions.

Not needed for:

• Internal implementation details that don't affect contracts.
• Small behavioral changes in existing functions.
• Refactoring that preserves existing interfaces.

Design produces proposed interfaces, data shapes, interaction patterns, and trade-offs. No implementation. Human review happens before code.

You are adding a new API endpoint. Instead of implementing immediately, you define request/response schema, error contract, and versioning expectations.

Design answers:

What are we building for this issue?

It prevents structural drift during implementation. Design is issue-scoped structure.

/wf-adr

Use this when the decision introduces or rejects a dependency, changes architectural direction, constrains future work, or is likely to be revisited if undocumented.

Not needed for:

• Implementation choices (sort algorithm, loop structure, data structure).
• Local design patterns within a module.
• Tooling or developer experience improvements.
• Style or convention decisions.

Reserved for:

• Introducing or rejecting dependencies (libraries, services, infrastructure).
• Choosing system-wide patterns (API style, auth approach, data flow).
• Organizational architecture (monorepo structure, deployment strategy).

The purpose of /wf-adr is not to let the model decide. It structures the decision space.

The command produces context, explicit options, trade-offs, and consequences of each option. It does not select the final approach.

The output is presented to the human. The human reviews it with their team. The team makes the decision. That decision is documented as the ADR. The documented ADR becomes a durable constraint. Future planning must respect it.

Choosing between native crypto APIs or introducing a third-party JWT library: the agent can enumerate maintenance cost, upgrade surface area, and operational risk. It does not choose. The team decides. The ADR records that decision.

ADR answers:

What rule are we introducing into the system?

Design is issue-scoped. ADR is cross-issue constraint.

Knowing when to skip

Not every change needs investigation. Not every feature needs design. Not every decision needs an ADR.

Small, well-understood bugfix? Go straight to gates.

Clear behavioural adjustment with no structural impact? Skip design.

Implementation detail that does not affect boundaries? No ADR.

The core loop is the default. The supplementary commands are situational.

How this supports the core loop

The core loop remains:

1. Define gates
2. Plan bounded task
3. Implement exactly one task
4. Repeat
5. Cleanup

The supplementary commands intervene before or during that loop when pressure appears:

• /wf-issue-plan when creating or enriching issues.
• /wf-investigate before gates.
• /wf-design before implementation.
• /wf-adr before structural commitment.
• /wf-summarise during long-running work.

They do not replace the loop. They keep it viable under complexity.

The core loop enforces bounded implementation.
The supplementary commands enforce bounded context and explicit intent.

If no pressure exists, skip them.
If pressure appears, activate them deliberately.
The structure stays lean by default and expands only when necessary.