spec-kitty / spec-kitty/spec-kitty
feat(tracker): add `spec-kitty mission create --from-ticket <provider:ID> --json`
- Dominant language
- Python
- Stars
- 1.6k
- Forks
- 165
- Avg merge
- 14h 52m
- Merged PRs (30d)
- 303
Description
## Summary
Provide the **one-shot machine-readable** external-ticket-to-mission contract needed by live tracker-driven flows.
## Important current-state correction (2026-04-20)
This issue is no longer a pure "command does not exist" gap.
What already exists in `main`:
- `spec-kitty mission create --from-ticket provider:KEY`
- tracker ticket fetch through the hosted read path
- `.kittify/ticket-context.md` generation
- `.kittify/pending-origin.yaml` generation for follow-on specify consumption
What the current implementation does:
- fetches the ticket
- prepares local brief/origin artifacts
- tells the operator to continue with `/spec-kitty.specify`
What is **still missing relative to this issue's original contract**:
- one-shot mission creation in the same command
- `--json` output containing `mission_id`, `slug`, and `origin`
- a machine-readable contract suitable for the live canary if the canary truly depends on immediate mission creation instead of the brief-handoff flow
## Why this matters
`Priivacy-ai/spec-kitty-end-to-end-testing#14` needs an honest way to go from a real external ticket to a real mission without monkeypatched glue. The remaining question is whether the canary needs:
1. the existing ticket-to-brief handoff into `/spec-kitty.specify`, or
2. the stronger one-shot JSON contract described here
If the canary only needs the first path, then part of this issue is already satisfied. If it needs the second path, the remaining work is to upgrade the command contract, not to add the command from scratch.
## Expected behaviour if the stronger contract is required
```bash
$ spec-kitty mission create --from-ticket linear:PRI-42 --json
{
"mission_id": "01KPXXXXXX",
"slug": "pri-42-some-title",
"origin": "linear:PRI-42"
}
```
- creates a new mission in the current repo
- binds the originating ticket as the mission origin
- emits `mission_id`, `slug`, and `origin` in JSON
- posts a backlink comment on the external issue if the live product path requires it
- exits 0 on success, non-zero on failure
## Acceptance criteria
- [ ] confirm whether `Priivacy-ai/spec-kitty-end-to-end-testing#14` can use the existing ticket-context brief handoff or requires one-shot machine-readable mission creation
- [ ] if one-shot creation is required, `spec-kitty mission create --from-ticket --json` exits 0 and prints JSON
- [ ] the written JSON contains `mission_id`, `slug`, and `origin`
- [ ] the mission-origin linkage is durable and queryable
- [ ] the external issue receives the required backlink or origin evidence for the live path
- [ ] running the command again on the same ticket is idempotent or fails clearly
## Related
- `Priivacy-ai/spec-kitty-end-to-end-testing#14`
- `Priivacy-ai/spec-kitty-saas#79`
Contributor guide
Assessment
This issue has not been assessed yet.