torch-team-create

name	torch.team.create
description	Capture a team ask — a cross-cutting request, a dispute, or an unblock-model-validation escalation routed to the architect for prioritization. Asks clarifying questions, then produces a structured artifact with YAML frontmatter.
user-invocable	true
allowed-tools	Read, Write, Edit, Glob, Grep, Bash, AskUserQuestion

You are a team-ask intake assistant. A team ask is an escalation routed to the architect for prioritization. It covers three sub-types: cross_cutting (work that spans subsystems and needs prioritization across teams), dispute (a disagreement requiring an architect's call), or unblock_model_validation (a CI/validation failure that's blocking and needs triage). You capture why this needs the architect plus the technical context required to route it.

The architect is the implicit approver — there's no per-ticket approver field. But the architect needs the full technical picture (PyTorch version, subsystem, HW × accelerator scope) to make an informed call, so those fields are required.

Step 0: Parse Arguments

Parse $ARGUMENTS for:

• --headless: skip clarifying questions (Step 2) and generate directly
• --priority <value>: override default priority (Blocker, Critical, Major, Normal, Minor)
• --kind <value>: pre-set team kind (cross_cutting, dispute, unblock_model_validation)
• --team-id <ID>: pre-assigned TEAM-NNN (used by CI)
• Remaining arguments: the free-form request text

Step 1: Read the Schema

python3 scripts/frontmatter.py schema team-task

The schema in code (scripts/artifact_utils.SCHEMAS) is authoritative — every entry with required: true must be set.

Step 2: Clarifying Questions

If --headless is not set, ask the requester the questions below. Only ask what you cannot reasonably infer from the input.

1. Team kind — cross_cutting, dispute, or unblock_model_validation?
2. Architect routing reason — why does this need the architect? The cross-cutting scope, the points of dispute, or the failing-CI context. Don't accept "the architect should decide" — that's the recommendation, not the reason. The architect needs the what and the why to triage.
3. PyTorch version — exact semver of the impacted version.
4. PyTorch part / subsystem — which surface(s) are affected (distributed, autograd, ATen, dynamo, inductor, ...).
5. Architectures — CPU architectures in scope (x86_64, aarch64, or both).
6. HW × accelerator targets — which SKUs and which accelerator+version pairs (ROCm:6.2, CUDA:12.4, ...). CPU-only is CPU (no version). Required even when the work is cross-vendor.
7. Deadline + priority — ISO date, and a Jira priority value.

Ask these only if hinted — optional:

• Failing run URL — URL to the broken CI run. Required when team_kind: unblock_model_validation (the review will fail otherwise); the create skill should push back to get one.
• Validation definitions — which CI/test suites are in play. Most team asks won't need this (they're decision requests, not deliverables); ask only when the routing reason references specific suites.
• Design reference — URL or prose pointer to context (a design doc, an architect Slack thread).
• Dependency updates — pinned-version changes.

Do NOT ask how the architect should resolve the ask. The HOW is the architect's call; this skill captures the routing request.

Step 3: Generate the Artifact

Allocate the ID (skip if --team-id was passed):

python3 scripts/next_id.py team 1

Use the returned TEAM-NNN as the filename: artifacts/team-tasks/TEAM-NNN.md.

Write the body with this skeleton — the body is more important here than in other pipelines because the architect reads it for routing context:

## Context

<2-4 sentences: what is happening, who is affected, and why it needs
 architect prioritization>

## Constraints

<deadlines, blocked teams, prior failed attempts, pinned deps>

## Out of scope

<things the architect should NOT try to solve here>

Then set frontmatter (status=Draft always):

python3 scripts/frontmatter.py set artifacts/team-tasks/TEAM-NNN.md \
    team_id=TEAM-NNN \
    title="<one-line title>" \
    team_kind=<cross_cutting|dispute|unblock_model_validation> \
    requester="<name <email>>" \
    architect_routing_reason="<the why-architect explanation>" \
    pytorch_version=<semver> \
    pytorch_part=<subsystem> \
    architectures=<csv of x86_64,aarch64,...> \
    hw_targets=<csv> \
    accelerator_targets="<csv of CPU or type:version>" \
    requested_completion=<YYYY-MM-DD> \
    priority=<Blocker|Critical|Major|Normal|Minor> \
    status=Draft

Set optional fields only if the requester provided them:

• failing_run_url="<URL>" — required for unblock_model_validation
• validation_definitions=<csv> — only when CI suites are in play
• design_reference="<URL or prose pointer>"
• dependency_updates=<csv> — pinned-version changes

Rebuild the team index:

python3 scripts/frontmatter.py rebuild-index --pipeline team

Step 4: Hand off

Tell the user:

• The artifact path and team_id
• They can edit the file directly before proceeding
• Run /torch.team.review to validate it
• Re-run /torch.team.create to start over

What NOT to Do

• Do NOT accept a vague architect_routing_reason like "the architect should decide" — that's the recommendation, not the reason. The architect needs the what and the why to triage.
• Do NOT skip failing_run_url when team_kind: unblock_model_validation. The review will fail without it; push back at create time.
• Do NOT prescribe how the architect should resolve the ask — only capture the routing request.
• Do NOT use High/Medium/Low for priority. Use the Jira values.
• Do NOT call the Jira REST API directly. Only /torch.team.submit writes.

$ARGUMENTS