Loom Plan Execution

/loom-plan-execution

Guide-first plan execution skill.

Mission

This skill does not hide package setup behind its own template. It first points the user to the package and guide surface that matches the current CI/CD-managed skill package version block, then routes execution through the applicable Loom Agent Execution Orchestrator runtime surface.

Once the skill-bound package version or runtime source is chosen, this skill must first prove that the selected Loom Agent Execution Orchestrator runtime for that source is runnable and can emit a fresh dotnet ao.dll --guide [--lang <language>] result from that runtime. Before that proof exists, do not proceed to planning, authoring, validation, compile, prompt-plan, prompt-replan, run, resume, or any downstream input collection. Once that guide result exists, treat it as a hard governance handoff back onto the corresponding published AO package runtime surface for official execution. Do not let --guide become a detour that drifts back to repository builds, hand-assembled runtimes, or other non-governed paths.

When the caller is explicitly debugging this skill inside the current repository and asks to use the current source tree, this skill may build and use the local Loom Agent Execution Orchestrator repo output instead of downloading package assets. That local-source override is for repository debugging only and does not create a second official execution authority.

This skill also enforces Loom Agent Execution Orchestrator-strong governance for official plan execution. In that governance model, Loom Agent Execution Orchestrator is the only official execution authority for this skill, only explicit dotnet ao.dll run and dotnet ao.dll resume count as official skill runs, and any direct non-Loom Agent Execution Orchestrator path stays outside official skill execution.

Business-outcome-first rule: when the caller request or plan content (for example testplan.md) clearly targets business execution outputs, this skill must treat that business outcome as the primary completion target and must not drift into AO meta-execution-only activity.

Read This First

<!-- skill-package-version-block:start -->

• Current published AO package runtime version: 0.2.126.
• This block is refreshed by the publish workflows whenever AO package versions change, so the skill contract stays aligned with the latest published stable package set.

<!-- skill-package-version-block:end -->

Follow the current skill package version block first, then derive the matching package surface:

• When the current skill package version is stable, use released references: reference/packages.released.md and reference/ao-guide.released.md
• When the current skill package version is prerelease, use beta references: reference/packages.beta.md and reference/ao-guide.beta.md

• Workflow designer subagent: assets/agents/loom-plan-execution-workflow-designer.agent.md

Input Contract

• Preferred input: a rich plan with at least 10 non-empty lines
• Fallback input: a file path to a detailed plan document
• Runtime version authority: the current CI/CD-managed skill package version block; derive released versus beta from that bound version when needed
• Optional input: guide language flag (--lang <language>) when the runtime guide call needs explicit language selection
• Optional input: runtime source mode (package-channel by default, or explicit repo-src-debug when debugging this skill inside the current repository and intentionally using current source output)
• Optional input: explicit audit output root

If the request is too short, redirect the user into plan mode or require a detailed plan file before proceeding.

Default Assumptions

Apply these defaults during Loom Agent Execution Orchestrator-based plan execution:

• Loom Agent Execution Orchestrator is the only official execution authority for this skill; only explicit dotnet ao.dll run and dotnet ao.dll resume count as official skill runs.
• Business-outcome-first is mandatory when plan content clearly targets business deliverables; runtime/meta-only mode requires explicit user intent.
• In package-channel mode, restore the full Loom Agent Execution Orchestrator runtime bundle that matches the current skill package version block into one unified runtime directory, enforce startup-contract preflight, and use explicit launch mode for deterministic host binding.
• In Windows PowerShell 5.1 package-channel mode, treat .nupkg as ZIP content and do not use Expand-Archive directly on the .nupkg; use ZIP APIs or an equivalent ZIP-based extraction path.
• In Windows PowerShell 5.1, add -UseBasicParsing to package-channel HTTP probes that use Invoke-WebRequest or Invoke-RestMethod so runtime acquisition does not stall on legacy browser-engine prompts.
• If runtime extraction, startup-contract checks, or guide execution fail, stop immediately and keep runtime_preflight_result and guide-refresh evidence in a failed state. Do not write success proof or exported guide files from failed commands.
• In repo-src-debug mode, build and use the current repository Loom Agent Execution Orchestrator output only as an explicit debug override.
• Keep checked-in source plans/snapshots immutable and keep mutable runtime state under session_dir or explicit execution-output roots.

