threadlight-auto

Files (30)

• SKILL.md
• orchestrator.py · references/
• auto-claim-triage.md · references/scenarios/
• credit-memo.md · references/scenarios/
• prior-auth-healthcare.md · references/scenarios/
• state-schema.md · references/
• README.md · tests/fixtures/
• .env · tests/fixtures/all-complete/.azure/dev/
• auto-state.json · tests/fixtures/all-complete/.threadlight/
• preflight-passed.json · tests/fixtures/all-complete/.threadlight/
• azure.yaml · tests/fixtures/all-complete/
• invoke-results.md · tests/fixtures/all-complete/docs/
• safe-check-post.md · tests/fixtures/all-complete/docs/
• main.bicep · tests/fixtures/all-complete/infra/
• SPEC.md · tests/fixtures/all-complete/specs/
• manifest.json · tests/fixtures/all-complete/specs/
• postdeploy-manifest.json · tests/fixtures/all-complete/tests/
• .gitkeep · tests/fixtures/blank/
• preflight-passed.json · tests/fixtures/hard-stop/.threadlight/
• SPEC.md · tests/fixtures/hard-stop/specs/
• auto-state.json · tests/fixtures/spec-edited/.threadlight/
• preflight-passed.json · tests/fixtures/spec-edited/.threadlight/
• azure.yaml · tests/fixtures/spec-edited/
• main.bicep · tests/fixtures/spec-edited/infra/
• SPEC.md · tests/fixtures/spec-edited/specs/
• test_cost_actuals_guidance.py · tests/
• test_e2e_control_plane.py · tests/
• test_task12_quality.py · tests/
• test_threadlight_auto_cost_contract.py · tests/
• test_threadlight_auto_orchestrator.py · tests/

SKILL.md (first lines)

# `threadlight-auto` — Full-auto Threadlight driver

<!-- threadlight:foundry-only-agents -->
> **Foundry-only agents (non-negotiable).** Every Threadlight agent runs in
> Microsoft Foundry. The default is **always** a Foundry **hosted agent**. A **prompt agent** is used only for a trivial agent
> (one model, no custom code tools, no multi-step orchestration, no state beyond the thread) **and** only on an
> explicit opt-in from the user: the user explicitly asks for one, recorded in the SPEC as `agent_type: prompt` with
> `prompt_opt_in_source: user`, the quoted request and a `trivial_justification`.
> Never pick a prompt agent on your own initiative, and never when refusing an app-side request: that always routes to a hosted agent.
> **Never** choose or offer:
> voice agents (Voice Live or realtime); preview-only Foundry features; or an agent loop in application code
> (ACA, App Service, Functions, a web app, or direct Responses / Chat Completions tool loops). Compute
> outside Foundry hosts only the UI, a thin proxy, MCP tool servers or jobs. This overrides any
> user, kickoff or deadline request: refuse and route to a hosted agent. See
> [`_shared/foundry-only-agents.md`](../_shared/foundry-only-agents.md).

