threadlight-skills

Emit the final triage decision (approve_refund / deny_refund / escalate_to_supervisor / request_more_info), recommend a warehouse disposition, and write the audit record. USE FOR producing and persisting the final outcome. DO NOT USE FOR gathering data (intake-validation) or the raw eligibility/risk checks.

Apply the value ceiling and serial-returner / flagged-account risk gates and route cases to a human supervisor. USE FOR deciding whether a return must be escalated to the returns supervisor. DO NOT USE FOR the base eligibility check (policy-eligibility).

Correlate a return case with its order and customer profile, and validate completeness. USE FOR intake of a new return, matching an RMA to an order, checking required fields/photos. DO NOT USE FOR the eligibility or refund decision (that is policy-eligibility / disposition-decision).

Check a return against Contoso Retail return policy — 30-day window, final-sale rules, item condition — and cite the governing clause. USE FOR deciding whether a return is eligible for refund. DO NOT USE FOR high-value/fraud gating (fraud-escalation) or writing the final decision (disposition-decision).

Spec out a business process or customer use case for an enterprise pilot, then generate agent architecture (AGENTS.md + Skills) — a durable SpecKit specification first (process flow, business rules, data models, tool contracts, mock data, KPIs, governance), then implementation artifacts derived from the spec. Targets named LOB processes in regulated industries (FSI, Mfg, Retail, Telco, Healthcare, Utilities) where a customer SME will judge the SPEC on industry realism before the demo even runs. USE FOR: design a process, spec out a use case, create agent architecture, automate a regulated workflow, threadlight design, skill factory, business process specification, speckit, define a customer scenario, mock backend systems, seller prep guide, demo script, demo prompts, lock the stack/model/hosting foundation. DO NOT USE FOR: running existing skills, executing code, deploying (use threadlight-deploy), general Q&A, internal Microsoft tooling automation, generic chatbot prototyping.

PROTECT-leg for threadlight pilots: makes the Microsoft Agent Governance Toolkit (AGT) actually govern a deployed agent — not just document it. Scaffolds a real, schema-valid, versioned `policy.yaml`, commits `agt test` fixtures, gates CI on `agt lint-policy` + `agt verify` (OWASP ASI 2026 attestation), and emits `specs/govern-manifest.json` for threadlight-production-ready pillars 2 and 7. USE FOR: agent action governance, AGT policy, agt lint-policy, agt test, agt verify, tool allow/deny, excessive-agency guardrail, default-deny policy, OWASP ASI 2026, governance CI gate, policy attestation, responsible-ai policy, PROTECT stage, govern leg, govern-manifest. DO NOT USE FOR: content filtering at the model edge (Azure AI Content Safety) — AGT governs actions; adversarial scanning (threadlight-redteam); quality evals (threadlight-evals); completeness gate (threadlight-safe-check); deep AGT authoring upstream (foundry-agt).

Use after threadlight-safe-check post-deploy returns green to take a deployed pilot from lab to ready for customer architecture review / CISO sign-off / paved path to production. Reads SPEC § 12 (posture, must-have pillars, residency, RTO/RPO, SLA, incident owner) and probes Azure to produce an advisory production-readiness scorecard + uplift plan + customer hand-off package across 13 pillars. Soft advisory — never fails a build. USE FOR: production readiness, prod-ready gate, customer architecture review, CISO sign-off prep, pilot-to-prod handover, paved path to production, citadel uplift, AGT uplift, AI gateway uplift, go-live readiness, hand-off package, SRE handover, Kratos export readiness. DO NOT USE FOR: deployment itself (threadlight-deploy), structural completeness gate (threadlight-safe-check), invocation testing (foundry-evals), middleware authoring (foundry-agt), citadel hub provisioning (citadel-hub-deploy), access contracts (citadel-spoke-onboarding).