Detailed assumptions, startup contracts, output matrices, and anti-drift rules live in the reference docs:

• Local skill reference: reference/ao-skill-reference.md

Workflow generation or revision for this skill must use the local workflow-designer subagent with context-rich relative links, not a freeform generic agent call:

• assets/agents/loom-plan-execution-workflow-designer.agent.md

Runtime Flow

0. Classify intent first: business execution versus explicit runtime verification. Lock business-first mode when objectives clearly request business deliverables. 1. Confirm the current skill-bound package version, derive channel from its version shape when needed, and confirm runtime source (package-channel or explicit repo-src-debug). 2. Prepare runtime:

• repo-src-debug: build Loom Agent Execution Orchestrator from src/dotnet/Techne.Loom.AgentOrchestrator.
• package-channel: restore the full Loom Agent Execution Orchestrator bundle into one unified runtime, use ZIP-based extraction for .nupkg on Windows PowerShell 5.1, run startup-contract preflight, and use explicit launch mode.

3. Prove the selected runtime can run and capture a fresh --guide result from that runtime. 4. Only after that guide result exists, run planning surfaces (prompt-plan) and capture required prompt blocks. 5. When creating or revising a workflow, invoke the local workflow-designer subagent and give it the relevant skill files, guide files, plan files, and audit artifacts through relative links. 6. Author a WorkflowInstance outside skill paths, then run compile. 7. Run Loom Agent Execution Orchestrator with that WorkflowInstance when graph continuity matters. 8. On blocked state, use payload signals plus prompt-replan to update seam nodes, then resume with structured envelope payload. 9. Repeat replan/resume until Loom Agent Execution Orchestrator reaches completed state. 10. Report completion only when Loom Agent Execution Orchestrator is completed and requested business deliverables are verifiable.

For AO workflow design and AO weave-out planning, prefer existing capable subagents whenever they can already complete the weave-out goal instead of emitting generic agent placeholders.

Operational details for prompt blocks, payload conventions, and blocked-state handling are defined in reference docs.

Required Outputs

• bound runtime version confirmation with derived released/beta evidence and matching canonical links
• runtime source selection and version-derived channel resolution metadata
• package-channel runtime facts: version, bundle list, unified runtime directory, preflight result, and launch mode
• package-channel runtime acquisition facts when Windows PowerShell 5.1 is involved: ZIP-based .nupkg extraction path, HTTP probe mode, and fail-fast evidence when extraction or guide generation fails
• workflow/session/event paths and audit artifact links
• required think-out-loud fields for runtime and audit updates
• business deliverable verification summary when business-first mode applies

For the full output matrix and field-level contracts, use reference docs.

Prohibited Results

Reject or mark invalid any execution result that says or implies any of these:

• AO is optional for official skill execution
• AO and another path are parallel official execution modes for this skill
• AO runtime artifacts alone are accepted as final completion when the caller explicitly requested business outputs
• business-output requests are silently downgraded to runtime/meta-only execution without explicit user approval
• compile, --guide, or helper shell steps are normal skill run modes
• compile, --guide, prompt-plan, prompt-replan, or helper shell steps are normal skill run modes
• non-AO output can count as official skill execution history
• non-AO tests can count as official skill execution evidence
• prose flow or examples are official execution authority by themselves

Completion Criteria

Do not treat execution as properly governed until all of these conditions hold:

• only explicit dotnet ao.dll run or dotnet ao.dll resume counts as an official skill run
• dotnet ao.dll compile, dotnet ao.dll --guide, dotnet ao.dll prompt-plan, and dotnet ao.dll prompt-replan are documented as preparation, validation, or authority-supporting surfaces only
• skill-level history only comes from AO workflow state, session state, event logs, or audit artifacts
• skill-level checklist only comes from AO workflow nodes, frontiers, transitions, blocked states, and resume points
• skill-level run map only comes from the AO runtime workflow_file, next_frontier, blocked state, and audit artifacts
• skill-level evidence only comes from AO-owned runtime state and audit artifacts
• non-AO tests do not count as official skill execution evidence
• prose flow and helper command examples are explanatory only, not execution authority
• when caller objectives explicitly request business outputs, AO completion state alone is insufficient without the corresponding business deliverables

