Onex Plan Ticket

---
name: "onex-plan-ticket"
description: >-
  Use this skill when the user has a plan or task description and needs a ticket contract template with deterministic repo detection and YAML output.
disable-model-invocation: true
---

# onex-plan-ticket

Use this skill when the user has a plan or task description and needs a ticket contract template with deterministic repo detection and YAML output.

## Purpose

Generate a structured YAML ticket contract template that can be handed to a team's ticket creation workflow or used as input to Linear (Stage 2). The skill uses deterministic repo detection to pre-fill the target repository.

## Prerequisites

- A plan document path or task description from the user
- Access to README.md in the repository root (for repo detection)

## Workflow

1. **Bounded context read.**
   Announce and read README.md. Optionally list one directory relevant to the prompt. Follow `01-codebase-research` constraints.

2. **Deterministic repo detection (3-priority chain).**
   Determine which OmniNode repository this ticket belongs to:
   - **Priority 1 — CWD or prompt match:** Check if the working directory path or user's prompt contains one of the 7 valid repo names (case-insensitive substring). If found, use it.
   - **Priority 2 — README project name:** Check if README.md contains a valid repo name as the project name. If found, use it.
   - **Priority 3 — Ask the user:** If priorities 1 and 2 both fail, present a multiple-choice question listing all 7 repos plus "Other." Wait for the answer.

   Valid repos: `omniclaude`, `omnibase_core`, `omnibase_infra`, `omnidash`, `omniintelligence`, `omnimemory`, `omninode_infra`

3. **Generate the YAML ticket template.**
   Output a YAML contract template pre-filled with context:
   - Derive `title` from the user's prompt (imperative verb form)
   - Set `repo` to the detected repo name
   - Add requirements inferred from the prompt — mark uncertain fields as "FILL IN"
   - Include verification blocks (unit tests, lint)
   - Leave `relevant_files` empty if file paths are unknown

4. **Create the Linear ticket via MCP.**

   Tool names depend on the Linear MCP server configured in Cursor; do not assume a single transport.

   - **Common in this repo’s Cursor setup:** `list_teams` on the Linear plugin, then `save_issue` with `title`, `team` (name or id), and `description` (markdown combining requirements + verification).
   - **Older / OmniClaude-shaped docs** may say `tracker.list_teams` and `tracker.create_issue` with `teamId` — match that *semantics* using whatever parameters your MCP tools actually accept.

   If multiple teams exist and none is obvious, ask the user which team to use. Always list teams (or confirm a single team) before creating the issue. Report the created ticket URL to the user.

   **Execute-plan / Omnimarket:** when the user later runs `onex-execute-plan` or the MCP tool `run_ticket_pipeline`, the Linear issue key from the created ticket is passed as **`ticket_id`** (MCP/JSON name). Use the identifier Linear returns (e.g. `OMN-47`), not a made-up prefix.

## Expected Output Format

A YAML contract template (shown in chat for review) containing:
- `title`: imperative description
- `repo`: detected repository name
- `requirements`: list with id, statement, rationale, acceptance criteria
- `verification`: list with id, title, kind, command, expected, blocking
- `context`: relevant_files, patterns_found, notes

Followed by the Linear ticket creation result.

## Quality Checklist

- [ ] Bounded context read was announced before file access
- [ ] Repo detection followed the 3-priority chain exactly
- [ ] YAML template is syntactically valid
- [ ] Title uses imperative verb form
- [ ] Requirements have specific, testable acceptance criteria
- [ ] Verification section includes at least unit tests and lint
- [ ] Teams were resolved (`list_teams` / `tracker.list_teams`, or equivalent) before create (`save_issue` / `tracker.create_issue`, or equivalent)
- [ ] Linear ticket URL is reported to the user