Nested lingtai-issue-report reference for the filing decision — the always-required human consent boundary, the read-only gh probe, Path A (direct gh filing) and Path B (paste-ready handoff), token hygiene, and proactive surfacing. Read this once the report is drafted and you are deciding how it gets filed.
Nested lingtai-issue-report reference for the report skeleton — subject/title format, the structured body sections (what's wrong, where, reproduction, expected vs actual, severity, suggested fix), and how to send it via LingTai email or the human's active channel. Read this when you are ready to assemble the report.
Adversarially review an existing written artifact — stories, plans, acceptance criteria, specs, or design mocks — to surface missing states, unhandled edge cases, unstated assumptions, unverifiable criteria, and slices still too broad or horizontal. Works interactively, one question at a time, writing each answer back into the artifact as a new acceptance criterion, plan update, or mock-state spec. Use when an artifact needs tightening before planning or coding ("what's missing?", "poke holes in this", "tighten this up"). Requires an artifact to inspect — for resolving a fuzzy decision tree with no artifact yet, see grill-me; for splitting oversized work, see story-splitting.
Turn fuzzy intent into shared understanding and acceptance criteria — specification as a conversation, run one question at a time, before any story is split or planned. Use when an idea, feature request, or problem statement has no agreed rules or examples yet ("let's spec this out", "what should this actually do?", "we need acceptance criteria"). Produces an example map and acceptance criteria written back into the team's own story artifact, plus candidate glossary terms and parked questions. The agent-facilitated round is a first draft for a real conversation between humans — recommended, not optional. For decision trees with no artifact, see grill-me; for tightening an existing artifact, see find-gaps; for slicing agreed work, see story-splitting.
Turn broad requirements, large stories, epics, features, initiatives, or backlog items into small end-to-end child stories without turning them into technical component tasks. Use when refining a backlog, decomposing epics, planning an MVP or walking skeleton, looking for vertical slices, reducing story size, applying SPIDR/Hamburger/capability slicing, avoiding scatter-gather/component stories, or deciding the first valuable story before implementation planning.
Generates a two-audience changelog from merged PRs in the FxA monorepo: a plain-language product summary and an engineer handoff with operational notes. Name a train (e.g. "341") or pass any git range; with no argument it defaults to the in-development train on main (the latest release tag up to HEAD — not a deployed stage/prod train), framed as the range the train owner is accountable for. Use for train-owner handoffs, train summaries, or "what shipped" questions.
Drafts a Jira bug report for an FXA issue. Gathers repro steps, expected vs actual behaviour, and affected surface, outputs a structured report, and optionally files the ticket via the Atlassian MCP. Returns the new FXA-N key when filed.
Drafts a concise Jira description for an FXA task. Gathers context via targeted interview, researches relevant patterns in the repo, outputs a clean description, and optionally files the ticket via the Atlassian MCP. Returns the new FXA-N key when filed.