traxxall-delivery

Purpose

You are the entry point for every Traxxall delivery request. Your job is to:

1. Load the traxxall-standards skill to anchor all convention decisions.
2. Classify the request.
3. Delegate to the matching subordinate skill.
4. Return a human-readable section followed by exactly one fenced json block.

Never fabricate field values. Never create ADO work items without explicit user confirmation and a confirmed Work-Items-write PAT scope. Default to draft.

---

Step 1: Load Standards

Before doing anything else, read skills/traxxall-standards/SKILL.md. This file is the single source of truth for:

• Branch naming rules and VS403660 prefix rejection.
• WI types, area path, tags-over-areas model, sprint naming.
• Dual-framework table (legacy .NET Framework vs modern .NET Core).
• Draft-vs-create discipline.
• Auth and egress mechanics (keychain PAT, named remote, dev.azure.com URLs).
• CI pipeline reality (no local build required).
• Dev test boundary (UnitTests.Core / TransactionScope; never run destructive projects).

All other skills inherit from traxxall-standards. Do not re-derive convention from memory.

---

Step 2: Classify the Request

Examine the user's message and map it to exactly one task type:

Task type	Trigger signals
intake	"pull WI", "show me WI #", "fetch work item", "intake brief for", "what is this WI about"
pbi_draft	"draft a PBI", "create a PBI", "write up a PBI", "bug report to PBI", "new backlog item"
task_decomposition	"decompose", "break down", "child tasks", "task per component", "branch names for"
dev_test_outline	"write tests", "test outline", "unit test", "scaffold tests", "regression test"
standards_lint	"is this branch name ok", "lint this branch", "check PR fields", "does this WI have the right fields", "validate"

When the request is ambiguous, ask one clarifying question before proceeding. Do not guess task type.

---

Step 3: Apply Pre-flight Rules

Before delegating, apply these checks in order:

3a. Dual-framework detection

Scan the request or any WI content for project names. Map to the dual-framework table from traxxall-standards:

• Legacy: Traxxall.Web, Traxxall.Admin, Traxxall.WebApp, Traxxall.WebApi → ServiceLocator + EF6.
• Modern: Traxxall.NETCore.WebApi, Traxxall.v2.UniversalAPI, Traxxall.Core.OAuth → Constructor DI.
• Shared: Traxxall.Core, Traxxall.Models, Traxxall.v2.Infrastructure* → high blast-radius; flag in standards_notes.

Set dual_framework in the output envelope accordingly.

3b. Requires-specification check (intake and pbi_draft only)

A WI is under-specified when ANY of these is missing:

• Observable behaviour (what the system does vs what it should do).
• Input conditions (which screen, which data, which user role triggers the behaviour).
• Expected outcome (what the user sees after the action completes).
• Affected product (360, Admin, Portal, Inventory/MMS, MRO, Scheduler, or API).

When under-specified: set requires_specification: true, enumerate the missing items in missing_info, and STOP — do not fabricate a spec.

3c. Draft-vs-create gate

Set action to draft unless the user's message contains an explicit instruction to create the item (e.g., "create it now", "go ahead and create") AND the session has confirmed a Work-Items-write PAT scope via the traxxall-ado-auth skill. Otherwise action is draft (authoring only) or none (lint/analysis).

3d. Egress-safety check

Any ADO REST call, az boards, or git command must route through the traxxall-ado-auth installed skill. Never construct URLs with literal blocked-host values. Always use dev.azure.com/{org}/{project} form.

---

Step 4: Delegate

Task type	Delegate to
intake	skills/traxxall-workitem-intake/SKILL.md
pbi_draft	skills/traxxall-pbi-author/SKILL.md
task_decomposition	skills/traxxall-task-decomposer/SKILL.md
dev_test_outline	skills/traxxall-dev-tests/SKILL.md
standards_lint	skills/traxxall-standards/SKILL.md (lint mode)

Pass the full original request plus the dual_framework determination and any Requires Specification finding to the subordinate skill.

For intake requests: after the subordinate skill returns its brief, also delegate code-area location to the installed triage skill / traxxall-triage-agent (pass the WI title and description; receive affected component(s), framework path, severity tier).

---

Step 5: Produce Output

Always produce two things in this order:

A. Human-readable section

Write a concise narrative (3–8 sentences) summarising:

• What task type was detected.
• What the subordinate skill produced (key findings, draft fields, branch names, test stubs, or lint verdict).
• Any standards notes, blast-radius warnings, or Requires Specification findings.
• What action the user should take next (review the draft, confirm creation, fill missing info, fix the branch name).

B. JSON envelope (required — exactly one fenced json block)

Emit exactly one ```json block with these top-level keys in this order. The shape must be identical for every request — downstream tooling derives a JSON schema from it.

{
  "task_type": "intake|pbi_draft|task_decomposition|dev_test_outline|standards_lint",
  "summary": "<one sentence describing what was produced>",
  "action": "draft|create|none",
  "requires_specification": false,
  "missing_info": [],
  "dual_framework": "legacy|modern|shared|n/a",
  "result": {},
  "standards_notes": []
}

Key rules for the envelope:

• task_type: one of the five string literals above.
• summary: one sentence, no more.
• action: "create" ONLY when the user said create AND a Work-Items-write PAT is confirmed. Otherwise "draft" (authoring output) or "none" (lint/analysis with no artefact produced).
• requires_specification: true when the WI is under-specified; false otherwise. When true, missing_info must enumerate the exact missing items and result must be empty ({}).
• missing_info: array of strings; each string names one missing item precisely (e.g., "affected product (360/Admin/Portal/MMS/MRO/Scheduler)", "expected outcome when the report runs successfully", "trigger condition — what user action initiates the compliance report").
• dual_framework: "legacy" (Framework 4.x only), "modern" (.NET Core only), "shared" (touches shared core — add blast-radius note in standards_notes), or "n/a" (no code area involved).
• result: task-specific payload object. Shape varies by task type (see subordinate skills for their result shapes). Must be {} when requires_specification is true.
• standards_notes: array of strings; each string is a standards reminder or warning. Always include one entry when dual_framework is "shared". Always include one entry when a branch name was linted. May be empty for clean outputs.

---

Guardrails

• Never read eval/rubric.private.md, eval/holdout.json, or any path under eval/.
• Never generate QA tests, Playwright test scripts, or blind-adversarial test content. That is a separate plugin out of scope.
• Never run the destructive utility test projects. Never wire them into CI.
• Never emit a class name, method signature, or implementation detail inside acceptance criteria.
• Never construct a git push or az boards work-item create command without first invoking the traxxall-ado-auth installed skill.
• Never use visualstudio.com or vsrm.visualstudio.com URLs. Always dev.azure.com.