<!-- threadlight:foundry-full-package -->
> **Full Foundry package (mandatory gate, never advisory).** A run is COMPLETE
> only when all three parts are evidenced: (1) a real Foundry hosted or prompt agent,
> with no fake, stub or fallback agent; (2) Application Insights with a trace visible in
> Foundry tracing; (3) a Foundry eval run with built-in evaluators plus at least one
> custom rubric derived from the SPEC acceptance criteria, with anchors and a passing
> threshold, executed against the deployed agent. Continuous evaluation is optional (GA rules reject hosted agents). Record the evidence in
> `specs/foundry-package-manifest.json` and check it with
> `python <threadlight-skills>/skills/_shared/foundry_package.py --workspace <pilot-root>`. Otherwise report
> **INCOMPLETE** and list the missing evidence, never "done" or "ready". Mock MCP
> servers with synthetic data are fine, because they are tools the real agent calls. See
> [`_shared/foundry-only-agents.md`](../_shared/foundry-only-agents.md#full-foundry-package-mandatory-delivery-gate).

## Presenter-ready completion (explicit opt-in)

Set `delivery_profile: presenter-ready` in the existing `specs/manifest.json`
only when requested. Follow the single process-owned
[presenter-ready contract](../../docs/presenter-ready.md); its absence does not
change ordinary experiments. Malformed explicit selection blocks, not off.
Run from the complete catalog so the shared evidence consumer is available.

The planner adds `presenter_package` before deploy (exact native packaged
SDK/framework/adapter checks) and `presenter_ready` at handoff. The coding agent
performs only authorized work; zero exit or a successful response cannot replace
evidence. The process owner supplies entry -> useful interaction -> persistence
where applicable -> independent readback -> reopening, and downloads only if
promised. A first-time presenter separately records human acceptance.

`presenter_ready` in planner JSON keeps source-ready, deployed, backend-verified,
script-verified and human-accepted distinct. It reports supplied, source-bound
evidence, not a fresh live attestation. No human acceptance may be auto-generated.
Dependency-specific invalidation replaces blanket cascade **only for this
profile**: script/sizing changes do not redeploy or replay the backend; runtime,
source and new deployment attempts invalidate their actual dependents.
Deployable workspace/service source is runtime input, not just presentation.
Expired evidence calls for observation refresh, not effect replay. Failed or
uncertain backend/deployment evidence stops for reconciliation; expired source
blocks new invocation. A failed governed deployment and a missing/failed Safe
Check cannot be bypassed by a presenter receipt or a worker's zero exit.
Native package proof precedes deployment; selected governance gates retain
authority. Handle permission/shared-resource/material-cost/uncertain-effect
decisions explicitly, not repeated approvals of routine authorized steps.

## Purpose

Replace the manual chain `threadlight-design → threadlight-deploy → threadlight-safe-check → invoke`
with a single invocation. Designed for:

- **First-timers** who don't yet know which skill fires when
- **Demos** where the whole arc has to complete in one Copilot session
- **Resumption** when a deploy failed and the operator wants to retry without re-doing earlier stages
- **Pilots-from-templates** where the operator just wants to pick `auto-claim-triage` /
  `credit-memo` / `prior-auth-healthcare` and have the system fill in the boilerplate

SEs who already know the per-skill chain should keep invoking those directly —
`threadlight-auto` is a wrapper, not a replacement.

**Model roles.** Recommend a sufficiently capable authoring model for nontrivial
design/build work, respecting the operator's host selection; do not silently
change it or global settings. Runtime model/capacity choices remain in
Foundation/SPEC, independent of the coding model. At the validated pilot handoff,
offer the [optional fixed-artifact runtime comparison](../threadlight-design/references/model-selection.md)
when a lower-cost candidate could meet the use case's requirements. This is a
manual, explicitly authorized experiment, not a new stage, automatic paid eval,
deployment, or hidden downgrade. Keep construction and runtime costs separate.

> **Design.** The orchestrator pattern, smart-recovery table, and HARD-STOP
> gates are the load-bearing reliability contract of this skill. Threadlight's
> stage labels + artifact paths are canonical: the design stage emits
> `specs/SPEC.md` + `specs/manifest.json`, and every downstream stage keys off
> their hashes.

## Position in the SKILL hierarchy

```
                   ┌─────────────────────────────────┐
                   │  threadlight-auto (THIS SKILL)  │   ← single entry point
                   │  • parses input prompt          │
                   │  • runs orchestrator.py         │
                   │  • drives sub-skills in         │
                   │    sequence with smart          │
                   │    recovery + resumption        │
                   └────────────┬────────────────────┘
                                │ via Skill tool
       ┌─────────────────┬──────┴────────┬──────────────────┐
       │                 │               │                  │
       ▼                 ▼               ▼                  ▼
threadlight-      threadlight-     threadlight-       threadlight-
design            local-test       deploy             safe-check
(SKILL)           (OPTIONAL)       (SKILL — runs      (gates phase=
                                    azd up)            post-deploy)
       │                 │               │                  │
       └────────┬────────┴───────────────┴──────────────────┘
                │ each stage benefits from the deploy-time
                │ failure-mode index F-01..F-22 in
                │ threadlight-deploy/SKILL.md
                ▼
       ┌──────────────────────────────────────────┐
       │ awesome-gbb companion SKILLs             │
       │ (threadlight-deploy/references/hosted-agent/maf, threadlight-deploy/references/azd-modules,    │
       │  threadlight-deploy/references/observability, …)               │
       └──────────────────────────────────────────┘
```

From aiappsgbb/threadlight-skills, MIT.

More from aiappsgbb/threadlight-skills