Detailed prohibited/acceptance examples are maintained in reference docs.

Mission

You are the dedicated workflow designer subagent for /loom-plan-execution.

Your only job is to design or revise AO workflow JSON with enough detail that each node is a single reviewable responsibility and no node hides a visible multi-step subflow.

You must run independently from repository-global docs once this file is loaded. Use the linked local skill documents as the authoritative context pack for this skill.

Context Pack

Read these relative references as your local authority set before designing:

• ../../SKILL.md
• ../../reference/ao-skill-reference.md
• ../../reference/ao-guide.released.md
• ../../reference/ao-guide.beta.md
• ../../reference/packages.released.md
• ../../reference/packages.beta.md

If a prompt hands you a concrete workflow file, plan file, audit artifact, or guide export path, treat those files as higher-priority run context layered on top of the authority set above.

AO-Specific Design Target

AO is for exploratory orchestration under uncertainty.

Design around these AO-specific facts:

• AO official execution surfaces are dotnet ao.dll run and dotnet ao.dll resume.
• compile, --guide, prompt-plan, and prompt-replan are preparation or authority-supporting surfaces, not official run modes.
• Before any later planning, authoring, validation, compile, prompt-plan, prompt-replan, run, resume, or downstream input collection nodes, the graph must prove that the selected AO runtime for the chosen runtime source is runnable and can emit a fresh dotnet ao.dll --guide result from that runtime.
• AO weaves out at control seams and returns blocked payloads such as boundary_reason, pending_requirements, next_frontier, and weave_out_request.
• AO resume must preserve seam continuity through transition_id, correlation_key, and payload.
• AO may carry caller convention metadata under payload.plan_meta, but that is not a substitute for explicit graph structure.

Node Granularity Rules

Every node must satisfy all of these:

• One node, one visible responsibility.
• No node may imply “do a multistep plan” or “figure out the rest.”
• If the instruction could naturally be split into two reviewable actions, split it.
• If a node both gathers context and makes a policy decision, split it.
• If a node both evaluates and writes, split it unless the write is the direct atomic result of that single evaluation.
• If a node both chooses a weave-out route and describes external execution, split the route decision from the external-action handoff.

Weave-Out Rules

AO weave-out design must be explicit and detailed.

For every branch that can weave out:

• If an existing agent or subagent can already complete the weave-out goal, prefer that subagent route over a generic agent-shaped placeholder node.
• Give the branch a concrete reason and explicit blocked seam.
• Make the blocked hint detailed enough that the caller knows the exact next action.
• When possible, point the hint to concrete local references using relative links.
• If the weave-out depends on a guide rule, cite the local guide file and the exact section title or nearby heading in prose.
• If the weave-out depends on a workflow or plan artifact, name the exact expected file path and the expected payload shape.
• If the weave-out depends on business deliverables, state which deliverable is missing and why AO cannot continue without it.

Required AO Weave-Out Families To Consider

When relevant, explicitly model these AO seam families rather than hiding them inside broad nodes:

• clarification-required seams
• tool-probe-required seams
• delegation-required seams
• weave-out-required seams for external comparison, planning, or decision work
• replan-required seams after a failed or stale frontier choice
• completion-claim seams when business evidence is still missing

If a requested workflow could hit one of these families, either model it as a node or explain why it does not apply.

Output Requirements

When you generate a workflow or workflow revision, ensure it includes:

• explicit node ids and transition ids
• explicit weave-out seam nodes or transitions
• detailed skill_hint / blocked-action intent in node descriptions or attached artifacts
• enough node detail that Mermaid and audit analysis show real operational structure
• no silent dependency on external docs beyond the context pack and prompt-provided files

Output Hint Guidance

When producing a workflow template proposal, also provide guidance for these companion outputs when relevant:

• workflow JSON path
• Mermaid review artifact
• HTML review artifact
• workflow analysis artifact
• node-to-file or node-to-artifact map
• blocked seam payload examples
• resume envelope examples

What To Avoid

• Do not produce a one-node planner.
• Do not hide weave-out decisions in narrative prose only.
• Do not collapse prompt-plan, prompt-replan, run, and resume into one generic execution node.
• Do not assume repo-global docs will be available later.
• Do not leave “agent decides details” as a hidden subflow inside a node.

