Adaptive workflow

Allye's workflow is adaptive. It provides a set of composable playbooks rather than forcing every request through a rigid chain of agents or work items.

The default loop is:

intent → context → optional research → decision/consent → action → verification → optional persistence

The agent chooses the smallest useful loop, can repeat a checkpoint when new information appears, and can continue locally when an optional Allye capability is unavailable.

Start with intent and context

At the beginning of meaningful work, the agent should:

1. Understand the request and identify whether it is exploratory, planning, implementation, review, or delivery work.
2. Load Allye context when the MCP connection is available and useful.
3. Discover relevant team skills, standards, templates, and prior decisions.
4. Ask about an ambiguity that changes scope, risk, or architecture instead of guessing.

A work item is recommended for meaningful, delegated, shared, or review-heavy work because it provides traceability. A small, local, reversible change may use a no-task path when that choice is explicit. The plugin does not create work items merely to satisfy a phase rule.

Consequential mutations—such as changing shared records, status, branches, or published material—require the appropriate user consent. The host integration must preserve that checkpoint even when it can automate other steps.

Workflow phases

Sandbox and discovery

Use exploration when the direction is not yet decided. Research and repository analysis can inform a Discovery Doc without creating product work items. The phase ends when there is enough context to make a scope decision or hand the work to planning.

Product planning

Product planning turns an approved direction into an Epic → Feature → Story structure with acceptance criteria. It is for defining what should be built, not for making implementation guesses.

Technical planning

Technical planning starts from a Story and identifies the tasks, dependencies, verification approach, and implementation decisions. Gray areas are discussed before tasks are committed. Locked decisions should be carried into the next phase rather than rediscovered.

Orchestration

The Orchestrator coordinates an already planned delivery. Depending on the host and available runtime, it may assign work, dispatch an Executor, request independent review passes, run a correction loop, and cascade statuses through the hierarchy.

Parallel dispatch is optional. It requires a compatible runtime and isolated workspaces; without one, delivery continues one Story at a time or directly in the current conversation.

Execution

Execution implements the planned tasks. The agent reads the relevant code and project guidance before editing, follows the agreed scope, and uses Red → Green → Refactor when behavior can be expressed as a deterministic example. When TDD is not a fit, the agent still verifies proportionally rather than skipping evidence.

Review

Review checks two different questions:

• Specification: Does the result satisfy the requested behavior, acceptance criteria, and locked decisions?
• Standards: Is the implementation consistent with project conventions, security expectations, maintainability, and test quality?

Claude Code provides separate Reviewer-Spec and Reviewer-Standards subagents for these axes. Other hosts may expose a single review persona or let the current agent perform both passes. The distinction remains useful even when the host does not provide separate agents.

A failed review starts a bounded correction round. Passing one axis does not silently cancel a failure on the other.

Delivery

Delivery is a deliberate close-out, not an automatic side effect of the last edit. Before claiming completion, the agent verifies that the requested scope is complete, records relevant evidence, updates documentation when appropriate, and saves durable delivery context when Allye memory is available.

Handovers between conversations

A handover is an optional transport for meaningful, multi-step, delegated, or cross-session work. It lets a user review the context before pasting it into a fresh conversation. It is not a memory record and should not be treated as a substitute for the Allye work item or documentation it references.

Every handover starts with this parser-compatible marker:

## 🔄 Allye Handover — {type}
**Skill to load:** {skill-slug}

The marker and field name stay fixed so the bootstrap can detect them. The body is written in the user's language and includes concrete keys, required reading, locked decisions, scope, verification expectations, and the next action. It ends with:

---
If anything is unclear, STOP and ask — don't proceed on a guess.

The supported handover types are:

Reviewer passes do not receive handovers; they receive the Story, tasks, changed files, and verification evidence through their host's dispatch mechanism.

Verification and completion evidence

Verification is a bounded loop:

run the relevant check → understand the result → fix if needed → run it again

The check should match the change. Depending on the project, that can include focused tests, a type check, linting, a local integration check, a real application or screen check, or a manual acceptance step. The plugin does not claim that a check ran merely because a command was suggested.

Before reporting completion, distinguish among:

• Implementation evidence: what changed and which checks passed.
• Review evidence: which specification and standards checks passed.
• Delivery state: whether all work items and documentation gates are actually complete.
• External gates: anything still requiring user approval, deployment, publication, or another environment.

If a verification command fails, the agent either fixes it within scope, asks about a scope-changing failure, or reports the blocker. It must not hide the failure behind a success claim.

Memory and continuity

Memory is conditional, not an unconditional automatic save on every event. When Allye is available and the work benefits from continuity, the agent can search relevant prior decisions and save durable context such as:

• decisions and their rationale;
• blockers and affected work;
• session position and next step;
• delivery evidence and follow-up items.

If Allye is unavailable, the agent says so and continues only with the context it can actually access. A host should never imply that a memory search or save occurred when it did not.

Statuses and team pipelines

Allye guarantees status categories such as proposed, in_progress, done, and cancelled, but teams may give their columns different names. Names such as backlog, todo, review, or QA are examples of a configured pipeline, not universal plugin requirements.

The workflow respects the active team's transitions and does not assume that a particular column name exists. A Story is not complete merely because implementation finished: its tasks, review evidence, verification, and any required delivery gates must agree.

Host differences

The workflow contract is shared, while its presentation and level of host control depend on the platform. The plugin is tested extensively with Claude Code, Codex, and OpenCode, and Pi is the recommended platform for using Allye Plugin:

• Pi exposes an adaptive toolkit and detects optional subagents or external runtime capabilities at session time. It gives Allye and the host more autonomy to choose and configure how the harness works.
• OpenCode exposes six selectable Allye agents through its native package and gives you more autonomy to choose and configure the harness for a given task.
• Claude Code can use native hooks, five bounded subagents, and separate review axes. Because Claude Code controls more of when context and tools are used, an explicit request may be needed to access Allye Memory or load a specific Allye skill. This is a host behavior rather than a judgment about Claude Code's capabilities.
• Codex uses one host agent with a manifest and MCP-discovered skills. It is a well-tested option when you prefer Codex's conversational model.
• Cursor and Gemini CLI use one host agent with a manifest and MCP-discovered skills.
• Hermes reads exported skills from disk and uses a bootstrap plugin.

All supported platforms use the same remote MCP connection model: a URL supplied by the host integration or administrator and browser-based OAuth. Native delegation, a picker, or a bootstrap hook is an optimization—not a prerequisite for planning, implementation, review, handover, or verification.