Require Linear In Progress claim before agent spawn thrash (#670)

Author: TheGreatAxios

plugins/corbits-skills/skills/implement/SKILL.md

@@ -11,6 +11,10 @@ A disciplined implementation workflow that produces reviewed, verified commits.
 
 Before using this workflow, load the `style` and `philosophy` skills. Follow their conventions throughout.
 
+## Linear claim (when applicable)
+
+When the work is tied to a Linear issue ID, claim it **before** greybeard / explore / build thrash: set state to "In Progress" with `mcp__linear__save_issue`. This is a hard first step. Parallel lanes each claim their own issue ID — never claim a sibling lane's ID. If Linear MCP is unavailable or the update fails, report that the issue status could not be updated; do not pretend it was claimed.
+
 ## When to Use
 
 This is a standalone skill, loaded on request. Use it when you want a single agent to work through a series of commits with review discipline.
@@ -152,6 +156,8 @@ Mark the current `manage_tasks` item done. Move to the next unit of work and ret
 
 ## Guidelines
 
+**Claim Linear work first when applicable.** When tied to a Linear issue: claim "In Progress" with `mcp__linear__save_issue` before the spawn loop. Parallel lanes claim their own IDs. If Linear MCP is unavailable, report that the issue status could not be updated.
+
 **Close the loop.** Ship → verify → fix → re-verify.
 
 **Do not invent a worker-count or fan-out ceiling.**

plugins/corbits-skills/skills/linear-issue-workflow/SKILL.md

@@ -9,10 +9,14 @@ user-invocable: false
 
 Use this skill when implementing features or fixes tracked in Linear.
 
-## Phase 1: Understand the Issue
+## Phase 1: Fetch and claim
 
 Fetch the Linear issue using `mcp__linear__get_issue`. The returned issue includes title, description, status, branch name, and other metadata you will need later.
 
+**Claim immediately (hard first step):** before worktree setup, explore, plan, or any build thrash, set the issue to "In Progress" with `mcp__linear__save_issue`. Teammates must see ownership before you dig. Parallel lanes each claim their own issue ID — never claim a sibling lane's ID.
+
+If Linear MCP is unavailable or `save_issue` fails when claiming, report that the issue status could not be updated. Do not pretend the claim succeeded.
+
 Ask the user clarifying questions if the scope is unclear before proceeding.
 
 ## Phase 2: Set Up Worktree
@@ -64,8 +68,6 @@ All subsequent work — exploration, planning, implementation, and review — ha
 
    Exception: plans with no structure — no file-by-file breakdown, no enumerated steps, no headings, no nested lists — can be posted as a comment instead. Structural shape, not length, is the test; a single-sentence plan is fine inline, a 10-line bulleted plan is not.
 
-5. Mark the issue as "In Progress" using `mcp__linear__save_issue` with the appropriate state.
-
 ## Phase 4: Implement
 
 Carry out the plan from Phase 3 in the worktree using whichever implementation approach fits the work and your role.

src/agent/directors/skywalker/package.ts

@@ -131,9 +131,9 @@ Do not reclassify COMMUNICATION as ORCHESTRATION just to justify parallel spawn
 - Interview when requirements are fuzzy; consult greybeard on architecture/approach.
 - Use counsel for multi-lane eng plans; clarify before a large fan-out.
 - Path tools are the DIY surface; shell file-writes stay denied. Track fleet work with manage_tasks.
+- When claiming Linear work: set the issue to In Progress via Linear MCP as a hard first step before explore/build thrash. Parallel lanes claim their own IDs. If Linear MCP is unavailable, report that status could not be updated.
 - Optional skills when needed on the primary session: style, philosophy, interview (use_skill is primary-mounted).
 
-
 # Spawn graph
 
 Skywalker = full closed set. Greybeard = limited spawn only (intern/explorer/critic) — not a second primary.