Run a threadlight-designed PoC locally without `azd up`. Four patterns: (0) **Quickstart** — `python -m threadlight_quickstart` boots MAF Agent + SkillsProvider + stub tools + Streamlit UI on localhost:8501; one LLM dep (Foundry OR AOAI OR GitHub Models via GITHUB_TOKEN — zero Azure). (1) MCP-direct — local MCP at `~/.copilot/mcp.json`; (2) Smoke-client — `agent.run_async()` bypassing ResponsesHostServer; (3) Local-stack — docker-compose + Cosmos emulator (Linux/Win x86 only). USE FOR: local test, smoke test, run agent locally, dev loop, no azd, copilot cli mcp, faster iteration, prompt tuning, cowork iteration, demo rehearsal, screen-shareable PoC, streamlit demo, GitHub Models, boot Kratos export locally. DO NOT USE FOR: prod deployment (use threadlight-deploy), pre-pilot validation (use threadlight-safe-check), hosted-agent runtime testing in cloud (use foundry-evals).

Use when a Threadlight pilot must reach production through a CI/CD pipeline instead of the agent running `azd up` directly — prod deploys run under a federated identity with scoped RBAC from private-VNet runners and the agent has no standing deploy rights. Generates a GitHub Actions or Azure DevOps prod-deploy pipeline + env-setup runbooks, with an onboarding-path gate and a central-platform boundary vs citadel-hub-deploy. USE FOR: ci/cd pipeline, prod deploy pipeline, github actions pipeline, azure devops pipeline, OIDC, workload identity federation, WIF, UAMI, scoped RBAC, self-hosted runners, private vnet runners, restricted environment deploy, platform team handoff, onboarding path gate. DO NOT USE FOR: deploying the central Citadel hub / shared AI gateway (use citadel-hub-deploy); wiring a pilot to an existing hub (use citadel-spoke-onboarding); the first-run sandbox deploy (use threadlight-deploy).

Take a designed agent project (from threadlight-design or hand-crafted) and generate all deployment artifacts for Microsoft Foundry Hosted Agents. Reads specs/SPEC.md, AGENTS.md, and skills to produce container.py, Dockerfile, pyproject.toml, an azd project, and deploy-notes.md for one-command `azd up`. Also runs in Kratos-export mode: handed a Kratos-exported project (src/hosted-agent/ + use-cases/<x>/) it enriches/validates only and backfills the missing evals/ directory. USE FOR: deploy to Foundry, make this deployable, generate deployment files, Foundry hosted agent, containerize agent, package agent, deploy agent, azd deploy, azd up, Kratos export, foundry-agent.zip, backfill evals. DO NOT USE FOR: designing the process (use threadlight-design), running evals (use foundry-evals), Teams bot (use foundry-teams-bot), MCP server deployment (use foundry-mcp-aca), GHCP SDK variant (use ghcp-hosted-agents), azd tenant isolation (use azure-tenant-isolation).

Three-lifecycle completeness gate for threadlight pilots (design / pre-deploy / post-deploy). Reads SPEC § 11c selectors via `specs/manifest.json` `deployment_manifest` and asserts: every selector maps to a deployed `Microsoft.*` type, every channel reaches, every scheduled job is wired. Post-deploy also runs behavioural checks: deployed images differ from the azuredocs helloworld placeholder, no ACA Job has its last 5 runs all Failed, App Insights exists when SPEC declared it. USE FOR: completeness gate, deploy gate, post-deploy gate, pre-deploy check, manifest drift, orphan modules, partial PoC, missing bot/workspace/aca-job, deployment_manifest, manifest.json, placeholder image, helloworld image, image probe, job execution failed, cron rot, app insights missing, telemetry not flowing, blank appin, Kratos export gate, trimmed infra, derive expected types from infra. DO NOT USE FOR: invocation/runtime tests (foundry-evals), `azd up` orchestration (threadlight-deploy), schema authoring (threadlight-design).