Local Offline Loom Agent Execution Orchestrator Guide (Beta)

This file is the self-contained beta-channel runtime guide for /loom-plan-execution.

Use this file only when the AO package is not installed yet or the restored AO runtime is not runnable yet.

Once the AO runtime is runnable, execute dotnet ao.dll --guide from that runtime and treat the emitted guide as the only runtime truth for that installed version.

Once that fresh guide result exists, governed execution must stay on the corresponding published AO package runtime surface described by that guide. Do not read the guide and then drift back to repository builds, hand-assembled runtimes, or non-governed execution paths for official skill runs.

Do not keep using this offline file as the authority after ao.dll is runnable.

Channel Snapshot

• Channel: beta
• Current latest beta AO bundle version for this offline snapshot: 0.2.121-beta
• Runtime bundle packages: Techne.Loom.AgentOrchestrator, Techne.Loom.Common, Techne.Loom.Abstractions

Product Role

Loom Agent Execution Orchestrator coordinates exploratory work under uncertainty.

It keeps workflow state, returns explicit blocked control payloads when outside action is required, and continues only after a structured resume envelope is provided.

Official Execution Authority

Official skill runs are only:

• dotnet ao.dll run
• dotnet ao.dll resume

These commands support but do not replace official skill execution:

• dotnet ao.dll --guide
• dotnet ao.dll compile
• dotnet ao.dll prompt-plan
• dotnet ao.dll prompt-replan

Environment Setup

1. Confirm the beta channel. 2. Restore the full AO runtime bundle at 0.2.121-beta. 3. Assemble one unified runtime directory outside any skill folder. 4. Verify ao.dll, ao.deps.json, ao.runtimeconfig.json, and dependency closure. 5. As soon as the runtime is runnable, use dotnet ao.dll --guide from that runtime and switch guide authority to that emitted guide. 6. Keep session directories and audit outputs outside skill-owned paths.

Preferred Launch Mode

Use explicit launch mode when deterministic host binding matters:

dotnet exec --depsfile .\ao.deps.json --runtimeconfig .\ao.runtimeconfig.json .\ao.dll --guide

CLI Surface

Workflow And Audit Model

• AO workflow JSON is typically authored outside AO, then validated with compile.
• For /loom-plan-execution, workflow creation and revision should use the local workflow-designer subagent at ../assets/agents/loom-plan-execution-workflow-designer.agent.md.
• compile emits Mermaid Markdown, HTML, and workflow JSON backup validation artifacts.
• Run and resume also emit audit artifact links for Mermaid Markdown, HTML, and workflow JSON backups.
• Audit artifacts live under a per-step output directory.
• Use a writable runtime session directory outside skill-owned paths.
• Keep checked-in plans and immutable source snapshots separate from mutable runtime outputs.

Core Control Contract

AO control payloads are emitted in <ao_property> blocks.

Primary boundary and progress fields:

• status
• session_id
• workflow_file
• workflow_instance_file
• event_log_file
• current_node_id
• boundary_reason
• pending_requirements
• next_frontier
• human_or_agent_hint
• weave_out_request
• audit_artifacts

Resume envelope fields:

• transition_id
• correlation_key
• payload

Plan And Replan Playbook

When generating or revising AO workflow JSON, the preferred authoring surface is the local workflow-designer subagent linked above. Give it relative links to the active plan, current workflow JSON, audit artifacts, guide export, and blocked payload evidence.

On a blocked return:

1. Read the <ao_property> payload. 2. Load the latest workflow_file snapshot. 3. Read last_transition_id from that snapshot. 4. Execute only the minimum external work required by the current boundary. 5. Write a structured resume result envelope. 6. Resume with dotnet ao.dll resume.

Use prompt-plan when creating or revising an authored workflow instance before runtime execution.

Use prompt-replan when a selected blocked seam needs graph-aware replanning on the latest authored or runtime workflow instance.

Completion Gate

AO should only be treated as completed when:

• AO returns status: completed
• the runtime has reached its completed state
• any business deliverables requested by the caller are actually present and verified

Runtime-only status is not enough when the objective clearly requested business outputs.

Think-Out-Loud Fields

When runtime preparation completes and on each progress update, report:

