[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6MP7JBM3FHDCJDMRFRKDRG8":3,"skill-same:01M6MP7JBM3FHDCJDMRFRKDRG8":56},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":27,"linkOnly":28,"markdownContent":29,"markdownBody":30,"frontMatter":31,"refName":32,"commitSha":33,"skillDirectory":34,"forksCount":35,"repositoryHtmlUrl":36,"repositoryHomepageUrl":37,"ownerHtmlUrl":38,"ownerBlogUrl":39,"ownerDescription":40,"updatedAt":41,"install":42,"resources":55},"01M6MP7JBM3FHDCJDMRFRKDRG8","run",null,"Run a full pipeline for a task. Orchestrates roles through stages (standalone or HOTL-integrated).","hashgraph-online\u002Fawesome-codex-plugins","hashgraph-online","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F160371962?v=4","01M6CNB6NRJVNNGN14TR01Q6D3","HOL (Hashgraph Online)","01M6JT1HSKKG9V68KQAQGBA7XP",1575,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fyimwoo\u002Fcodex-agenteam\u002Fskills\u002Frun\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26],"pipeline","task","full","roles","standalone","for","full pipeline","hotl","2026-11-10 10:12:30",false,"---\nname: run\ndescription: Run a full pipeline for a task. Orchestrates roles through stages (standalone or HOTL-integrated).\n---\n\n# AgenTeam Run\n\nOrchestrate a full team pipeline for a task. This is the main entry point\nfor collaborative AI-assisted development. You are the lead; AgenTeam\ndispatches your specialists.\n\n## Process\n\n### 1. Auto-Init Guard\n\nCheck for `.agenteam\u002Fconfig.yaml`, `.agenteam.team\u002Fconfig.yaml`, or legacy\n`agenteam.yaml` in the project root. If all are missing:\n- Create config dir: `mkdir -p .agenteam`\n- Copy the template: `cp \u003Cplugin-dir>\u002Ftemplates\u002Fagenteam.yaml.template .agenteam\u002Fconfig.yaml`\n- Set the team name to the project directory name\n- Generate agents: `python3 \u003Cruntime>\u002Fagenteam_rt.py generate`\n- Tell the user: \"AgenTeam auto-initialized with default roles. Edit `.agenteam\u002Fconfig.yaml` to customize.\"\n- Then continue with the requested run in the same turn. Auto-init is a prerequisite, not the end of the workflow.\n\n### 2. Accept Task\n\nGet the task description from the user. If not provided, ask:\n\"What task should the team work on?\"\n\n### 2b. Select Profile\n\nIf the project config defines pipeline profiles, select one before init:\n\n1. Read `pipeline.profiles` from config (check if `pipeline` key is a dict\n with a `profiles` sub-key). If no profiles defined, skip this step.\n2. If the user already specified `--profile \u003Cname>` in their request, use\n it directly and skip classification.\n3. If profiles are defined:\n - Read each profile's `hints` list (advisory examples of task shape)\n - Select the best-fit profile using judgment over the task description\n and hints. Do not keyword-match — use hints as examples of the kind\n of task each profile is designed for.\n - Announce: \"Using profile **quick** (one-line fix). Override with\n `--profile standard` if needed.\"\n - Do not pause for confirmation unless confidence is low or the profile\n materially shortens the pipeline (e.g., skipping 5 of 7 stages).\n4. If uncertain which profile fits, default to `full` (all stages).\n Misclassification fails safe.\n5. Pass `--profile \u003Cname>` to the init command in step 3.3:\n ```bash\n python3 \u003Cruntime>\u002Fagenteam_rt.py init --task \"\u003Ctask>\" --profile \u003Cname>\n ```\n\n### 2b2. Inject Run History\n\nBefore starting the pipeline, check for relevant context from past runs:\n\n1. Call `python3 \u003Cruntime>\u002Fagenteam_rt.py history list --last 10`\n2. If the result is empty (no past runs), skip this step.\n3. Filter for relevance using LLM judgment:\n - Prefer runs with similar task descriptions\n - Prefer runs that touched similar artifact paths or stages\n - Prefer runs with lessons (verify failures, rework edges) — these\n are more informative than clean runs\n - Prefer recent runs over older ones\n4. Select 0-3 most relevant summaries. If nothing is clearly relevant,\n inject nothing — nothing is better than noisy context.\n5. Format as \"Prior Run Context\" and append to the task description\n for the first stage's dispatch:\n\n```\n## Prior Run Context\n\n### Run: \"add user authentication\" (2026-03-30, standard profile)\n- Status: completed (5\u002F5 stages)\n- Implement stage needed 3 verify attempts (test failures in auth middleware)\n- Cross-stage rework: test → implement (auth session handling)\n- Final verification: passed\n\n### Run: \"fix login redirect bug\" (2026-03-29, quick profile)\n- Status: completed (2\u002F2 stages)\n- Clean run, no rework\n```\n\n**Rules:**\n- Conservative: inject 0-3 summaries, never more\n- Selective: nothing is better than noisy\u002Firrelevant context\n- Non-blocking: if `history list` fails, skip silently and continue\n- No accumulation: each run gets fresh context, not a growing blob\n\n### 2c. Collaborative Discovery Mode\n\nIf multiple discovery-phase stages can run in parallel, switch to\ncollaborative discovery mode. This gives users faster results and a\nstructured handoff to implementation.\n\n**Trigger — collaborative mode activates when either:**\n\n1. **Profile-based**: The selected profile's front stages all have roles\n with `parallel_safe: true` and disjoint `write_scope` patterns.\n2. **Intent-based**: The user explicitly mentions multiple discovery\n roles: \"@architect @pm @researcher build X\"\n\nWhen not triggered (0 or 1 qualifying stages, or user didn't request\nmulti-role work), skip this section entirely — the run skill behaves\nas normal serial execution.\n\n**Detection logic:**\n\n1. Look at the first N stages in the effective pipeline. For each stage,\n check its roles via `agenteam-rt roles show \u003Crole>`.\n2. A stage qualifies for the discovery batch if ALL its roles have\n `parallel_safe: true`.\n3. Additionally, ALL roles across ALL qualifying stages must have\n disjoint `write_scope` patterns (no scope string appears in more\n than one role's write_scope list).\n4. The first stage whose roles include a non-`parallel_safe` writer\n (e.g., dev with `src\u002F**`) marks the start of the \"execution\" phase.\n5. If 0 or 1 stages qualify, fall back to normal serial execution.\n\n**Note:** The built-in discovery roles (researcher, pm, architect) are\nall `can_write: true` with `parallel_safe: true` and disjoint scopes\n(`docs\u002Fresearch\u002F**`, `docs\u002Fstrategies\u002F**`, `docs\u002Fdesigns\u002F**`). The\nparallelism basis is disjoint scopes, not read-only status.\n\n**When collaborative mode is active, the following phases apply:**\n\n#### Phase 1: Parallel Discovery Dispatch\n\n**Isolation mode constraints:**\n\n| Isolation Mode | Behavior |\n|---------------|----------|\n| `none` (scoped parallel) | Dispatch all discovery-batch roles as parallel subagents |\n| `branch` | Serial fallback — dispatch discovery stages one at a time |\n| `worktree` | Serial fallback — dispatch discovery stages one at a time |\n\nIn `isolation: none` mode:\n- Collect all roles across discovery-batch stages\n- Verify all have `parallel_safe: true` and disjoint `write_scope`\n- Dispatch all as parallel subagents (single group)\n- If scope overlap detected: fall back to serial\n\nIn `branch` or `worktree` mode:\n- Dispatch each discovery stage serially (existing behavior)\n- The convergence summary and handoff gate still apply after all\n complete — the only difference is discovery takes longer\n\nFor each discovery stage:\n- Transition: `pending → dispatched`\n- After actual launch: emit `stage_dispatched` event\n- Check HOTL skill eligibility before each dispatch (same as step c0)\n- Each role writes to its standard artifact path:\n - Researcher → `docs\u002Fresearch\u002F\u003Cdate>-\u003Ctopic>.md`\n - PM → `docs\u002Fstrategies\u002F\u003Cdate>-\u003Ctopic>.md`\n - Architect → `docs\u002Fdesigns\u002F\u003Cdate>-\u003Ctopic>.md`\n\nWait for all discovery roles to complete.\n\n**Dual-use design doc format (Architect):**\n\nThe architect's design artifact should include a HOTL-friendly contract\nblock at the end — human-readable narrative first, execution contracts\nsecond:\n\n```\n# Design: \u003CFeature Name>\n\n## Overview\n[human-readable design narrative]\n\n## Proposed Approach\n[architecture, components, data flow]\n\n## Interfaces \u002F File Targets\n[specific files\u002Fmodules to create or modify]\n\n## Risks\n[what could go wrong, migration concerns]\n\n---\n\n## Execution Contracts\n\n### Intent\n- objective: [one sentence]\n- constraints: [what must not change]\n- success_criteria: [how we know it's done]\n\n### Verification\n- [test command or check]\n\n### Handoff to Dev\n- [ordered list of implementation steps]\n- [estimated scope per step]\n```\n\nThis is HOTL-compatible by shape — HOTL can consume the contracts if\npresent, dev can plan from them without HOTL.\n\n#### Phase 2: Convergence Summary\n\nAfter all discovery roles complete, render an inline summary:\n\n```\nDiscovery complete (3 specialists, ~45s):\n\nResearcher → docs\u002Fresearch\u002F2026-03-30-auth-analysis.md\n - OAuth2 + PKCE is industry standard for this use case\n - Competitor X shipped passkey support last month\n\nArchitect → docs\u002Fdesigns\u002F2026-03-30-auth-design.md\n - Proposes middleware pattern in src\u002Fauth\u002F\n - Flags: session storage needs migration\n\nPM → docs\u002Fstrategies\u002F2026-03-30-auth-strategy.md\n - Priority 1: OAuth2 basic flow (2-3 days)\n - Priority 2: Passkey support (stretch goal)\n\nRecommendation: Ready for dev handoff. Review architect artifact\nfirst — migration risk flagged.\n\nApprove handoff to Dev? (yes \u002F review artifacts first \u002F stop)\n```\n\n**Format rules:**\n- One line per role with artifact path\n- 2-4 bullets max per role (outcome-shaped, not raw telemetry)\n- One short controller recommendation line\n- Then the gate prompt\n- No cross-role synthesis — if roles disagree, it shows in their\n individual bullets\n\n**Partial failure:** If one discovery role fails while others succeed,\ninclude successful roles' outputs normally and show the failed role\nwith an error note: \"Researcher: unavailable — [error reason]\". Still\npresent the handoff gate — user decides whether to proceed.\n\n**State transitions at convergence:**\n- For each discovery stage: `dispatched → passed`\n- If stage has human gate: `passed → gated`\n- No `stage_completed` events yet — stages stay in `gated` or `passed`\n until the handoff gate is resolved\n\n#### Phase 3: Handoff Gate\n\nPause before the first writing stage. Present options:\n- **yes** → continue to execution phase\n- **review artifacts first** → user reads the full docs, then returns\n- **stop** → emit `run_finished` with `status: stopped`\n\nOn approval:\n- For each discovery stage: transition to `completed`\n- Emit `stage_completed` with `result: passed` for each\n- Record gate for each stage that had a human gate\n- Continue to the first execution stage\n\nOn rejection (stop):\n- `gated → rejected` for gated stages\n- Emit `stage_completed` with `result: failed, reason: handoff rejected`\n- Emit `run_finished` with `status: stopped`\n\n**Headless policy (CI=true or no TTY):**\n- Auto-approve the handoff gate\n- Log the convergence summary to stderr\n- Continue to execution immediately\n\n#### Phase 4: Serial Execution with Per-Role Visibility\n\nAfter handoff approval, continue through remaining stages (implement →\ntest → review) using the normal serial pipeline flow from step 6.\n\nThe addition is **per-role announcements** at each stage:\n\nStart: `Dev is implementing...`\nComplete: `Dev completed → added OAuth middleware in src\u002Fauth\u002F, login page updated`\n\nStart: `Qa is testing...`\nComplete: `Qa completed → 8 tests added (auth flow, session handling), all passing`\n\nStart: `Reviewer is reviewing...`\nComplete: `Reviewer completed → PASS, no blocking findings`\n\n**Announcement rules:**\n- Outcome-shaped: primary is what changed and whether it passed\n- Secondary (if helpful): file counts, test counts\n- Never: raw diffs, full test output, or telemetry dumps\n\nThese announcements also apply in normal (non-collaborative) serial\nmode — per-role visibility is always useful.\n\n---\n\n### 3. Branch Isolation\n\nBefore initializing the run, set up branch isolation. This applies to\n`standalone` and `dispatch-only` pipeline modes. If `pipeline: hotl`,\nskip this step (HOTL owns git lifecycle for pipeline runs).\n\n1. **Preflight:**\n ```bash\n bash \u003Cplugin-dir>\u002Fscripts\u002Fgit-isolate.sh preflight\n ```\n - If `not-a-git-repo`: skip isolation\n - If `dirty-worktree` and mode is serial or worktree: **block.** Tell user\n to stash or commit first.\n - If `detached-head`: **block.** Tell user to checkout a branch first.\n\n2. **Capture current branch** (before any git mutation):\n ```bash\n RETURN_BRANCH=$(git rev-parse --abbrev-ref HEAD)\n ```\n Store this for the entire run. Return to it after the final stage.\n\n3. **Initialize the run first** (to get run_id):\n ```bash\n python3 \u003Cruntime>\u002Fagenteam_rt.py init --task \"\u003Ctask description>\" [--profile \u003Cname>]\n ```\n Include `--profile` if one was selected in step 2b. Capture the\n `run_id` from the output.\n\n4. **Get branch plan:**\n ```bash\n python3 \u003Cruntime>\u002Fagenteam_rt.py branch-plan --task \"\u003Ctask>\" --run-id \"\u003Crun_id>\"\n ```\n\n5. **Execute the plan:**\n - If `action: create-branch`:\n `bash \u003Cplugin-dir>\u002Fscripts\u002Fgit-isolate.sh create-branch \u003Cbranch>`\n - If `action: create-worktree`:\n `bash \u003Cplugin-dir>\u002Fscripts\u002Fgit-isolate.sh create-worktree \u003Cpath> \u003Cbranch>`\n - If `action: use-current`: show warning, continue.\n - If `action: none` (hotl-deferred): skip.\n\n6. All pipeline stages run on the created branch\u002Fworktree.\n\n7. **After the final stage completes (or on abort):**\n - If `action` was `create-branch`:\n `bash \u003Cplugin-dir>\u002Fscripts\u002Fgit-isolate.sh return $RETURN_BRANCH`\n Tell user: \"Pipeline work is on branch `\u003Cbranch>`. Merge or create a PR.\"\n - If `action` was `create-worktree`:\n `bash \u003Cplugin-dir>\u002Fscripts\u002Fgit-isolate.sh cleanup-worktree \u003Cpath>`\n Tell user: \"Pipeline work is on branch `\u003Cbranch>`.\"\n\n### 4. Initialize Run\n\n(Run was already initialized in step 3.3 above to obtain the run_id for\nbranch naming. Capture the run state from that output.)\n\nCapture the run state (run_id, pipeline_mode, stages).\n\nCreating the run state is bookkeeping only. Do not stop after printing\nthe run ID or stage list. Once you have the run state, continue\nimmediately into stage dispatch unless blocked by a human gate, an error,\nor an explicit user stop request.\n\n**Pipeline start banner (always show):**\n\nAfter capturing the run state, announce:\n\n```\nPipeline started: \"\u003Ctask description>\"\nProfile: \u003Cprofile name or \"full\"> | Stages: \u003Ccomma-separated stage names>\n```\n\nThis gives the user immediate confirmation of what's about to happen.\n\n### 5. Determine Pipeline Mode\n\nRead `pipeline_mode` from the run state:\n\n- **standalone** -> Run the built-in pipeline (step 4)\n- **hotl** -> Run the HOTL wrapper pipeline (step 5)\n- **dispatch-only** -> Tell the user: \"Pipeline is dispatch-only. Use\n `$ateam:assign \u003Crole> \u003Ctask>` to assign tasks to specific roles.\"\n- **auto** -> Check HOTL availability. If available, ask the user:\n \"HOTL detected. Run with HOTL integration? (yes\u002Fno)\". If yes, use HOTL\n mode. If no, use standalone mode.\n\n### 6. Standalone Pipeline\n\nIterate through each stage from the run state's `stages` in order. Do not\nhardcode a shortened list. The default standalone pipeline is:\n\n`research -> strategy -> design -> plan -> implement -> test -> review`\n\nIf the project config defines a different stage list, follow the config.\n\n```\nFor each stage in the ordered stage list:\n\n a0. Capture stage baseline:\n python3 \u003Cruntime>\u002Fagenteam_rt.py stage-baseline --run-id \u003Crun_id> \\\n --stage \u003Cstage> --action capture\n\n a1. Check if stage should be skipped (docs-only pre-dispatch skip):\n\n After a writing stage completes and before dispatching the next\n stage, check whether the changes warrant the upcoming stage:\n\n 1. Get changed files since baseline:\n ```bash\n git diff --name-only \u003Cbaseline>\n ```\n 2. Classify: **docs-only** if ALL files match `docs\u002F**`, `*.md`,\n `README*`, `CHANGELOG*`, `LICENSE*`, `.gitignore`.\n Otherwise: **code-or-config**.\n 3. If next stage is `test` AND change set is docs-only:\n - Transition: `pending → skipped`\n ```bash\n python3 \u003Cruntime>\u002Fagenteam_rt.py transition --run-id \u003Crun_id> \\\n --stage \u003Cstage> --to skipped\n python3 \u003Cruntime>\u002Fagenteam_rt.py set-stage-field --run-id \u003Crun_id> \\\n --stage \u003Cstage> --field skip_reason --value \"docs_only_change\"\n python3 \u003Cruntime>\u002Fagenteam_rt.py set-stage-field --run-id \u003Crun_id> \\\n --stage \u003Cstage> --field skipped_at --value \"\u003CISO timestamp>\"\n python3 \u003Cruntime>\u002Fagenteam_rt.py event append --run-id \u003Crun_id> \\\n --type stage_completed --stage \u003Cstage> \\\n --data '{\"result\": \"skipped\", \"reason\": \"docs_only_change\"}'\n ```\n - Announce: \"⊘ Skipping test stage (docs-only change, no tests needed)\"\n - Continue to next stage (review) or completion\n 4. Otherwise: dispatch normally (continue to step a below)\n\n **Rules:**\n - Never skip `implement` or `review` stages\n - Never skip in collaborative discovery mode\n - Only skip `test` stage, only for docs-only changes\n - Config files (*.yaml, *.toml, *.json) are NOT docs-only\n\n a. Get dispatch plan:\n python3 \u003Cruntime>\u002Fagenteam_rt.py dispatch \u003Cstage> \\\n --task \"\u003Ctask>\" --run-id \u003Crun_id>\n\n b. Read the dispatch plan (JSON). Two formats:\n\n **Flat dispatch (isolation: branch or worktree):**\n - dispatch: list of roles to launch serially\n - blocked: roles waiting for write lock\n - gate: human or auto\n\n **Grouped dispatch (isolation: none \u002F scoped parallel):**\n - groups: list of parallel-safe writer groups\n - read_only: list of read-only roles\n - gate: human or auto\n\n b2. Transition stage to dispatched:\n ```bash\n python3 \u003Cruntime>\u002Fagenteam_rt.py transition --run-id \u003Crun_id> \\\n --stage \u003Cstage> --to dispatched\n ```\n\n b3. Announce stage start to user:\n\n Format: \"[N\u002Ftotal] Assigning @Role to \u003Cverb>...\"\n\n Use the stage name to select the verb:\n | Stage | Verb |\n |-----------|------|\n | research | \"investigate\" |\n | strategy | \"define strategy\" |\n | design | \"design the solution\" |\n | plan | \"write the implementation plan\" |\n | implement | \"implement the design\" |\n | test | \"write tests\" |\n | review | \"review the implementation\" |\n\n For custom stage names not in this table, use the stage name as the verb.\n\n Adjust numbering to the actual stage count (profiles may skip stages).\n Use the stage's assigned role name from the dispatch plan.\n\n If a human gate is upcoming at this stage, append:\n \"(approval required after this stage)\"\n\n Example: \"[3\u002F5] Assigning @Dev to implement the design...\"\n\n c0. Check HOTL skill eligibility (before launching any subagent):\n\n For each role about to be launched:\n ```bash\n python3 \u003Cruntime>\u002Fagenteam_rt.py hotl-skills \\\n --run-id \u003Crun_id> --stage \u003Cstage> --role \u003Crole>\n ```\n - For each entry in the `eligible[]` array: append the `inject`\n text to the subagent's task instructions.\n - If `hotl_available` is false or `eligible` is empty: no injection,\n launch with default role instructions.\n\n c0.5. Build a role-context block for each launched role:\n\n Gather the role's static contract:\n ```bash\n python3 \u003Cruntime>\u002Fagenteam_rt.py roles show \u003Crole>\n ```\n Use the returned `handoff_contract` to tell the role what it is expected\n to consume, produce, and who reads its output next.\n\n Gather the stage's dynamic verification context:\n ```bash\n python3 \u003Cruntime>\u002Fagenteam_rt.py verify-plan \u003Cstage> --run-id \u003Crun_id>\n ```\n If a verify command is present, append it to the role context block.\n This is especially important for QA so it writes tests the pipeline can\n actually discover and run.\n\n Resolve artifact paths for prior-stage artifact discovery:\n ```bash\n python3 \u003Cruntime>\u002Fagenteam_rt.py artifact-paths\n ```\n Use the returned `paths` map to scan for prior-stage artifacts.\n This auto-detects standalone vs HOTL mode:\n - Standalone: architect → `docs\u002Fdesigns\u002F`, pm → `docs\u002Fstrategies\u002F`\n - HOTL: architect → `docs\u002Fplans\u002F`, dev plans → `.\u002F`\n\n Do NOT hardcode directory paths — always use the runtime-resolved\n paths so the context block is correct in both modes.\n\n Include the most relevant prior-stage artifacts or summaries already\n collected in step d2. Keep this block short and specific.\n\n c. Launch agents:\n\n **If plan has flat \"dispatch\" key (serial mode):**\n - For each role in dispatch list:\n - If mode is \"read\": launch as Codex subagent (can run in parallel\n with other readers)\n - If mode is \"write\": launch as Codex subagent (serial by default)\n\n **If plan has \"groups\" key (scoped parallel mode):**\n - Capture baseline: BASELINE=$(git rev-parse HEAD)\n - Launch read_only roles as parallel subagents (alongside any group)\n - For each group in order:\n 1. Launch all roles in the group as parallel subagents\n Instruct agents: \"Write your changes but do NOT run git add or\n git commit. The controller handles commits.\"\n 2. Wait for all agents in the group to complete\n 3. Serialized commit capture (controller does this, NOT agents):\n For each writing role in the group:\n - git add \u003Cfiles matching role's write_scope>\n - git commit -m \"[ateam:\u003Crole>] \u003Cstage>: \u003Csummary>\" (if staged files exist)\n 4. Check for unclaimed files: git status --porcelain\n If any remain -> containment violation\n 5. Run scope audit:\n python3 \u003Cruntime>\u002Fagenteam_rt.py scope-audit \\\n --run-id \u003Crun_id> --stage \u003Cstage> --baseline $BASELINE\n 6. If audit fails:\n - Save the complete diff as\n `.agenteam\u002Fruns\u002F\u003Crun_id>\u002F\u003Cstage>\u002Fscope-violation.patch` before\n taking any recovery action.\n - Log: \"Scope containment violation. Preserved evidence and stopped\n the stage; no checkout content was reset.\"\n - Do not modify or discard the dirty checkout. A serial replay must\n start in a new clean branch\u002Fworktree from `$BASELINE`.\n - Ask before creating that replay because it may duplicate\n non-idempotent role work. Break out of the group loop.\n - The agent file is at the path in the dispatch plan (e.g.,\n .codex\u002Fagents\u002Farchitect.toml)\n - Pass the task description and any outputs from previous stages\n as context to the agent\n - Append the role-context block from step c0.5 to the task prompt so\n static role instructions are paired with run-specific context\n - You must launch actual Codex subagents. Do not keep the work in the\n lead agent and do not simulate what a role \"would\" say.\n\n d. Emit stage_dispatched event and progress snapshot:\n ```bash\n python3 \u003Cruntime>\u002Fagenteam_rt.py event append --run-id \u003Crun_id> \\\n --type stage_dispatched --stage \u003Cstage> \\\n --data '{\"roles\": [\"\u003Crole1>\", ...], \"isolation\": \"\u003Cmode>\"}'\n python3 \u003Cruntime>\u002Fagenteam_rt.py status \u003Crun_id> --progress\n ```\n Display the progress snapshot to the user so they can see\n pipeline progress during execution.\n\n **Progress emission rule:** After every stage transition (dispatch,\n verify result, gate decision, completion, skip), emit the progress\n snapshot via `status --progress`. This gives users in-thread\n visibility into pipeline state without requiring a separate\n terminal or polling loop.\n\n d2. Collect outputs:\n - Gather each role's output\n - Store as context for subsequent stages\n\n d3. Announce stage completion to user:\n\n On success:\n \"@Role completed \u003Cstage> -- \u003Cone-line outcome summary>. \u003Cforward reference>\"\n\n Examples:\n \"@Researcher completed research -- report on auth patterns written to docs\u002Fresearch\u002F. @Pm strategizes next.\"\n \"@Architect completed design -- OAuth2+PKCE recommended, 3 approaches documented. @Dev implements next.\"\n \"@Dev completed implement -- added 4 files in src\u002Fauth\u002F, 230 lines. @Qa tests next.\"\n \"@Qa completed test -- 12 tests added, all passing. @Reviewer reviews next.\"\n \"@Reviewer completed review -- PASS, no blocking findings.\"\n\n On failure:\n \"@Role failed at \u003Cstage> -- \u003Cone-line failure reason>\"\n\n Rules:\n - One line per stage, outcome-shaped\n - Include artifact paths or counts when available\n - Include forward reference to next stage's role (except for the final stage)\n - Never dump raw output, diffs, or full test logs\n\n e. Verify stage (if configured):\n - Get verify plan:\n python3 \u003Cruntime>\u002Fagenteam_rt.py verify-plan \u003Cstage> --run-id \u003Crun_id>\n - If verify is null: skip to gate check (see transition note below).\n - Transition to verifying:\n python3 \u003Cruntime>\u002Fagenteam_rt.py transition --run-id \u003Crun_id> \\\n --stage \u003Cstage> --to verifying\n - Execute verification in the isolated workspace:\n bash \u003Cplugin-dir>\u002Fscripts\u002Fverify-stage.sh run \"\u003Cverify>\" --cwd \"\u003Ccwd>\"\n - Record result:\n python3 \u003Cruntime>\u002Fagenteam_rt.py record-verify --run-id \u003Crun_id> \\\n --stage \u003Cstage> --result pass|fail --output \"\u003Coutput>\"\n - If passed:\n python3 \u003Cruntime>\u002Fagenteam_rt.py transition --run-id \u003Crun_id> \\\n --stage \u003Cstage> --to passed\n Continue to gate check.\n - If failed:\n python3 \u003Cruntime>\u002Fagenteam_rt.py transition --run-id \u003Crun_id> \\\n --stage \u003Cstage> --to failed\n - If failed and attempts \u003C max_retries:\n Log \"Verification failed (attempt N\u002Fmax). Re-dispatching...\"\n Check verify-plan for rework_to:\n * If rework_to is set (cross-stage repair):\n Dispatch rework_roles as REPAIR (no verify\u002Fgate on repair action).\n Record: record-verify --rework-stage \u003Crework_to>\n Re-run THIS stage's verify (not the rework stage's).\n * If rework_to is not set (same-stage retry):\n Determine repair role(s):\n - Single-role stage: re-dispatch that role\n - Multi-role stage: match failing files to write_scope\n - All-read-only stage: fail-fast (no repair possible)\n Before re-dispatching, re-run hotl-skills for each repair role:\n ```\n python3 \u003Cruntime>\u002Fagenteam_rt.py hotl-skills \\\n --run-id \u003Crun_id> --stage \u003Cstage> --role \u003Crepair_role>\n ```\n The stage status is now \"failed\" or \"rework\", so\n systematic-debugging becomes eligible. Append any eligible\n inject text to the repair subagent's instructions.\n Re-dispatch repair role(s) with failure output as context\n Go back to verify\n - If failed and attempts >= max_retries (or no legal repair role):\n Log \"Verification failed after N attempts.\"\n Offer non-destructive recovery:\n result = agenteam_rt.py stage-baseline --run-id \u003Crun_id> \\\n --stage \u003Cstage> --action rollback\n If result.allowed:\n Show: git diff --stat \u003Cbaseline>..HEAD\n Save the current diff to\n `.agenteam\u002Fruns\u002F\u003Crun_id>\u002F\u003Cstage>\u002Ffailed-attempt.patch`.\n Ask: \"Create a clean recovery branch\u002Fworktree from the baseline?\"\n Never discard the current checkout automatically. Recovery runs in\n the new isolated workspace, and the preserved patch remains reviewable.\n If not result.allowed (isolation:none):\n Log: \"Rollback not available in scoped parallel mode.\"\n Show failure output to user. Do NOT advance.\n\n **Long-running harness invariant:** Treat runtime state as authoritative.\n Persist the active attempt, `thread_id`, last heartbeat, wall\u002Fidle budgets,\n retry count, and stop reason. Emit `status --progress` at least once per\n heartbeat interval. After controller interruption, invoke `$ateam:resume`;\n do not silently launch a replacement agent.\n\n f. Gate criteria check (if stage has criteria):\n result = agenteam_rt.py gate-eval --run-id \u003Crun_id> --stage \u003Cstage>\n If result.passed: continue to gate.\n If result.failed:\n Log: \"Gate criteria failed: \u003Cfailed_criteria>\"\n Escalate to human: \"Stage exceeded criteria. Approve anyway? (yes\u002Fno)\"\n If approved:\n python3 \u003Cruntime>\u002Fagenteam_rt.py record-gate --run-id \u003Crun_id> \\\n --stage \u003Cstage> --gate-type criteria_override \\\n --result approved --criteria-failed \"\u003Clist>\" \\\n --override-reason \"\u003Cuser's reason>\"\n Continue to gate.\n If rejected: mark stage failed.\n\n g. Gate check and stage completion transitions:\n\n **Transition paths (all four cases from default pipeline):**\n - verify + gate (e.g., design): dispatched → verifying → passed → gated → completed\n - verify + no gate (e.g., implement): dispatched → verifying → passed → completed\n - no verify + gate (e.g., strategy, plan): dispatched → passed → gated → completed\n - no verify + no gate (e.g., research): dispatched → completed\n\n **If verify was null (no verify configured):**\n - If gate is \"human\" or \"reviewer\":\n python3 \u003Cruntime>\u002Fagenteam_rt.py transition --run-id \u003Crun_id> \\\n --stage \u003Cstage> --to passed\n - If gate is \"auto\" or no gate:\n python3 \u003Cruntime>\u002Fagenteam_rt.py transition --run-id \u003Crun_id> \\\n --stage \u003Cstage> --to completed\n (skip gate check, stage is done)\n\n **Gate evaluation (when gate is not \"auto\"):**\n - python3 \u003Cruntime>\u002Fagenteam_rt.py transition --run-id \u003Crun_id> \\\n --stage \u003Cstage> --to gated\n - If gate is \"human\":\n Announce: \"Waiting for your approval at the \u003Cstage> gate.\"\n Pause and show the user a summary of the\n stage output. Ask: \"Approve this stage? (yes\u002Fno\u002Fdetails)\"\n - If gate is \"reviewer\" or \"qa\": dispatch the gate agent as a\n SEPARATE subagent (never the stage actor). Parse verdict\n (PASS\u002FBLOCK). Record via record-gate. If BLOCK, pause for human.\n - Record gate result:\n python3 \u003Cruntime>\u002Fagenteam_rt.py record-gate --run-id \u003Crun_id> \\\n --stage \u003Cstage> --gate-type \u003Ctype> --result approved|rejected\n\n **After gate approval:**\n - python3 \u003Cruntime>\u002Fagenteam_rt.py transition --run-id \u003Crun_id> \\\n --stage \u003Cstage> --to completed\n\n **After gate rejection:**\n - python3 \u003Cruntime>\u002Fagenteam_rt.py transition --run-id \u003Crun_id> \\\n --stage \u003Cstage> --to rejected\n\n **On re-dispatch (retry after failure or rejection):**\n - python3 \u003Cruntime>\u002Fagenteam_rt.py transition --run-id \u003Crun_id> \\\n --stage \u003Cstage> --to dispatched\n\n f0. Emit stage_completed event (after verify passed + gate approved):\n ```bash\n python3 \u003Cruntime>\u002Fagenteam_rt.py event append --run-id \u003Crun_id> \\\n --type stage_completed --stage \u003Cstage> \\\n --data '{\"result\": \"passed\"}'\n ```\n On stage failure (verify exhausted, gate rejected, or no repair):\n ```bash\n python3 \u003Cruntime>\u002Fagenteam_rt.py event append --run-id \u003Crun_id> \\\n --type stage_completed --stage \u003Cstage> \\\n --data '{\"result\": \"failed\", \"reason\": \"\u003Cfailure reason>\"}'\n ```\n\n f. Handoff:\n - Pass the collected outputs as context to the next stage\n - Design output feeds into plan stage\n - Plan output feeds into implement stage\n - Implement output feeds into test stage\n - All outputs feed into review stage\n```\n\nDo not mark the run complete after `implement`. Unless the user explicitly\nasks to stop early, continue through `test` and `review`, and surface the\nreviewer's findings before calling the pipeline done.\n\n### 6b. Final Verification (after the last configured stage)\n\nAfter all stages complete, run final verification:\n\n```\n1. Get final verify plan:\n python3 \u003Cruntime>\u002Fagenteam_rt.py final-verify-plan --run-id \u003Crun_id>\n\n2. If policy is \"unverified\":\n Print warning: \"No final verification commands configured or detected.\n AgenTeam cannot vouch for this run.\"\n Skip to completion.\n\n3. Run each command in sequence:\n bash \u003Cplugin-dir>\u002Fscripts\u002Fverify-stage.sh run \"\u003Ccommand>\" --cwd \"\u003Ccwd>\"\n\n4. If all pass: continue to completion.\n\n5. If any fail and retries remain:\n Determine repair role(s) from failure context:\n * Failing test files (tests\u002F**) -> dispatch qa\n * Failing source files (src\u002F**) -> dispatch dev\n * Both -> dispatch dev + qa\n * Unclear -> dispatch dev as fallback\n Re-dispatch repair role(s) with failure output\n Re-run all final_verify commands\n\n6. If still failing:\n block mode: mark run failed, keep branch open, print failure summary\n warn mode: print \"TESTS FAILING\" warning, complete but do not suggest merge\n```\n\nThis is non-negotiable. Final verification is the mechanism that lets\nAgenTeam vouch for its work. It runs AFTER the review stage, not before.\n\n### 6c. Run Report (always, at completion or failure)\n\nAfter final verification (or when pipeline stops due to failure):\n\n```\n1. Generate report:\n python3 \u003Cruntime>\u002Fagenteam_rt.py run-report --run-id \u003Crun_id>\n\n2. Render the JSON as markdown and write to the report_path\n (typically .agenteam\u002Freports\u002F\u003Crun-id>.md)\n\n3. Show report summary to user\n\n4. Log: \"Run report saved to \u003Creport_path>\"\n```\n\nReports are local diagnostics (gitignored). They are never auto-committed.\n\n### 7. HOTL Wrapper Pipeline\n\nWhen pipeline mode is `hotl`, AgenTeam acts as the outer orchestrator\nand composes HOTL skills for each stage:\n\n```\na. DESIGN STAGE:\n - Resolve roles: agenteam-rt dispatch design -> {architect}\n - Invoke HOTL brainstorming skill with architect's system instructions\n injected as context\n - HOTL drives the design conversation\n - Collect design output\n\nb. PLAN STAGE:\n - Resolve roles: agenteam-rt dispatch plan -> {architect}\n - Invoke HOTL writing-plans skill\n - HOTL generates the workflow file\n - Gate: human approval of the plan\n\nc. IMPLEMENT + TEST STAGE:\n - Resolve roles: agenteam-rt dispatch implement -> {dev}\n - Resolve roles: agenteam-rt dispatch test -> {qa}\n - Invoke HOTL loop-execution or subagent-execution\n - HOTL executes workflow steps\n - Implementer and qa agents are the workers\n - Write policy enforced: serial by default\n\nd. REVIEW STAGE:\n - Resolve roles: agenteam-rt dispatch review -> {reviewer}\n - Invoke HOTL code-review skill with reviewer agent\n - Gate: human approval\n```\n\n**Key principle:** AgenTeam manages role selection and write policy\nbetween phases. HOTL manages execution within each phase. AgenTeam\nnever modifies HOTL internals.\n\n### 8. Completion\n\nOnly after the final configured stage completes:\n- Emit run_finished event:\n ```bash\n python3 \u003Cruntime>\u002Fagenteam_rt.py event append --run-id \u003Crun_id> \\\n --type run_finished --data '{\"status\": \"completed\"}'\n ```\n- Announce pipeline result:\n On success: `Pipeline complete: \u003CN>\u002F\u003CN> stages passed.`\n On failure: `Pipeline stopped at \u003Cstage>: \u003Creason>. Completed \u003CN>\u002F\u003Ctotal> stages.`\n- Show a summary of what each role produced\n- Show the final state: `python3 \u003Cruntime>\u002Fagenteam_rt.py status`\n- Suggest next steps (commit, create PR, etc.)\n- Persist run history for future context:\n ```bash\n python3 \u003Cruntime>\u002Fagenteam_rt.py history append --run-id \u003Crun_id>\n ```\n This saves the run summary + lessons learned for injection into future\n runs. Only called on completed or failed runs — not stopped\u002Fabandoned.\n\nOn unrecoverable pipeline failure:\n- Emit run_finished event:\n ```bash\n python3 \u003Cruntime>\u002Fagenteam_rt.py event append --run-id \u003Crun_id> \\\n --type run_finished --data '{\"status\": \"failed\"}'\n ```\n- Persist run history (failures have useful lessons too):\n ```bash\n python3 \u003Cruntime>\u002Fagenteam_rt.py history append --run-id \u003Crun_id>\n ```\n\n## Error Handling\n\n- If a stage fails, stop the pipeline and show the error\n- If a role agent fails, report which role failed and at what stage\n- If write policy blocks a role, show the block reason and wait\n- If HOTL is configured but not available, fall back to standalone\n with a warning\n\n## Runtime Path Resolution\n\nResolve the AgenTeam runtime:\n1. If running from the plugin directory: `.\u002Fruntime\u002Fagenteam_rt.py`\n2. If installed as a Codex plugin: `\u003Cplugin-install-path>\u002Fruntime\u002Fagenteam_rt.py`\n","# AgenTeam Run\n\nOrchestrate a full team pipeline for a task. This is the main entry point\nfor collaborative AI-assisted development. You are the lead; AgenTeam\ndispatches your specialists.\n\n## Process\n\n### 1. Auto-Init Guard\n\nCheck for `.agenteam\u002Fconfig.yaml`, `.agenteam.team\u002Fconfig.yaml`, or legacy\n`agenteam.yaml` in the project root. If all are missing:\n- Create config dir: `mkdir -p .agenteam`\n- Copy the template: `cp \u003Cplugin-dir>\u002Ftemplates\u002Fagenteam.yaml.template .agenteam\u002Fconfig.yaml`\n- Set the team name to the project directory name\n- Generate agents: `python3 \u003Cruntime>\u002Fagenteam_rt.py generate`\n- Tell the user: \"AgenTeam auto-initialized with default roles. Edit `.agenteam\u002Fconfig.yaml` to customize.\"\n- Then continue with the requested run in the same turn. Auto-init is a prerequisite, not the end of the workflow.\n\n### 2. Accept Task\n\nGet the task description from the user. If not provided, ask:\n\"What task should the team work on?\"\n\n### 2b. Select Profile\n\nIf the project config defines pipeline profiles, select one before init:\n\n1. Read `pipeline.profiles` from config (check if `pipeline` key is a dict\n with a `profiles` sub-key). If no profiles defined, skip this step.\n2. If the user already specified `--profile \u003Cname>` in their request, use\n it directly and skip classification.\n3. If profiles are defined:\n - Read each profile's `hints` list (advisory examples of task shape)\n - Select the best-fit profile using judgment over the task description\n and hints. Do not keyword-match — use hints as examples of the kind\n of task each profile is designed for.\n - Announce: \"Using profile **quick** (one-line fix). Override with\n `--profile standard` if needed.\"\n - Do not pause for confirmation unless confidence is low or the profile\n materially shortens the pipeline (e.g., skipping 5 of 7 stages).\n4. If uncertain which profile fits, default to `full` (all stages).\n Misclassification fails safe.\n5. Pass `--profile \u003Cname>` to the init command in step 3.3:\n ```bash\n python3 \u003Cruntime>\u002Fagenteam_rt.py init --task \"\u003Ctask>\" --profile \u003Cname>\n ```\n\n### 2b2. Inject Run History\n\nBefore starting the pipeline, check for relevant context from past runs:\n\n1. Call `python3 \u003Cruntime>\u002Fagenteam_rt.py history list --last 10`\n2. If the result is empty (no past runs), skip this step.\n3. Filter for relevance using LLM judgment:\n - Prefer runs with similar task descriptions\n - Prefer runs that touched similar artifact paths or stages\n - Prefer runs with lessons (verify failures, rework edges) — these\n are more informative than clean runs\n - Prefer recent runs over older ones\n4. Select 0-3 most relevant summaries. If nothing is clearly relevant,\n inject nothing — nothing is better than noisy context.\n5. Format as \"Prior Run Context\" and append to the task description\n for the first stage's dispatch:\n\n```\n## Prior Run Context\n\n### Run: \"add user authentication\" (2026-03-30, standard profile)\n- Status: completed (5\u002F5 stages)\n- Implement stage needed 3 verify attempts (test failures in auth middleware)\n- Cross-stage rework: test → implement (auth session handling)\n- Final verification: passed\n\n### Run: \"fix login redirect bug\" (2026-03-29, quick profile)\n- Status: completed (2\u002F2 stages)\n- Clean run, no rework\n```\n\n**Rules:**\n- Conservative: inject 0-3 summaries, never more\n- Selective: nothing is better than noisy\u002Firrelevant context\n- Non-blocking: if `history list` fails, skip silently and continue\n- No accumulation: each run gets fresh context, not a growing blob\n\n### 2c. Collaborative Discovery Mode\n\nIf multiple discovery-phase stages can run in parallel, switch to\ncollaborative discovery mode. This gives users faster results and a\nstructured handoff to implementation.\n\n**Trigger — collaborative mode activates when either:**\n\n1. **Profile-based**: The selected profile's front stages all have roles\n with `parallel_safe: true` and disjoint `write_scope` patterns.\n2. **Intent-based**: The user explicitly mentions multiple discovery\n roles: \"@architect @pm @researcher build X\"\n\nWhen not triggered (0 or 1 qualifying stages, or user didn't request\nmulti-role work), skip this section entirely — the run skill behaves\nas normal serial execution.\n\n**Detection logic:**\n\n1. Look at the first N stages in the effective pipeline. For each stage,\n check its roles via `agenteam-rt roles show \u003Crole>`.\n2. A stage qualifies for the discovery batch if ALL its roles have\n `parallel_safe: true`.\n3. Additionally, ALL roles across ALL qualifying stages must have\n disjoint `write_scope` patterns (no scope string appears in more\n than one role's write_scope list).\n4. The first stage whose roles include a non-`parallel_safe` writer\n (e.g., dev with `src\u002F**`) marks the start of the \"execution\" phase.\n5. If 0 or 1 stages qualify, fall back to normal serial execution.\n\n**Note:** The built-in discovery roles (researcher, pm, architect) are\nall `can_write: true` with `parallel_safe: true` and disjoint scopes\n(`docs\u002Fresearch\u002F**`, `docs\u002Fstrategies\u002F**`, `docs\u002Fdesigns\u002F**`). The\nparallelism basis is disjoint scopes, not read-only status.\n\n**When collaborative mode is active, the following phases apply:**\n\n#### Phase 1: Parallel Discovery Dispatch\n\n**Isolation mode constraints:**\n\n| Isolation Mode | Behavior |\n|---------------|----------|\n| `none` (scoped parallel) | Dispatch all discovery-batch roles as parallel subagents |\n| `branch` | Serial fallback — dispatch discovery stages one at a time |\n| `worktree` | Serial fallback — dispatch discovery stages one at a time |\n\nIn `isolation: none` mode:\n- Collect all roles across discovery-batch stages\n- Verify all have `parallel_safe: true` and disjoint `write_scope`\n- Dispatch all as parallel subagents (single group)\n- If scope overlap detected: fall back to serial\n\nIn `branch` or `worktree` mode:\n- Dispatch each discovery stage serially (existing behavior)\n- The convergence summary and handoff gate still apply after all\n complete — the only difference is discovery takes longer\n\nFor each discovery stage:\n- Transition: `pending → dispatched`\n- After actual launch: emit `stage_dispatched` event\n- Check HOTL skill eligibility before each dispatch (same as step c0)\n- Each role writes to its standard artifact path:\n - Researcher → `docs\u002Fresearch\u002F\u003Cdate>-\u003Ctopic>.md`\n - PM → `docs\u002Fstrategies\u002F\u003Cdate>-\u003Ctopic>.md`\n - Architect → `docs\u002Fdesigns\u002F\u003Cdate>-\u003Ctopic>.md`\n\nWait for all discovery roles to complete.\n\n**Dual-use design doc format (Architect):**\n\nThe architect's design artifact should include a HOTL-friendly contract\nblock at the end — human-readable narrative first, execution contracts\nsecond:\n\n```\n# Design: \u003CFeature Name>\n\n## Overview\n[human-readable design narrative]\n\n## Proposed Approach\n[architecture, components, data flow]\n\n## Interfaces \u002F File Targets\n[specific files\u002Fmodules to create or modify]\n\n## Risks\n[what could go wrong, migration concerns]\n\n---\n\n## Execution Contracts\n\n### Intent\n- objective: [one sentence]\n- constraints: [what must not change]\n- success_criteria: [how we know it's done]\n\n### Verification\n- [test command or check]\n\n### Handoff to Dev\n- [ordered list of implementation steps]\n- [estimated scope per step]\n```\n\nThis is HOTL-compatible by shape — HOTL can consume the contracts if\npresent, dev can plan from them without HOTL.\n\n#### Phase 2: Convergence Summary\n\nAfter all discovery roles complete, render an inline summary:\n\n```\nDiscovery complete (3 specialists, ~45s):\n\nResearcher → docs\u002Fresearch\u002F2026-03-30-auth-analysis.md\n - OAuth2 + PKCE is industry standard for this use case\n - Competitor X shipped passkey support last month\n\nArchitect → docs\u002Fdesigns\u002F2026-03-30-auth-design.md\n - Proposes middleware pattern in src\u002Fauth\u002F\n - Flags: session storage needs migration\n\nPM → docs\u002Fstrategies\u002F2026-03-30-auth-strategy.md\n - Priority 1: OAuth2 basic flow (2-3 days)\n - Priority 2: Passkey support (stretch goal)\n\nRecommendation: Ready for dev handoff. Review architect artifact\nfirst — migration risk flagged.\n\nApprove handoff to Dev? (yes \u002F review artifacts first \u002F stop)\n```\n\n**Format rules:**\n- One line per role with artifact path\n- 2-4 bullets max per role (outcome-shaped, not raw telemetry)\n- One short controller recommendation line\n- Then the gate prompt\n- No cross-role synthesis — if roles disagree, it shows in their\n individual bullets\n\n**Partial failure:** If one discovery role fails while others succeed,\ninclude successful roles' outputs normally and show the failed role\nwith an error note: \"Researcher: unavailable — [error reason]\". Still\npresent the handoff gate — user decides whether to proceed.\n\n**State transitions at convergence:**\n- For each discovery stage: `dispatched → passed`\n- If stage has human gate: `passed → gated`\n- No `stage_completed` events yet — stages stay in `gated` or `passed`\n until the handoff gate is resolved\n\n#### Phase 3: Handoff Gate\n\nPause before the first writing stage. Present options:\n- **yes** → continue to execution phase\n- **review artifacts first** → user reads the full docs, then returns\n- **stop** → emit `run_finished` with `status: stopped`\n\nOn approval:\n- For each discovery stage: transition to `completed`\n- Emit `stage_completed` with `result: passed` for each\n- Record gate for each stage that had a human gate\n- Continue to the first execution stage\n\nOn rejection (stop):\n- `gated → rejected` for gated stages\n- Emit `stage_completed` with `result: failed, reason: handoff rejected`\n- Emit `run_finished` with `status: stopped`\n\n**Headless policy (CI=true or no TTY):**\n- Auto-approve the handoff gate\n- Log the convergence summary to stderr\n- Continue to execution immediately\n\n#### Phase 4: Serial Execution with Per-Role Visibility\n\nAfter handoff approval, continue through remaining stages (implement →\ntest → review) using the normal serial pipeline flow from step 6.\n\nThe addition is **per-role announcements** at each stage:\n\nStart: `Dev is implementing...`\nComplete: `Dev completed → added OAuth middleware in src\u002Fauth\u002F, login page updated`\n\nStart: `Qa is testing...`\nComplete: `Qa completed → 8 tests added (auth flow, session handling), all passing`\n\nStart: `Reviewer is reviewing...`\nComplete: `Reviewer completed → PASS, no blocking findings`\n\n**Announcement rules:**\n- Outcome-shaped: primary is what changed and whether it passed\n- Secondary (if helpful): file counts, test counts\n- Never: raw diffs, full test output, or telemetry dumps\n\nThese announcements also apply in normal (non-collaborative) serial\nmode — per-role visibility is always useful.\n\n---\n\n### 3. Branch Isolation\n\nBefore initializing the run, set up branch isolation. This applies to\n`standalone` and `dispatch-only` pipeline modes. If `pipeline: hotl`,\nskip this step (HOTL owns git lifecycle for pipeline runs).\n\n1. **Preflight:**\n ```bash\n bash \u003Cplugin-dir>\u002Fscripts\u002Fgit-isolate.sh preflight\n ```\n - If `not-a-git-repo`: skip isolation\n - If `dirty-worktree` and mode is serial or worktree: **block.** Tell user\n to stash or commit first.\n - If `detached-head`: **block.** Tell user to checkout a branch first.\n\n2. **Capture current branch** (before any git mutation):\n ```bash\n RETURN_BRANCH=$(git rev-parse --abbrev-ref HEAD)\n ```\n Store this for the entire run. Return to it after the final stage.\n\n3. **Initialize the run first** (to get run_id):\n ```bash\n python3 \u003Cruntime>\u002Fagenteam_rt.py init --task \"\u003Ctask description>\" [--profile \u003Cname>]\n ```\n Include `--profile` if one was selected in step 2b. Capture the\n `run_id` from the output.\n\n4. **Get branch plan:**\n ```bash\n python3 \u003Cruntime>\u002Fagenteam_rt.py branch-plan --task \"\u003Ctask>\" --run-id \"\u003Crun_id>\"\n ```\n\n5. **Execute the plan:**\n - If `action: create-branch`:\n `bash \u003Cplugin-dir>\u002Fscripts\u002Fgit-isolate.sh create-branch \u003Cbranch>`\n - If `action: create-worktree`:\n `bash \u003Cplugin-dir>\u002Fscripts\u002Fgit-isolate.sh create-worktree \u003Cpath> \u003Cbranch>`\n - If `action: use-current`: show warning, continue.\n - If `action: none` (hotl-deferred): skip.\n\n6. All pipeline stages run on the created branch\u002Fworktree.\n\n7. **After the final stage completes (or on abort):**\n - If `action` was `create-branch`:\n `bash \u003Cplugin-dir>\u002Fscripts\u002Fgit-isolate.sh return $RETURN_BRANCH`\n Tell user: \"Pipeline work is on branch `\u003Cbranch>`. Merge or create a PR.\"\n - If `action` was `create-worktree`:\n `bash \u003Cplugin-dir>\u002Fscripts\u002Fgit-isolate.sh cleanup-worktree \u003Cpath>`\n Tell user: \"Pipeline work is on branch `\u003Cbranch>`.\"\n\n### 4. Initialize Run\n\n(Run was already initialized in step 3.3 above to obtain the run_id for\nbranch naming. Capture the run state from that output.)\n\nCapture the run state (run_id, pipeline_mode, stages).\n\nCreating the run state is bookkeeping only. Do not stop after printing\nthe run ID or stage list. Once you have the run state, continue\nimmediately into stage dispatch unless blocked by a human gate, an error,\nor an explicit user stop request.\n\n**Pipeline start banner (always show):**\n\nAfter capturing the run state, announce:\n\n```\nPipeline started: \"\u003Ctask description>\"\nProfile: \u003Cprofile name or \"full\"> | Stages: \u003Ccomma-separated stage names>\n```\n\nThis gives the user immediate confirmation of what's about to happen.\n\n### 5. Determine Pipeline Mode\n\nRead `pipeline_mode` from the run state:\n\n- **standalone** -> Run the built-in pipeline (step 4)\n- **hotl** -> Run the HOTL wrapper pipeline (step 5)\n- **dispatch-only** -> Tell the user: \"Pipeline is dispatch-only. Use\n `$ateam:assign \u003Crole> \u003Ctask>` to assign tasks to specific roles.\"\n- **auto** -> Check HOTL availability. If available, ask the user:\n \"HOTL detected. Run with HOTL integration? (yes\u002Fno)\". If yes, use HOTL\n mode. If no, use standalone mode.\n\n### 6. Standalone Pipeline\n\nIterate through each stage from the run state's `stages` in order. Do not\nhardcode a shortened list. The default standalone pipeline is:\n\n`research -> strategy -> design -> plan -> implement -> test -> review`\n\nIf the project config defines a different stage list, follow the config.\n\n```\nFor each stage in the ordered stage list:\n\n a0. Capture stage baseline:\n python3 \u003Cruntime>\u002Fagenteam_rt.py stage-baseline --run-id \u003Crun_id> \\\n --stage \u003Cstage> --action capture\n\n a1. Check if stage should be skipped (docs-only pre-dispatch skip):\n\n After a writing stage completes and before dispatching the next\n stage, check whether the changes warrant the upcoming stage:\n\n 1. Get changed files since baseline:\n ```bash\n git diff --name-only \u003Cbaseline>\n ```\n 2. Classify: **docs-only** if ALL files match `docs\u002F**`, `*.md`,\n `README*`, `CHANGELOG*`, `LICENSE*`, `.gitignore`.\n Otherwise: **code-or-config**.\n 3. If next stage is `test` AND change set is docs-only:\n - Transition: `pending → skipped`\n ```bash\n python3 \u003Cruntime>\u002Fagenteam_rt.py transition --run-id \u003Crun_id> \\\n --stage \u003Cstage> --to skipped\n python3 \u003Cruntime>\u002Fagenteam_rt.py set-stage-field --run-id \u003Crun_id> \\\n --stage \u003Cstage> --field skip_reason --value \"docs_only_change\"\n python3 \u003Cruntime>\u002Fagenteam_rt.py set-stage-field --run-id \u003Crun_id> \\\n --stage \u003Cstage> --field skipped_at --value \"\u003CISO timestamp>\"\n python3 \u003Cruntime>\u002Fagenteam_rt.py event append --run-id \u003Crun_id> \\\n --type stage_completed --stage \u003Cstage> \\\n --data '{\"result\": \"skipped\", \"reason\": \"docs_only_change\"}'\n ```\n - Announce: \"⊘ Skipping test stage (docs-only change, no tests needed)\"\n - Continue to next stage (review) or completion\n 4. Otherwise: dispatch normally (continue to step a below)\n\n **Rules:**\n - Never skip `implement` or `review` stages\n - Never skip in collaborative discovery mode\n - Only skip `test` stage, only for docs-only changes\n - Config files (*.yaml, *.toml, *.json) are NOT docs-only\n\n a. Get dispatch plan:\n python3 \u003Cruntime>\u002Fagenteam_rt.py dispatch \u003Cstage> \\\n --task \"\u003Ctask>\" --run-id \u003Crun_id>\n\n b. Read the dispatch plan (JSON). Two formats:\n\n **Flat dispatch (isolation: branch or worktree):**\n - dispatch: list of roles to launch serially\n - blocked: roles waiting for write lock\n - gate: human or auto\n\n **Grouped dispatch (isolation: none \u002F scoped parallel):**\n - groups: list of parallel-safe writer groups\n - read_only: list of read-only roles\n - gate: human or auto\n\n b2. Transition stage to dispatched:\n ```bash\n python3 \u003Cruntime>\u002Fagenteam_rt.py transition --run-id \u003Crun_id> \\\n --stage \u003Cstage> --to dispatched\n ```\n\n b3. Announce stage start to user:\n\n Format: \"[N\u002Ftotal] Assigning @Role to \u003Cverb>...\"\n\n Use the stage name to select the verb:\n | Stage | Verb |\n |-----------|------|\n | research | \"investigate\" |\n | strategy | \"define strategy\" |\n | design | \"design the solution\" |\n | plan | \"write the implementation plan\" |\n | implement | \"implement the design\" |\n | test | \"write tests\" |\n | review | \"review the implementation\" |\n\n For custom stage names not in this table, use the stage name as the verb.\n\n Adjust numbering to the actual stage count (profiles may skip stages).\n Use the stage's assigned role name from the dispatch plan.\n\n If a human gate is upcoming at this stage, append:\n \"(approval required after this stage)\"\n\n Example: \"[3\u002F5] Assigning @Dev to implement the design...\"\n\n c0. Check HOTL skill eligibility (before launching any subagent):\n\n For each role about to be launched:\n ```bash\n python3 \u003Cruntime>\u002Fagenteam_rt.py hotl-skills \\\n --run-id \u003Crun_id> --stage \u003Cstage> --role \u003Crole>\n ```\n - For each entry in the `eligible[]` array: append the `inject`\n text to the subagent's task instructions.\n - If `hotl_available` is false or `eligible` is empty: no injection,\n launch with default role instructions.\n\n c0.5. Build a role-context block for each launched role:\n\n Gather the role's static contract:\n ```bash\n python3 \u003Cruntime>\u002Fagenteam_rt.py roles show \u003Crole>\n ```\n Use the returned `handoff_contract` to tell the role what it is expected\n to consume, produce, and who reads its output next.\n\n Gather the stage's dynamic verification context:\n ```bash\n python3 \u003Cruntime>\u002Fagenteam_rt.py verify-plan \u003Cstage> --run-id \u003Crun_id>\n ```\n If a verify command is present, append it to the role context block.\n This is especially important for QA so it writes tests the pipeline can\n actually discover and run.\n\n Resolve artifact paths for prior-stage artifact discovery:\n ```bash\n python3 \u003Cruntime>\u002Fagenteam_rt.py artifact-paths\n ```\n Use the returned `paths` map to scan for prior-stage artifacts.\n This auto-detects standalone vs HOTL mode:\n - Standalone: architect → `docs\u002Fdesigns\u002F`, pm → `docs\u002Fstrategies\u002F`\n - HOTL: architect → `docs\u002Fplans\u002F`, dev plans → `.\u002F`\n\n Do NOT hardcode directory paths — always use the runtime-resolved\n paths so the context block is correct in both modes.\n\n Include the most relevant prior-stage artifacts or summaries already\n collected in step d2. Keep this block short and specific.\n\n c. Launch agents:\n\n **If plan has flat \"dispatch\" key (serial mode):**\n - For each role in dispatch list:\n - If mode is \"read\": launch as Codex subagent (can run in parallel\n with other readers)\n - If mode is \"write\": launch as Codex subagent (serial by default)\n\n **If plan has \"groups\" key (scoped parallel mode):**\n - Capture baseline: BASELINE=$(git rev-parse HEAD)\n - Launch read_only roles as parallel subagents (alongside any group)\n - For each group in order:\n 1. Launch all roles in the group as parallel subagents\n Instruct agents: \"Write your changes but do NOT run git add or\n git commit. The controller handles commits.\"\n 2. Wait for all agents in the group to complete\n 3. Serialized commit capture (controller does this, NOT agents):\n For each writing role in the group:\n - git add \u003Cfiles matching role's write_scope>\n - git commit -m \"[ateam:\u003Crole>] \u003Cstage>: \u003Csummary>\" (if staged files exist)\n 4. Check for unclaimed files: git status --porcelain\n If any remain -> containment violation\n 5. Run scope audit:\n python3 \u003Cruntime>\u002Fagenteam_rt.py scope-audit \\\n --run-id \u003Crun_id> --stage \u003Cstage> --baseline $BASELINE\n 6. If audit fails:\n - Save the complete diff as\n `.agenteam\u002Fruns\u002F\u003Crun_id>\u002F\u003Cstage>\u002Fscope-violation.patch` before\n taking any recovery action.\n - Log: \"Scope containment violation. Preserved evidence and stopped\n the stage; no checkout content was reset.\"\n - Do not modify or discard the dirty checkout. A serial replay must\n start in a new clean branch\u002Fworktree from `$BASELINE`.\n - Ask before creating that replay because it may duplicate\n non-idempotent role work. Break out of the group loop.\n - The agent file is at the path in the dispatch plan (e.g.,\n .codex\u002Fagents\u002Farchitect.toml)\n - Pass the task description and any outputs from previous stages\n as context to the agent\n - Append the role-context block from step c0.5 to the task prompt so\n static role instructions are paired with run-specific context\n - You must launch actual Codex subagents. Do not keep the work in the\n lead agent and do not simulate what a role \"would\" say.\n\n d. Emit stage_dispatched event and progress snapshot:\n ```bash\n python3 \u003Cruntime>\u002Fagenteam_rt.py event append --run-id \u003Crun_id> \\\n --type stage_dispatched --stage \u003Cstage> \\\n --data '{\"roles\": [\"\u003Crole1>\", ...], \"isolation\": \"\u003Cmode>\"}'\n python3 \u003Cruntime>\u002Fagenteam_rt.py status \u003Crun_id> --progress\n ```\n Display the progress snapshot to the user so they can see\n pipeline progress during execution.\n\n **Progress emission rule:** After every stage transition (dispatch,\n verify result, gate decision, completion, skip), emit the progress\n snapshot via `status --progress`. This gives users in-thread\n visibility into pipeline state without requiring a separate\n terminal or polling loop.\n\n d2. Collect outputs:\n - Gather each role's output\n - Store as context for subsequent stages\n\n d3. Announce stage completion to user:\n\n On success:\n \"@Role completed \u003Cstage> -- \u003Cone-line outcome summary>. \u003Cforward reference>\"\n\n Examples:\n \"@Researcher completed research -- report on auth patterns written to docs\u002Fresearch\u002F. @Pm strategizes next.\"\n \"@Architect completed design -- OAuth2+PKCE recommended, 3 approaches documented. @Dev implements next.\"\n \"@Dev completed implement -- added 4 files in src\u002Fauth\u002F, 230 lines. @Qa tests next.\"\n \"@Qa completed test -- 12 tests added, all passing. @Reviewer reviews next.\"\n \"@Reviewer completed review -- PASS, no blocking findings.\"\n\n On failure:\n \"@Role failed at \u003Cstage> -- \u003Cone-line failure reason>\"\n\n Rules:\n - One line per stage, outcome-shaped\n - Include artifact paths or counts when available\n - Include forward reference to next stage's role (except for the final stage)\n - Never dump raw output, diffs, or full test logs\n\n e. Verify stage (if configured):\n - Get verify plan:\n python3 \u003Cruntime>\u002Fagenteam_rt.py verify-plan \u003Cstage> --run-id \u003Crun_id>\n - If verify is null: skip to gate check (see transition note below).\n - Transition to verifying:\n python3 \u003Cruntime>\u002Fagenteam_rt.py transition --run-id \u003Crun_id> \\\n --stage \u003Cstage> --to verifying\n - Execute verification in the isolated workspace:\n bash \u003Cplugin-dir>\u002Fscripts\u002Fverify-stage.sh run \"\u003Cverify>\" --cwd \"\u003Ccwd>\"\n - Record result:\n python3 \u003Cruntime>\u002Fagenteam_rt.py record-verify --run-id \u003Crun_id> \\\n --stage \u003Cstage> --result pass|fail --output \"\u003Coutput>\"\n - If passed:\n python3 \u003Cruntime>\u002Fagenteam_rt.py transition --run-id \u003Crun_id> \\\n --stage \u003Cstage> --to passed\n Continue to gate check.\n - If failed:\n python3 \u003Cruntime>\u002Fagenteam_rt.py transition --run-id \u003Crun_id> \\\n --stage \u003Cstage> --to failed\n - If failed and attempts \u003C max_retries:\n Log \"Verification failed (attempt N\u002Fmax). Re-dispatching...\"\n Check verify-plan for rework_to:\n * If rework_to is set (cross-stage repair):\n Dispatch rework_roles as REPAIR (no verify\u002Fgate on repair action).\n Record: record-verify --rework-stage \u003Crework_to>\n Re-run THIS stage's verify (not the rework stage's).\n * If rework_to is not set (same-stage retry):\n Determine repair role(s):\n - Single-role stage: re-dispatch that role\n - Multi-role stage: match failing files to write_scope\n - All-read-only stage: fail-fast (no repair possible)\n Before re-dispatching, re-run hotl-skills for each repair role:\n ```\n python3 \u003Cruntime>\u002Fagenteam_rt.py hotl-skills \\\n --run-id \u003Crun_id> --stage \u003Cstage> --role \u003Crepair_role>\n ```\n The stage status is now \"failed\" or \"rework\", so\n systematic-debugging becomes eligible. Append any eligible\n inject text to the repair subagent's instructions.\n Re-dispatch repair role(s) with failure output as context\n Go back to verify\n - If failed and attempts >= max_retries (or no legal repair role):\n Log \"Verification failed after N attempts.\"\n Offer non-destructive recovery:\n result = agenteam_rt.py stage-baseline --run-id \u003Crun_id> \\\n --stage \u003Cstage> --action rollback\n If result.allowed:\n Show: git diff --stat \u003Cbaseline>..HEAD\n Save the current diff to\n `.agenteam\u002Fruns\u002F\u003Crun_id>\u002F\u003Cstage>\u002Ffailed-attempt.patch`.\n Ask: \"Create a clean recovery branch\u002Fworktree from the baseline?\"\n Never discard the current checkout automatically. Recovery runs in\n the new isolated workspace, and the preserved patch remains reviewable.\n If not result.allowed (isolation:none):\n Log: \"Rollback not available in scoped parallel mode.\"\n Show failure output to user. Do NOT advance.\n\n **Long-running harness invariant:** Treat runtime state as authoritative.\n Persist the active attempt, `thread_id`, last heartbeat, wall\u002Fidle budgets,\n retry count, and stop reason. Emit `status --progress` at least once per\n heartbeat interval. After controller interruption, invoke `$ateam:resume`;\n do not silently launch a replacement agent.\n\n f. Gate criteria check (if stage has criteria):\n result = agenteam_rt.py gate-eval --run-id \u003Crun_id> --stage \u003Cstage>\n If result.passed: continue to gate.\n If result.failed:\n Log: \"Gate criteria failed: \u003Cfailed_criteria>\"\n Escalate to human: \"Stage exceeded criteria. Approve anyway? (yes\u002Fno)\"\n If approved:\n python3 \u003Cruntime>\u002Fagenteam_rt.py record-gate --run-id \u003Crun_id> \\\n --stage \u003Cstage> --gate-type criteria_override \\\n --result approved --criteria-failed \"\u003Clist>\" \\\n --override-reason \"\u003Cuser's reason>\"\n Continue to gate.\n If rejected: mark stage failed.\n\n g. Gate check and stage completion transitions:\n\n **Transition paths (all four cases from default pipeline):**\n - verify + gate (e.g., design): dispatched → verifying → passed → gated → completed\n - verify + no gate (e.g., implement): dispatched → verifying → passed → completed\n - no verify + gate (e.g., strategy, plan): dispatched → passed → gated → completed\n - no verify + no gate (e.g., research): dispatched → completed\n\n **If verify was null (no verify configured):**\n - If gate is \"human\" or \"reviewer\":\n python3 \u003Cruntime>\u002Fagenteam_rt.py transition --run-id \u003Crun_id> \\\n --stage \u003Cstage> --to passed\n - If gate is \"auto\" or no gate:\n python3 \u003Cruntime>\u002Fagenteam_rt.py transition --run-id \u003Crun_id> \\\n --stage \u003Cstage> --to completed\n (skip gate check, stage is done)\n\n **Gate evaluation (when gate is not \"auto\"):**\n - python3 \u003Cruntime>\u002Fagenteam_rt.py transition --run-id \u003Crun_id> \\\n --stage \u003Cstage> --to gated\n - If gate is \"human\":\n Announce: \"Waiting for your approval at the \u003Cstage> gate.\"\n Pause and show the user a summary of the\n stage output. Ask: \"Approve this stage? (yes\u002Fno\u002Fdetails)\"\n - If gate is \"reviewer\" or \"qa\": dispatch the gate agent as a\n SEPARATE subagent (never the stage actor). Parse verdict\n (PASS\u002FBLOCK). Record via record-gate. If BLOCK, pause for human.\n - Record gate result:\n python3 \u003Cruntime>\u002Fagenteam_rt.py record-gate --run-id \u003Crun_id> \\\n --stage \u003Cstage> --gate-type \u003Ctype> --result approved|rejected\n\n **After gate approval:**\n - python3 \u003Cruntime>\u002Fagenteam_rt.py transition --run-id \u003Crun_id> \\\n --stage \u003Cstage> --to completed\n\n **After gate rejection:**\n - python3 \u003Cruntime>\u002Fagenteam_rt.py transition --run-id \u003Crun_id> \\\n --stage \u003Cstage> --to rejected\n\n **On re-dispatch (retry after failure or rejection):**\n - python3 \u003Cruntime>\u002Fagenteam_rt.py transition --run-id \u003Crun_id> \\\n --stage \u003Cstage> --to dispatched\n\n f0. Emit stage_completed event (after verify passed + gate approved):\n ```bash\n python3 \u003Cruntime>\u002Fagenteam_rt.py event append --run-id \u003Crun_id> \\\n --type stage_completed --stage \u003Cstage> \\\n --data '{\"result\": \"passed\"}'\n ```\n On stage failure (verify exhausted, gate rejected, or no repair):\n ```bash\n python3 \u003Cruntime>\u002Fagenteam_rt.py event append --run-id \u003Crun_id> \\\n --type stage_completed --stage \u003Cstage> \\\n --data '{\"result\": \"failed\", \"reason\": \"\u003Cfailure reason>\"}'\n ```\n\n f. Handoff:\n - Pass the collected outputs as context to the next stage\n - Design output feeds into plan stage\n - Plan output feeds into implement stage\n - Implement output feeds into test stage\n - All outputs feed into review stage\n```\n\nDo not mark the run complete after `implement`. Unless the user explicitly\nasks to stop early, continue through `test` and `review`, and surface the\nreviewer's findings before calling the pipeline done.\n\n### 6b. Final Verification (after the last configured stage)\n\nAfter all stages complete, run final verification:\n\n```\n1. Get final verify plan:\n python3 \u003Cruntime>\u002Fagenteam_rt.py final-verify-plan --run-id \u003Crun_id>\n\n2. If policy is \"unverified\":\n Print warning: \"No final verification commands configured or detected.\n AgenTeam cannot vouch for this run.\"\n Skip to completion.\n\n3. Run each command in sequence:\n bash \u003Cplugin-dir>\u002Fscripts\u002Fverify-stage.sh run \"\u003Ccommand>\" --cwd \"\u003Ccwd>\"\n\n4. If all pass: continue to completion.\n\n5. If any fail and retries remain:\n Determine repair role(s) from failure context:\n * Failing test files (tests\u002F**) -> dispatch qa\n * Failing source files (src\u002F**) -> dispatch dev\n * Both -> dispatch dev + qa\n * Unclear -> dispatch dev as fallback\n Re-dispatch repair role(s) with failure output\n Re-run all final_verify commands\n\n6. If still failing:\n block mode: mark run failed, keep branch open, print failure summary\n warn mode: print \"TESTS FAILING\" warning, complete but do not suggest merge\n```\n\nThis is non-negotiable. Final verification is the mechanism that lets\nAgenTeam vouch for its work. It runs AFTER the review stage, not before.\n\n### 6c. Run Report (always, at completion or failure)\n\nAfter final verification (or when pipeline stops due to failure):\n\n```\n1. Generate report:\n python3 \u003Cruntime>\u002Fagenteam_rt.py run-report --run-id \u003Crun_id>\n\n2. Render the JSON as markdown and write to the report_path\n (typically .agenteam\u002Freports\u002F\u003Crun-id>.md)\n\n3. Show report summary to user\n\n4. Log: \"Run report saved to \u003Creport_path>\"\n```\n\nReports are local diagnostics (gitignored). They are never auto-committed.\n\n### 7. HOTL Wrapper Pipeline\n\nWhen pipeline mode is `hotl`, AgenTeam acts as the outer orchestrator\nand composes HOTL skills for each stage:\n\n```\na. DESIGN STAGE:\n - Resolve roles: agenteam-rt dispatch design -> {architect}\n - Invoke HOTL brainstorming skill with architect's system instructions\n injected as context\n - HOTL drives the design conversation\n - Collect design output\n\nb. PLAN STAGE:\n - Resolve roles: agenteam-rt dispatch plan -> {architect}\n - Invoke HOTL writing-plans skill\n - HOTL generates the workflow file\n - Gate: human approval of the plan\n\nc. IMPLEMENT + TEST STAGE:\n - Resolve roles: agenteam-rt dispatch implement -> {dev}\n - Resolve roles: agenteam-rt dispatch test -> {qa}\n - Invoke HOTL loop-execution or subagent-execution\n - HOTL executes workflow steps\n - Implementer and qa agents are the workers\n - Write policy enforced: serial by default\n\nd. REVIEW STAGE:\n - Resolve roles: agenteam-rt dispatch review -> {reviewer}\n - Invoke HOTL code-review skill with reviewer agent\n - Gate: human approval\n```\n\n**Key principle:** AgenTeam manages role selection and write policy\nbetween phases. HOTL manages execution within each phase. AgenTeam\nnever modifies HOTL internals.\n\n### 8. Completion\n\nOnly after the final configured stage completes:\n- Emit run_finished event:\n ```bash\n python3 \u003Cruntime>\u002Fagenteam_rt.py event append --run-id \u003Crun_id> \\\n --type run_finished --data '{\"status\": \"completed\"}'\n ```\n- Announce pipeline result:\n On success: `Pipeline complete: \u003CN>\u002F\u003CN> stages passed.`\n On failure: `Pipeline stopped at \u003Cstage>: \u003Creason>. Completed \u003CN>\u002F\u003Ctotal> stages.`\n- Show a summary of what each role produced\n- Show the final state: `python3 \u003Cruntime>\u002Fagenteam_rt.py status`\n- Suggest next steps (commit, create PR, etc.)\n- Persist run history for future context:\n ```bash\n python3 \u003Cruntime>\u002Fagenteam_rt.py history append --run-id \u003Crun_id>\n ```\n This saves the run summary + lessons learned for injection into future\n runs. Only called on completed or failed runs — not stopped\u002Fabandoned.\n\nOn unrecoverable pipeline failure:\n- Emit run_finished event:\n ```bash\n python3 \u003Cruntime>\u002Fagenteam_rt.py event append --run-id \u003Crun_id> \\\n --type run_finished --data '{\"status\": \"failed\"}'\n ```\n- Persist run history (failures have useful lessons too):\n ```bash\n python3 \u003Cruntime>\u002Fagenteam_rt.py history append --run-id \u003Crun_id>\n ```\n\n## Error Handling\n\n- If a stage fails, stop the pipeline and show the error\n- If a role agent fails, report which role failed and at what stage\n- If write policy blocks a role, show the block reason and wait\n- If HOTL is configured but not available, fall back to standalone\n with a warning\n\n## Runtime Path Resolution\n\nResolve the AgenTeam runtime:\n1. If running from the plugin directory: `.\u002Fruntime\u002Fagenteam_rt.py`\n2. If installed as a Codex plugin: `\u003Cplugin-install-path>\u002Fruntime\u002Fagenteam_rt.py`\n",{"name":5,"description":7},"main","2b63f856ce19c2a797929cacabd9e0fc936812fa","plugins\u002Fyimwoo\u002Fcodex-agenteam\u002Fskills\u002Frun",491,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins","https:\u002F\u002Fhol.org\u002Fplugins\u002Fbest-codex-plugins","https:\u002F\u002Fgithub.com\u002Fhashgraph-online","https:\u002F\u002Fhol.org","Open-source standards and developer tools for interoperable AI agents: discovery, identity, communication, payments, privacy and security.","2026-11-14 14:06:13",{"source":8,"skillName":5,"commands":43,"prompt":53,"zipAvailable":54},[44,47,50],{"tool":45,"command":46},"npx","npx skills add hashgraph-online\u002Fawesome-codex-plugins --skill run",{"tool":48,"command":49},"bunx","bunx skills add hashgraph-online\u002Fawesome-codex-plugins --skill run",{"tool":51,"command":52},"pnpm","pnpm dlx skills add hashgraph-online\u002Fawesome-codex-plugins --skill run","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fyimwoo\u002Fcodex-agenteam\u002Fskills\u002Frun\u002FSKILL.md",true,[],[57,65,72,79,106,131],{"skillNo":58,"name":59,"nameZh":6,"description":60,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":61,"categories":62,"keywords":63,"publishedAt":64},"01M746ZWACVKMZ1BJXJZHYJSSX","migrate-to-e2e","Moves an existing Playwright, Cypress, Selenium, Appium, Detox, Maestro, or TesterArmy suite to e2e one slice at a time, with the old suite running beside the new one until each ported test is proven. Keeps a MIGRATION.md progress file so any later session resumes where the last stopped. Optionally plants a defect to show both suites catch it. Use for \u002Fmigrate-to-e2e, \"migrate our tests to e2e\", \"port these Maestro flows\", \"move our TesterArmy tests\", or when a project has an e2e config and an older suite still running.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fmigrate-to-e2e\u002FSKILL.md",[],[],"2026-11-11 15:11:14",{"skillNo":66,"name":67,"nameZh":6,"description":68,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":69,"categories":70,"keywords":71,"publishedAt":64},"01M746ZPTAX1Q0FBKAB1CYND7E","e2e","Writes, runs, and debugs end-to-end tests for web and mobile apps with e2e, the agentic test runner, which mixes agent.act goals with exact locator assertions on a Playwright browser or an iOS or Android device. Also drives a project's running app live over the e2e MCP server to look at a screen, check a UI change, take a screenshot or record a video, and try a locator; and runs bug bashes, parallel e2e explore runs with each bug proven by a repro test. Use when a project depends on e2e or has an e2e.config.ts, when asked for end-to-end, browser, mobile, or agentic UI tests, to check a change in the running app, to QA or bug bash an app or branch, or when an e2e run fails.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fe2e\u002FSKILL.md",[],[],{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":78,"publishedAt":64},"01M746ZJN784HVHMDP9MQGCSGG","create-verification-skill","Generate a project-local verify-\u003Capp> skill on top of e2e, so any coding agent can launch the app, check it is worth driving, exercise a feature the way a user does, keep evidence, and bug bash it. Writes the skill, a feature map with one explore charter per feature, and proves it once. Use for \u002Fcreate-verification-skill, \"make a verification skill for this repo\", or when a project has no scripted way to prove UI behavior.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fcreate-verification-skill\u002FSKILL.md",[],[],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":85,"publishedAt":27},"01M716A6ETNB9B1SQ3GXZC75VR","deja-search","deja-vu memory — search the user's past AI coding sessions with the deja CLI. Holds what they already settled and never wrote into the repo (naming rules, banned or already-tried tools, required checks before merge, preferred values, who owns what). Use before your first edit in a task, before you call a change done or ready to merge, before you recommend a tool, library, design or reviewer, before re-debugging an error that may already be solved, when they say 'didn't we fix this before', 'what did we decide about X' or 'I already have that', and before telling them something on this machine does not exist.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-search\u002FSKILL.md",[],[86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105],"search","deja search","never","error","ready","memory","re","decide","fix","design","debugging","when","you","done","reviewer","io","change","cli","merge","past",{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":112,"publishedAt":27},"01M716A3J2W5SENSE9VGMXB375","deja-reflect","End-of-session reflection and memory curation with deja-vu. Review what was decided, what commands broke and what repaired them, and record durable project rules or decisions with deja remember so the next session starts with them.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-reflect\u002FSKILL.md",[],[113,114,115,101,116,117,118,119,120,121,122,123,124,125,91,126,127,128,129,130],"deja reflect","reflect","review","with","record","github","next","https","node","Rules","decisions","brew","remember","project rules","project","session","end","reflection",{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":148,"publishedAt":27},"01M715T3RR4BAYSR57HPPTJ0PF","revid","Make, edit, export and post AI videos with Revid (revid.ai) through the Revid MCP server. Use whenever the user wants a short-form or long-form video made (from an idea, a script, a URL, an article, a PDF, a tweet, a product page, their own clips, or a song), wants to find what is going viral on TikTok, YouTube, Instagram or X before making something, wants to edit or re-export an existing Revid project, generate a standalone AI image or clip, make a series episode, or publish and schedule a finished video to connected social accounts. Covers setup (hosted MCP with OAuth, or an API key), the 36 tools, credits, polling and the rules for publishing. Routes to the more specific revid-* skills when one fits.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftmakersas\u002Frevid-skills\u002Fskills\u002Frevid\u002FSKILL.md",[137,142,145],{"categoryNo":138,"categoryName":139,"taxonomyType":140,"taxonomyTypeDesc":141},"01JBSEEDCAT000000000000016","图像与多媒体","SCENARIO","使用场景",{"categoryNo":143,"categoryName":144,"taxonomyType":140,"taxonomyTypeDesc":141},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":146,"categoryName":147,"taxonomyType":140,"taxonomyTypeDesc":141},"01JBSEEDCAT000000000000010","后端与接口",[133,149,150,151,23,152,153,127,154,92,155,156,157,158,97,159,160,161,162,163],"URL","Video","short-form","PDF","viral","tiktok","short","social","MCP","song","image","mcp server","schedule","api","publish"]