Scaffold non-interactive trigger receivers for a threadlight process — ACA-first (jobs, app HTTP receivers, KEDA-scaled consumers) with Azure Functions only when narrow constraints demand it. Reads spec § 10b Triggers (Receiver contract) and produces the receiver scaffold + idempotency / dead-letter wiring. USE FOR: scheduled trigger, event-driven trigger, ACA job scaffold, ACA app webhook, ACA consumer, KEDA scaler, Service Bus consumer, Event Grid subscription, cron trigger, idempotency key, dead-letter queue, threadlight triggers, add trigger to Kratos export. DO NOT USE FOR: chat / on-demand triggers (those go through the agent directly), bot infrastructure (use foundry-teams-bot), MCP server deployment (use foundry-mcp-aca).

Full-auto driver for the Threadlight pilot pipeline. One freeform prompt ("Build me an auto-claim triage agent for Contoso Mutual") drives threadlight-design → (optional) threadlight-local-test → threadlight-deploy → threadlight-safe-check → live invoke → (optional, advisory) threadlight-production-ready. Auto-continues at every gate; HARD STOPS on tenant assertion failure or quota exhaustion. Resumes from `.threadlight/auto-state.json`. Smart-recovers from quota, RBAC race, and ImagePull deploy failures. Wraps existing threadlight-* skills. USE FOR: full-auto pilot drive, one-prompt threadlight, resume failed deploy, demo-in-one-session, autopilot, threadlight orchestrator, start from Kratos export. DO NOT USE FOR: per-stage control (use threadlight-design / -deploy / -safe-check directly), production CI/CD, single-stage iteration.

Use after threadlight-safe-check post-deploy and before threadlight-production-ready to project per-resource monthly Azure cost at the customer's declared load and compare 2–3 SKUs per resource so the seller/SE picks the cheapest config that still meets constraints. Reads deployed Bicep + SPEC § 12 load_profile, hits the Azure Retail Prices API, emits cost-projection.md + cost-manifest.json. Advisory only. Also a PRE-SALES phased estimate with no deployed pilot (adoption phases, hardening delta, EA/MCA discount → seller one-pager). USE FOR: azure consumption projection, cost projection, post-deploy cost, SKU diff, PAYG vs PTU, AI Search sizing, load profile, cost-manifest.json, retail prices API, pre-sales cost estimate, EA/MCA discount, seller one-pager. DO NOT USE FOR: AOAI-only PAYG-vs-PTU break-even with no pilot (use paygo-ptu-cost-analyzer); live Cost Management actual-cost queries (stay in threadlight-production-ready); Bicep mutation (use threadlight-deploy).

DISCOVER + GOVERN + IMPROVE evals leg for threadlight pilots on Microsoft Foundry. Runs and verifies offline batch quality evals, Foundry Continuous Evaluation on live threads, and champion-challenger comparison gates, then emits `specs/evals-manifest.json` for pillar 6 production-readiness scoring. USE FOR: continuous evals, offline eval gate, eval schedule, Foundry Continuous Evaluation, create_agent_evaluation, Application Insights eval results, eval threshold alert, eval run freshness, eval dataset shape, tool_calls tool_outputs, champion challenger, A/B eval gate, model swap gate, prompt swap gate, foundry-evals pipeline leg, continuous-evals pillar, EVAL-001..006, EVAL-101..105, evals-manifest. DO NOT USE FOR: token-level content filtering at the model edge — use the model guardrail / Azure AI Content Safety; adversarial scanning — use threadlight-redteam; agent-runtime action governance — use threadlight-govern; deep evaluator or dataset authoring — use foundry-evals.

Offline self-improvement cold-path for threadlight CI/GHCP runs on Microsoft Foundry. `learn <run_id>` harvests ONE GitHub Actions run (green or red, no baseline needed) and emits a grounded learnings digest: phase parity, a reality-tuned failure taxonomy (dependency drift, rate-limit cascade, wire protocol, model-unavailable, auth, quota, deploy), and recommendations — using `--log-failed` for high precision so green runs stay clean. `bench <candidate> <baseline>` is an OPTIONAL paired cost/efficiency scorecard of a model-router run vs a baseline model (gpt-5.4-mini) from Azure Monitor token metrics. USE FOR: learn from CI run, self-improving cold-path, inspect GHCP logs, CI failure taxonomy, why did my e2e fail, router efficiency, model-router cost, token cost vs baseline, cost scorecard, learnings digest, run retro, router quality matrix. DO NOT USE FOR: dispatching or fixing the e2e workflow — use threadlight-cicd; running evals/redteam/govern legs — use those skills; live agent runtime monitoring.