• resolved_runtime_version
• runtime_bundle_packages
• unified_runtime_directory
• runtime_preflight_result
• package_channel_launch_mode
• audit_markdown_file
• audit_html_file

Anti-Patterns

• Treating compile, --guide, prompt-plan, or prompt-replan as official run modes
• Hiding blocked-state control inside prose only
• Treating AO runtime artifacts alone as final completion when the task asked for business outputs
• Writing runtime session state under the skill folder

Local Offline Loom Agent Execution Orchestrator Guide (Released)

This file is the self-contained released-channel runtime guide for /loom-plan-execution.

Use this file only when the AO package is not installed yet or the restored AO runtime is not runnable yet.

Once the AO runtime is runnable, execute dotnet ao.dll --guide from that runtime and treat the emitted guide as the only runtime truth for that installed version.

Once that fresh guide result exists, governed execution must stay on the corresponding published AO package runtime surface described by that guide. Do not read the guide and then drift back to repository builds, hand-assembled runtimes, or non-governed execution paths for official skill runs.

Do not keep using this offline file as the authority after ao.dll is runnable.

Channel Snapshot

• Channel: released
• Current latest released AO bundle version for this offline snapshot: 0.2.126
• Runtime bundle packages: Techne.Loom.AgentOrchestrator, Techne.Loom.Common, Techne.Loom.Abstractions

Product Role

Loom Agent Execution Orchestrator coordinates exploratory work under uncertainty.

It keeps workflow state, returns explicit blocked control payloads when outside action is required, and continues only after a structured resume envelope is provided.

Official Execution Authority

Official skill runs are only:

• dotnet ao.dll run
• dotnet ao.dll resume

These commands support but do not replace official skill execution:

• dotnet ao.dll --guide
• dotnet ao.dll compile
• dotnet ao.dll prompt-plan
• dotnet ao.dll prompt-replan

Environment Setup

1. Confirm the released channel. 2. Restore the full AO runtime bundle at 0.2.126. 3. Assemble one unified runtime directory outside any skill folder. 4. Verify ao.dll, ao.deps.json, ao.runtimeconfig.json, and dependency closure. 5. As soon as the runtime is runnable, use dotnet ao.dll --guide from that runtime and switch guide authority to that emitted guide. 6. Keep session directories and audit outputs outside skill-owned paths.

Preferred Launch Mode

Use explicit launch mode when deterministic host binding matters:

dotnet exec --depsfile .\ao.deps.json --runtimeconfig .\ao.runtimeconfig.json .\ao.dll --guide

CLI Surface

Workflow And Audit Model

• AO workflow JSON is typically authored outside AO, then validated with compile.
• For /loom-plan-execution, workflow creation and revision should use the local workflow-designer subagent at ../assets/agents/loom-plan-execution-workflow-designer.agent.md.
• compile emits Mermaid Markdown, HTML, and workflow JSON backup validation artifacts.
• Run and resume also emit audit artifact links for Mermaid Markdown, HTML, and workflow JSON backups.
• Audit artifacts live under a per-step output directory.
• Use a writable runtime session directory outside skill-owned paths.
• Keep checked-in plans and immutable source snapshots separate from mutable runtime outputs.

Core Control Contract

AO control payloads are emitted in <ao_property> blocks.

Primary boundary and progress fields:

• status
• session_id
• workflow_file
• workflow_instance_file
• event_log_file
• current_node_id
• boundary_reason
• pending_requirements
• next_frontier
• human_or_agent_hint
• weave_out_request
• audit_artifacts

Resume envelope fields:

• transition_id
• correlation_key
• payload

Plan And Replan Playbook

When generating or revising AO workflow JSON, the preferred authoring surface is the local workflow-designer subagent linked above. Give it relative links to the active plan, current workflow JSON, audit artifacts, guide export, and blocked payload evidence.

On a blocked return:

1. Read the <ao_property> payload. 2. Load the latest workflow_file snapshot. 3. Read last_transition_id from that snapshot. 4. Execute only the minimum external work required by the current boundary. 5. Write a structured resume result envelope. 6. Resume with dotnet ao.dll resume.

Use prompt-plan when creating or revising an authored workflow instance before runtime execution.

Use prompt-replan when a selected blocked seam needs graph-aware replanning on the latest authored or runtime workflow instance.

Completion Gate

AO should only be treated as completed when:

