From 8226d00130886508e034bba2063c698a2d457bbb Mon Sep 17 00:00:00 2001 From: VinPropane Date: Fri, 24 Apr 2026 21:47:17 -0400 Subject: [PATCH 1/2] =?UTF-8?q?chore:=20story-end=20=E2=80=94=20require=20?= =?UTF-8?q?prominent=20Linear=20state=20ask=20after=20end=20story?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .cursor/rules/story-end.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/.cursor/rules/story-end.md b/.cursor/rules/story-end.md index aa91b3e..b4fa522 100644 --- a/.cursor/rules/story-end.md +++ b/.cursor/rules/story-end.md @@ -31,6 +31,16 @@ If the user asks to **push** changes that sit on **`main`** and **`git push orig - **Do not** call Linear `save_issue` to change **state** until the user has **explicitly** chosen the target status. Typical names here are **`In Test`** or **`Done`**; use `list_issue_statuses` (Linear MCP, server **`plugin-linear-linear`**) if names differ on your team. - If the user only says “end story” / “merge cleanup” / similar **without** naming a target status: run the **git** steps in §2, then **ask** which **Linear state** to set (e.g. **In Test** vs **Done**) and **wait for their answer** before updating the issue. **Never assume Done** without that confirmation. + +### 4a. Required ask (agents — do not skip) + +After §2 (and any local branch deletes that succeeded), the **next reply to the user** must include a **clear, dedicated question** about Linear — not only implied by “per project rules” or buried after long git output. + +Use a short opening like this (adapt issue key if known from branch / context): + +> **Which Linear state should we set this story to?** (e.g. **In Test** or **Done**.) Reply with the **status name** and **issue key** (e.g. **NEO-25**) if more than one ticket could apply. + +Then you may summarize git results below that question. - **Exception:** If the **same user message** already names the status (e.g. “end story, move NEO-18 to **Done**”), you may update Linear after git cleanup without a second ask. - When Linear MCP is available, perform the update with **`save_issue`** (`id` = issue identifier, `state` = chosen status). - If MCP is unavailable or the update fails, tell the user and ask them to update Linear manually. From 9415ea0a0a289871a4e3b5ce83553e2c20e92ccb Mon Sep 17 00:00:00 2001 From: VinPropane Date: Fri, 24 Apr 2026 21:50:05 -0400 Subject: [PATCH 2/2] chore: AskQuestion multiple choice for end-story Linear state --- .cursor/rules/story-end.md | 30 +++++++++++++++++++----------- .cursor/rules/story-kickoff.md | 1 + AGENTS.md | 2 +- 3 files changed, 21 insertions(+), 12 deletions(-) diff --git a/.cursor/rules/story-end.md b/.cursor/rules/story-end.md index b4fa522..4106e73 100644 --- a/.cursor/rules/story-end.md +++ b/.cursor/rules/story-end.md @@ -30,21 +30,29 @@ If the user asks to **push** changes that sit on **`main`** and **`git push orig ## 4. Linear issue status - **Do not** call Linear `save_issue` to change **state** until the user has **explicitly** chosen the target status. Typical names here are **`In Test`** or **`Done`**; use `list_issue_statuses` (Linear MCP, server **`plugin-linear-linear`**) if names differ on your team. -- If the user only says “end story” / “merge cleanup” / similar **without** naming a target status: run the **git** steps in §2, then **ask** which **Linear state** to set (e.g. **In Test** vs **Done**) and **wait for their answer** before updating the issue. **Never assume Done** without that confirmation. - -### 4a. Required ask (agents — do not skip) - -After §2 (and any local branch deletes that succeeded), the **next reply to the user** must include a **clear, dedicated question** about Linear — not only implied by “per project rules” or buried after long git output. - -Use a short opening like this (adapt issue key if known from branch / context): - -> **Which Linear state should we set this story to?** (e.g. **In Test** or **Done**.) Reply with the **status name** and **issue key** (e.g. **NEO-25**) if more than one ticket could apply. - -Then you may summarize git results below that question. +- If the user only says “end story” / “merge cleanup” / similar **without** naming a target status: run the **git** steps in §2, then run **§4a** (required ask) and **wait for the user’s choice** before updating the issue. **Never assume Done** without that confirmation. - **Exception:** If the **same user message** already names the status (e.g. “end story, move NEO-18 to **Done**”), you may update Linear after git cleanup without a second ask. - When Linear MCP is available, perform the update with **`save_issue`** (`id` = issue identifier, `state` = chosen status). - If MCP is unavailable or the update fails, tell the user and ask them to update Linear manually. +### 4a. Required ask (agents — do not skip) + +After §2 (and any local branch deletes that succeeded), prompt for the **Linear next state** in a way that matches **story kickoff** blocking decisions: **selectable multiple choice when the product supports it**, not only free-form prose buried after long git output. + +**Preferred (Agent mode):** Use Cursor’s **`AskQuestion`** tool (multiple-choice) as the **first** user-facing step after git, **before** a long git dump—or put a **one-line** git summary first, then **`AskQuestion`** immediately. Example question: + +- **Prompt:** `Which Linear state should we set this story to?` (name the **issue key** in the prompt if known, e.g. **NEO-25**, or ask which issue in a second question if ambiguous.) +- **Options** (adapt labels to `list_issue_statuses` for the **Neon Sprawl** team—or the issue’s team—if names differ): + - **`in-test`** → label **In Test** + - **`done`** → label **Done** + - **`skip`** → label **Skip — do not change Linear** (user can clarify in chat afterward) + +After the user selects **`in-test`** or **`done`**, call **`save_issue`** with `state` matching that status (name or type from Linear). If they pick **`skip`**, do not call `save_issue` for state. + +**Fallback (no `AskQuestion`, e.g. Ask mode):** Use the prose template: ask which **status name** and **issue key**, with **In Test** / **Done** / **Skip** spelled out. + +Then give any **git** details (branch deleted, `main` ahead, etc.) **after** the question or below the choice result. + ## Related - [story-kickoff](story-kickoff.md) — start of story workflow diff --git a/.cursor/rules/story-kickoff.md b/.cursor/rules/story-kickoff.md index 789718d..bcb1ab8 100644 --- a/.cursor/rules/story-kickoff.md +++ b/.cursor/rules/story-kickoff.md @@ -11,6 +11,7 @@ When the user starts work on a **Linear issue** (e.g. issue key `NEO-5`, phrases - During kickoff and while drafting the plan, **ask the user** about anything **unclear**, **underspecified**, or that **needs a decision** (scope, behavior, acceptance criteria, priorities, trade-offs, or what is out of scope). Do not guess or pick silent defaults when the issue, Linear notes, or repo context do not settle it. - Use **concrete questions**, often with short options when helpful; group related questions so the user can answer in one pass. +- When the Cursor session supports it (**Agent** mode), prefer **`AskQuestion`** multiple-choice for blocking decisions (same pattern as [story-end](story-end.md) §4a for **Linear state** after “end story”) instead of only long prose lists. ## 1. Load Linear context diff --git a/AGENTS.md b/AGENTS.md index 2704c47..a9714cc 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -7,6 +7,6 @@ Optional **personas** for Cursor. Enable by **@ mentioning** the rule in chat or | **Code review** | [`.cursor/rules/code-review-agent.md`](.cursor/rules/code-review-agent.md) | PR / diff / pre-merge review; **always writes** `docs/reviews/YYYY-MM-DD-{slug}.md` with **Documentation checked** vs `docs/plans/` and `docs/decomposition/modules/`; **when suggestions are fixed, strike through those bullets + `Done.` in that file** ([planning-implementation-docs](.cursor/rules/planning-implementation-docs.md)); short chat pointer | | **Docs review** | [`.cursor/rules/docs-review-agent.md`](.cursor/rules/docs-review-agent.md) | Coherence / links / dev-guide fitness for `docs/` (especially `docs/game-design/` + decomposition); **writes** `docs/reviews/YYYY-MM-DD-{slug}.md`; **when suggestions are fixed, strike through + `Done.` in that file** ([planning-implementation-docs](.cursor/rules/planning-implementation-docs.md)); use when working in **documents** or @ mention | -Project-wide conventions live under [`.cursor/rules/`](.cursor/rules/) (many are `alwaysApply`). **Planning / implementation decisions** must be written into `docs/plans/` (and related docs)—[`.cursor/rules/planning-implementation-docs.md`](.cursor/rules/planning-implementation-docs.md). **Manual QA checklists** for user-visible ticketed work are generated during implementation at `docs/manual-qa/{KEY}.md` (same rule). **Godot client layout** (thin `main.gd`, split by concern): [`.cursor/rules/godot-client-script-organization.md`](.cursor/rules/godot-client-script-organization.md). **Git:** agents may **commit** at discretion on story/ticket work; **never** `git push` unless the user asks — [`.cursor/rules/commit-and-review.md`](.cursor/rules/commit-and-review.md). **Open PR:** when the user asks, use **`gh pr create`** with a title starting **`NEO-123:`** (same rule file). **Story lifecycle:** kickoff [`.cursor/rules/story-kickoff.md`](.cursor/rules/story-kickoff.md); after merge / end of story — `checkout main`, `pull`, delete local story branch — [`.cursor/rules/story-end.md`](.cursor/rules/story-end.md). **Linear:** ask which **state** to set (e.g. **In Test** vs **Done**), or wait for the user to say which in the same message, **before** updating the issue; do not guess. **PR / push text:** no “Made-with: Cursor” boilerplate (same file). +Project-wide conventions live under [`.cursor/rules/`](.cursor/rules/) (many are `alwaysApply`). **Planning / implementation decisions** must be written into `docs/plans/` (and related docs)—[`.cursor/rules/planning-implementation-docs.md`](.cursor/rules/planning-implementation-docs.md). **Manual QA checklists** for user-visible ticketed work are generated during implementation at `docs/manual-qa/{KEY}.md` (same rule). **Godot client layout** (thin `main.gd`, split by concern): [`.cursor/rules/godot-client-script-organization.md`](.cursor/rules/godot-client-script-organization.md). **Git:** agents may **commit** at discretion on story/ticket work; **never** `git push` unless the user asks — [`.cursor/rules/commit-and-review.md`](.cursor/rules/commit-and-review.md). **Open PR:** when the user asks, use **`gh pr create`** with a title starting **`NEO-123:`** (same rule file). **Story lifecycle:** kickoff [`.cursor/rules/story-kickoff.md`](.cursor/rules/story-kickoff.md); after merge / end of story — `checkout main`, `pull`, delete local story branch — [`.cursor/rules/story-end.md`](.cursor/rules/story-end.md). **Linear:** on **end story**, use **`AskQuestion`** multiple choice for **In Test** / **Done** / **Skip** when Agent mode supports it ([story-end](.cursor/rules/story-end.md) §4a); otherwise ask in prose. Wait for the choice (or the same message naming the state) **before** `save_issue`; do not guess. **PR / push text:** no “Made-with: Cursor” boilerplate (same file). **Commits tied to a Linear issue** must start the subject with the **issue id** and a colon (e.g. `NEO-8: …`). Branch naming and exceptions (`chore:` when there is no ticket) — [`.cursor/rules/linear-git-naming.md`](.cursor/rules/linear-git-naming.md).