chore(dx): make L-N sequence numbering opt-in in linear-issue skill#3241
Conversation
Default to Linear's manual ordering and native blocked-by/blocks relationships for execution order; apply L-N. title prefixes only when the user explicitly asks. Gate the renumber workflow on projects that already opted into L-N. Refines #3233.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughThe Linear issue skill documentation updates multi-issue execution order: defaults to Linear manual ordering plus native ChangesLinear Issue Skill Execution Order Policy
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Possibly related PRs
Suggested labels
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.claude/skills/linear-issue/SKILL.md:
- Around line 128-135: Clarify precedence between “When NOT to apply” and
“Adding issues to a sequenced project”: add one explicit sentence to the “When
NOT to apply (even within an opt-in sequence)” paragraph stating that the
“single-issue creates (one-off bug, lone chore) — un-prefixed” exception does
NOT apply if the target project already uses the L-N. sequencing, and that in
that case the “Adding issues to a sequenced project” flow governs and the new
issue must be created with the appropriate L-N. prefix and insertion/renumbering
procedure; keep the detailed insertion steps in the existing “Adding issues to a
sequenced project” section as the authoritative workflow.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 6d5345a8-07ff-4a52-b5d9-6175bf3ec60a
📒 Files selected for processing (1)
.claude/skills/linear-issue/SKILL.md
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.claude/skills/linear-issue/SKILL.md (1)
210-210:⚠️ Potential issue | 🟠 Major | 🏗️ Heavy liftClarify when the sequenced-project flow is triggered during create-mode.
Lines 210 and 270 say to apply
L-N.prefixes "only if the user opted into" numbering, but the "Adding issues to a sequenced project" flow (lines 395-411) should trigger whenever the target project already usesL-N.— regardless of whether the user explicitly requested numbering in the current command.The sequenced-project section is placed under "Improve Existing Issues," but line 134 says it applies when "adding to an already-numbered project later." This placement could cause the skill to miss triggering it during Phase 4-5 when creating new issues in a numbered project.
Consider either: (a) moving the sequenced-project flow earlier and integrating it into Phase 4, or (b) adding explicit routing logic in Phase 4 that says "if target project uses
L-N., follow the sequenced-project flow instead."Also applies to: 395-397
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.claude/skills/linear-issue/SKILL.md at line 210, The sequenced-project routing is ambiguous: ensure the "Adding issues to a sequenced project" flow is triggered whenever the target project already uses L-N. numbering, not only when the user opts into numbering; update the create-mode/Phase 4 routing so that when creating or adding issues the logic checks the target project's numbering state and routes to the "sequenced-project" flow (the section titled "Adding issues to a sequenced project") instead of the default create flow, and move or reference that section out of "Improve Existing Issues" into Phase 4 or add explicit decision logic in Phase 4 that says "if target project uses L-N., follow sequenced-project flow".
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.claude/skills/linear-issue/SKILL.md:
- Line 130: Update the guidance at the Improve-mode rule that currently states
"don't retrofit a prefix" (near the Improve-mode edits paragraph) to cover the
numbered-project edge case: when improving an un-prefixed issue that belongs to
a project using `L-N.` numbering, change the text to recommend the skill should
warn the user about the missing prefix and offer an explicit option to add the
correct `L-N.` prefix (or skip) rather than silently leaving it un-prefixed;
also add a cross-reference to the "Adding issues to a sequenced project" section
so readers understand sequence-consistency requirements and the available
behaviors (warn+offer-to-add, leave, or abort).
---
Outside diff comments:
In @.claude/skills/linear-issue/SKILL.md:
- Line 210: The sequenced-project routing is ambiguous: ensure the "Adding
issues to a sequenced project" flow is triggered whenever the target project
already uses L-N. numbering, not only when the user opts into numbering; update
the create-mode/Phase 4 routing so that when creating or adding issues the logic
checks the target project's numbering state and routes to the
"sequenced-project" flow (the section titled "Adding issues to a sequenced
project") instead of the default create flow, and move or reference that section
out of "Improve Existing Issues" into Phase 4 or add explicit decision logic in
Phase 4 that says "if target project uses L-N., follow sequenced-project flow".
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 33d58628-52a5-437c-ba08-87b6d0974f24
📒 Files selected for processing (1)
.claude/skills/linear-issue/SKILL.md
…rojects Clarify that L-N opt-in governs starting a sequence; continuing an existing one is automatic. Add Phase 4 routing and improve-mode guidance for un-prefixed issues in numbered projects.
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
2 participants
Why
Follow-up to #3233, which taught the
linear-issueskill to always prefix multi-issue plan titles withL-1.,L-2., … In practice the leading number is too intrusive:L-N.pollutes the title and hurts search/filtering, and—since Linear issues already have global IDs likeCON-123—causes confusion.This refines the convention so manual ordering is the default and
L-N.numbering is opt-in.What
Skill-file-only change to
.claude/skills/linear-issue/SKILL.md:blocked by/blocksrelationships (hard deps), with no title prefix — even for multi-issue plans.L-N.moved into an explicit opt-in subsection (only when the user asks for visible numbering).L-N.prefix only when opted in.L-N.; otherwise just create and let manual ordering place the issue.No code, lint, or type impact.
Summary by CodeRabbit
L-N.) is opt-in