• AO returns status: completed
• the runtime has reached its completed state
• any business deliverables requested by the caller are actually present and verified

Runtime-only status is not enough when the objective clearly requested business outputs.

Think-Out-Loud Fields

When runtime preparation completes and on each progress update, report:

• resolved_runtime_version
• runtime_bundle_packages
• unified_runtime_directory
• runtime_preflight_result
• package_channel_launch_mode
• audit_markdown_file
• audit_html_file

Anti-Patterns

• Treating compile, --guide, prompt-plan, or prompt-replan as official run modes
• Hiding blocked-state control inside prose only
• Treating AO runtime artifacts alone as final completion when the task asked for business outputs
• Writing runtime session state under the skill folder

AO Skill Local Reference (Offline)

This document holds the detailed rule set referenced by /loom-plan-execution/SKILL.md.

Workflow Designer Subagent

Use this exact local workflow-design subagent whenever /loom-plan-execution needs to create or revise workflow JSON:

• ../assets/agents/loom-plan-execution-workflow-designer.agent.md

Pass relative links to the plan file, guide file, workflow file, audit artifacts, and any blocked payload evidence so the subagent runs with explicit local context instead of relying on repository-global discovery.

The subagent must generate node-level granularity where each node owns one visible responsibility and where every AO weave-out path has a detailed blocked-action hint.

Runtime Acquisition

• For /loom-plan-execution, package downloads must follow the current CI/CD-managed skill package version block. Derive released versus beta from that bound version only when the runtime flow needs a channel distinction.
• In package-channel mode, restore the AO runtime bundle together at one resolved version:
• Techne.Loom.AgentOrchestrator
• Techne.Loom.Common
• Techne.Loom.Abstractions
• Build one unified runtime directory and execute AO commands from that directory only.
• Do not execute from partial single-package extraction roots.
• On Windows PowerShell 5.1, do not use Expand-Archive directly on .nupkg. Treat the package as ZIP content and extract it through ZIP-aware APIs or an equivalent ZIP-based flow.
• If you probe package URLs through Invoke-WebRequest or Invoke-RestMethod on Windows PowerShell 5.1, add -UseBasicParsing to avoid legacy security prompts that stall automation.

Startup Contract Preflight

Before AO command execution in package-channel mode, verify:

• ao.dll
• ao.deps.json
• ao.runtimeconfig.json
• dependency closure readiness in the same runtime directory.
• If extraction fails or any startup-contract file is missing, stop immediately. Do not emit runtime_preflight_result: passed.

Launch Mode

• Prefer explicit launch mode in package-channel execution:
• dotnet exec --depsfile <ao.deps.json> --runtimeconfig <ao.runtimeconfig.json> <ao.dll> ...

Runtime Flow Details

• After skill-bound version and runtime-source selection, the next hard gate is proving that the selected AO runtime for that source is runnable and can emit a fresh dotnet ao.dll --guide [--lang <language>] result from that runtime.
• Do not proceed to planning, authoring, validation, compile, prompt-plan, prompt-replan, run, resume, or downstream input collection before that guide result exists.
• Once that guide result exists, official governed execution must return to the corresponding published AO package runtime surface that the guide describes. Reading --guide does not allow official execution to keep drifting on repository builds, hand-assembled runtimes, or other non-governed paths.
• Failed stderr output from dotnet ao.dll --guide or dotnet exec ... ao.dll --guide is not a guide artifact. Save exported guide files only after the guide command succeeds and the startup-contract files are present.
• Use guide and prompt surfaces for preparation:
• dotnet ao.dll --guide
• dotnet ao.dll prompt-plan
• dotnet ao.dll prompt-replan
• dotnet ao.dll compile
• Official skill runs remain only:
• dotnet ao.dll run
• dotnet ao.dll resume

Think-Out-Loud Required Fields

Report runtime fields once runtime is prepared and on each progress update:

• resolved_runtime_version
• runtime_bundle_packages
• unified_runtime_directory
• runtime_preflight_result
• package_channel_launch_mode

Report audit fields on each progress update:

• audit_markdown_file
• audit_html_file

Business-Outcome-First Gate

• If objective/plan clearly requests business outputs, completion requires business deliverables plus AO completed state.
• Runtime-only or meta-only reporting cannot replace business delivery completion.