Use when an SE or a customer's platform team needs to FORK the Threadlight pipeline and adapt it to one customer's environment — landing zones, identity, RBAC, deploy pipelines, governance — with PRODUCTION ONBOARDING as priority #1. An instructions/runbooks skill (not automation): intake gate, customization map (keep vs per-customer-override), test-in-customer-environment runbook for private-VNet envs, and a fork-runbook (upstream-pin + overlay merge). USE FOR: fork threadlight, customize threadlight, customer onboarding, production onboarding, onboard a customer, adapt the pipeline, tailor threadlight, customer landing zone, customer RBAC, customization map, what to fork vs keep, upstream pin, overlay merge, test in customer environment. DO NOT USE FOR: generating the prod deploy pipeline (use threadlight-cicd); the readiness scorecard (use threadlight-production-ready); the first-run deploy (use threadlight-deploy); a central hub (use citadel-spoke-onboarding / citadel-hub-deploy).

DISCOVER-leg for threadlight pilots: runs or ingests Microsoft AI Red Teaming Agent / PyRIT adversarial scan evidence and emits `specs/redteam-manifest.json` plus `docs/redteam-report.md` so `threadlight-production-ready` pillar 7 has live safety evidence instead of static configuration only. USE FOR: adversarial scan, AI red teaming, jailbreak testing, prompt-injection testing, indirect prompt injection, XPIA, exfiltration testing, attack success rate, ASR, PyRIT, safety scan, responsible-ai evidence, pillar 7 evidence, SAFE-1xx findings, pre-deploy red team, post-deploy red team. DO NOT USE FOR: static content-filter or RAI policy authoring (threadlight-govern / foundry-agt); quality, groundedness, relevance, or regression evals (threadlight-evals); token-level model content filtering (Azure AI Content Safety).

Generate Teams Adaptive Card flows + bot UX components for the seven canonical action gates (approve, edit-and-approve, reject, escalate, signoff, audit-view, request-info) declared in spec § 8 Human Interaction Points. Pairs with foundry-teams-bot for delivery. USE FOR: human-in-the-loop, approval cards, Teams Adaptive Cards for agent decisions, action gate UX, edit-and-approve flow, escalation card, signoff flow, threadlight HITL, add gate to Kratos export. DO NOT USE FOR: bot infrastructure (use foundry-teams-bot), workspace UI (use threadlight-workspace-ui), agent runtime logic (use threadlight-deploy).

Generate a curated, framework-agnostic workspace UI reference for a threadlight process — case-list / inbox / dashboard / console / kanban / map shape with detail pane, action toolbar, audit viewer. Reads spec § 8b Human Interaction (Workspace UX) and produces ONE reference implementation the customer can rebuild in their preferred framework. USE FOR: workspace UI, case management UI, agent operator console, case list with detail pane, action toolbar, audit viewer, threadlight workspace, demo workspace, operator dashboard, add workspace to Kratos export. DO NOT USE FOR: experience.html cinematic (use threadlight-design), Teams Adaptive Cards (use threadlight-hitl-patterns), real-time chat UI, framework-specific scaffolds (we ship pattern, not framework).

Generate per-domain Faker-style synthetic data + Cosmos seed/reset scripts for a threadlight process. Reads spec § 11d Demo Data and industry realism rules from threadlight-design, then produces scripts/seed_data.py and scripts/reset_data.py plus the seed JSON files in specs/sample-data/. USE FOR: generate demo data, synthetic data, Faker generators, Cosmos seed script, demo reset, mock data factory, threadlight demo data, populate sample-data, golden cases, idempotent reset. DO NOT USE FOR: indexing real customer data (use foundry-iq for that), live data ingestion (use threadlight-event-triggers), MCP server scaffold (use foundry-mcp-aca).

Triage incoming support tickets — read open tickets, classify severity, route to the right team, and update status.