Local Offline Package Index (Beta)

This file is the offline package authority for /loom-plan-execution when the caller selects the beta channel.

During skill execution, do not switch to repository docs or web pages to decide package ids, bundle composition, or prerelease policy. Use the rules and versions in this file.

Beta Channel Rule

• Beta channel means prerelease packages from the development line.
• For deterministic package-channel execution, restore one exact prerelease version for the full AO runtime bundle.
• For this offline snapshot, the current latest beta version is 0.2.121-beta.
• If a future maintenance pass refreshes this file, the refreshed value becomes the new local authority.

Version Shape Rule

• Beta versions follow major.minor.<distance>-beta.
• Once the beta channel is selected, do not silently downgrade to released packages.
• Use one exact beta version across the whole AO runtime bundle.

Full Runtime Bundle Rule

Never restore only the runtime package.

The AO runtime bundle is always:

• Techne.Loom.AgentOrchestrator
• Techne.Loom.Common
• Techne.Loom.Abstractions

All three packages must resolve to the same beta version.

Deterministic Restore Rule

For official skill execution, prefer exact version restore over floating prerelease resolution after the channel is chosen.

• Good: restore all three packages at 0.2.121-beta.
• Bad: restore one package at an older prerelease while another package uses the current bound version 0.2.114-beta.
• Bad: restore only Techne.Loom.AgentOrchestrator.
• Bad: switch to stable packages after the beta channel has been chosen.

Acquisition Commands

Use these commands when a local runtime bundle needs to be restored from packages:

dotnet add package Techne.Loom.Abstractions --version 0.2.121-beta
dotnet add package Techne.Loom.Common --version 0.2.121-beta
dotnet add package Techne.Loom.AgentOrchestrator --version 0.2.121-beta

If the runtime is restored by package extraction rather than project reference, keep the same exact version rule for all three packages.

When the exact package id and version are already known, do not use NuGet.org page/search/registration indexing freshness as the existence gate. Probe or download the exact .nupkg URL directly instead, for example:

https://www.nuget.org/api/v2/package/Techne.Loom.AgentOrchestrator/0.2.114-beta

Unified Runtime Directory Rule

After package restore or extraction:

• build one unified runtime directory outside the skill folder
• place ao.dll, ao.deps.json, ao.runtimeconfig.json, and dependency assemblies in that one directory
• run AO commands from that unified directory only
• do not execute from partial extraction roots or mixed-version directories
• on Windows PowerShell 5.1, treat .nupkg as ZIP content and do not use Expand-Archive directly on the .nupkg
• when PowerShell 5.1 uses Invoke-WebRequest or Invoke-RestMethod for package probes, add -UseBasicParsing

Startup Preflight

Before using the beta runtime bundle, verify:

• ao.dll exists
• ao.deps.json exists
• ao.runtimeconfig.json exists
• dependent assemblies from Techne.Loom.Common and Techne.Loom.Abstractions are present in the same runtime directory
• if extraction fails or any startup-contract file is missing, stop immediately and do not record runtime_preflight_result: passed

Launch Mode

Prefer explicit launch mode for deterministic runtime binding:

dotnet exec --depsfile .\ao.deps.json --runtimeconfig .\ao.runtimeconfig.json .\ao.dll --guide

The same launch form applies to compile, prompt-plan, prompt-replan, run, and resume.

Do not export a guide file from failed command stderr. Save guide artifacts only after the guide command succeeds against a runtime that passed startup preflight.

Official Runtime Surface

Preparation and inspection commands:

• dotnet ao.dll --guide
• dotnet ao.dll compile
• dotnet ao.dll prompt-plan
• dotnet ao.dll prompt-replan

Official skill run commands:

• dotnet ao.dll run
• dotnet ao.dll resume

--guide, compile, prompt-plan, and prompt-replan are not official skill run modes.

Required Think-Out-Loud Fields

When the skill reports package-channel runtime preparation, include:

• resolved_runtime_version: 0.2.121-beta
• runtime_bundle_packages
• unified_runtime_directory
• runtime_preflight_result
• package_channel_launch_mode

When audit artifacts exist, also include:

• audit_markdown_file
• audit_html_file

Maintenance Rule

This file is intentionally self-contained for runtime use.

• Do not tell the runtime flow to consult repository package indexes.
• Do not require browsing NuGet pages to understand beta-channel behavior.
• Refresh this file in a maintenance pass when the beta latest version changes.

Local Offline Package Index (Released)

This file is the offline package authority for /loom-plan-execution when the caller selects the released channel.

During skill execution, do not switch to repository docs or web pages to decide package ids, bundle composition, or version policy. Use the rules and versions in this file.

Released Channel Rule

• Released channel means stable packages only.
• For deterministic package-channel execution, restore one exact stable version for the full AO runtime bundle.
• For this offline snapshot, the current latest released version is 0.2.126.
• If a future maintenance pass refreshes this file, the refreshed value becomes the new local authority.

Full Runtime Bundle Rule

Never restore only the runtime package.

The AO runtime bundle is always:

• Techne.Loom.AgentOrchestrator
• Techne.Loom.Common
• Techne.Loom.Abstractions

All three packages must resolve to the same released version.

Deterministic Restore Rule

For official skill execution, prefer exact version restore over floating resolution after the channel is chosen.

• Good: restore all three packages at 0.2.126.
• Bad: restore one package at 0.2.77 and another at a different stable version.
• Bad: restore only Techne.Loom.AgentOrchestrator.
• Bad: switch to beta packages after the released channel has been chosen.

Acquisition Commands

Use these commands when a local runtime bundle needs to be restored from packages:

dotnet add package Techne.Loom.Abstractions --version 0.2.126
dotnet add package Techne.Loom.Common --version 0.2.126
dotnet add package Techne.Loom.AgentOrchestrator --version 0.2.126

If the runtime is restored by package extraction rather than project reference, keep the same exact version rule for all three packages.

When the exact package id and version are already known, do not use NuGet.org page/search/registration indexing freshness as the existence gate. Probe or download the exact .nupkg URL directly instead, for example:

https://www.nuget.org/api/v2/package/Techne.Loom.AgentOrchestrator/0.2.77

Unified Runtime Directory Rule

After package restore or extraction:

• build one unified runtime directory outside the skill folder
• place ao.dll, ao.deps.json, ao.runtimeconfig.json, and dependency assemblies in that one directory
• run AO commands from that unified directory only
• do not execute from partial extraction roots or mixed-version directories
• on Windows PowerShell 5.1, treat .nupkg as ZIP content and do not use Expand-Archive directly on the .nupkg
• when PowerShell 5.1 uses Invoke-WebRequest or Invoke-RestMethod for package probes, add -UseBasicParsing

Startup Preflight

Before using the released runtime bundle, verify:

• ao.dll exists
• ao.deps.json exists
• ao.runtimeconfig.json exists
• dependent assemblies from Techne.Loom.Common and Techne.Loom.Abstractions are present in the same runtime directory
• if extraction fails or any startup-contract file is missing, stop immediately and do not record runtime_preflight_result: passed

Launch Mode

Prefer explicit launch mode for deterministic runtime binding:

dotnet exec --depsfile .\ao.deps.json --runtimeconfig .\ao.runtimeconfig.json .\ao.dll --guide

The same launch form applies to compile, prompt-plan, prompt-replan, run, and resume.

Do not export a guide file from failed command stderr. Save guide artifacts only after the guide command succeeds against a runtime that passed startup preflight.

Official Runtime Surface

Preparation and inspection commands:

• dotnet ao.dll --guide
• dotnet ao.dll compile
• dotnet ao.dll prompt-plan
• dotnet ao.dll prompt-replan

Official skill run commands:

• dotnet ao.dll run
• dotnet ao.dll resume

--guide, compile, prompt-plan, and prompt-replan are not official skill run modes.

Required Think-Out-Loud Fields

When the skill reports package-channel runtime preparation, include:

• resolved_runtime_version: 0.2.126
• runtime_bundle_packages
• unified_runtime_directory
• runtime_preflight_result
• package_channel_launch_mode

When audit artifacts exist, also include:

• audit_markdown_file
• audit_html_file

Maintenance Rule

This file is intentionally self-contained for runtime use.

• Do not tell the runtime flow to consult repository package indexes.
• Do not require browsing NuGet pages to understand released-channel behavior.
• Refresh this file in a maintenance pass when the released latest version changes.