home / skills / derklinke / codex-config / linear-issue-workflow

linear-issue-workflow skill

/skills/linear-issue-workflow

This skill processes Linear issues in order, enforcing In Progress to In Review transitions and reporting changes with build and test confirmation.

npx playbooks add skill derklinke/codex-config --skill linear-issue-workflow

Review the files below or copy the command above to add this skill to your agents.

Files (1)

SKILL.md

1.0 KB

---
name: linear-issue-workflow
description: Use when user provides a list of Linear issue IDs to fix sequentially; enforce status transitions (In Progress -> In Review), one issue at a time, and report build/test confirmation strategy.
---

# Linear Issue Workflow

Use this skill when user gives multiple Linear issue IDs and wants sequential fixes.

## Workflow

- Process issues strictly in order. One active issue at a time.
- Before coding each issue: fetch issue details, set status to `In Progress`.
- After implementing: set status to `In Review` (never Done unless explicitly asked).
- If blocked: stop and ask with short options.

## Build/Test Confirmation Strategy

- Default: run full gate via `just` (`just lint`, `just test`, `just build`) before handoff.
- If user asks to skip or system constraints prevent it: say so and ask for follow-up confirmation.

## Communication

- State which issue is active.
- Keep updates terse; list files changed.
- After each issue: brief verify steps or note skipped runs.

Overview

This skill enforces a strict, sequential workflow for fixing multiple Linear issue IDs provided by the user. It ensures only one issue is active at a time, manages status transitions from In Progress to In Review, and requires a build/test confirmation strategy before handoff. Communication is terse and focused: active issue, files changed, and verification notes.

How this skill works

When given a list of Linear issue IDs, the skill fetches each issue in order and sets its status to In Progress before any code changes. After implementation, it sets the issue to In Review (never Done unless explicitly requested) and reports the files changed. It also runs or requests confirmation for the build/test gate (default: just lint, just test, just build) and stops to ask if the issue is blocked.

When to use it

You have multiple Linear issue IDs and want them addressed sequentially.
You need strict status control to avoid parallel work on related issues.
You require a consistent build/test confirmation before handing off changes.
You want concise status updates that list active issue and changed files.
You prefer the workflow to halt when an issue is blocked for quick resolution.

Best practices

Provide issue IDs in the exact order you want them processed.
Allow the default gate (just lint/test/build) to run unless constraints exist.
If you need an issue marked Done, state that explicitly in the request.
When blocked, reply promptly to the short options so the workflow can continue.
Keep updates concise: active issue, files changed, and whether tests/build ran.

Example use cases

Fix three bug issues in sequence so each has a clean In Review handoff.
Work through a prioritized backlog where only one issue should be active at a time.
Run quick fixes but ensure lint/test/build completed before creating PRs.
Pause the workflow when a dependency or clarification is required and request input.
Enforce team policy that reviewers only get issues that were set to In Review after tests passed.

FAQ

What happens if an issue is blocked?

The workflow stops and asks a short-choice question (e.g., wait, skip, provide details) so you can resolve the blocker before continuing.

Can I skip the build/test steps?

You can request skipping, but the skill will report that runs were skipped and ask for explicit confirmation before handoff.

Will the skill mark issues Done?

No. Issues are set to In Review after implementation. Marking Done requires an explicit user instruction.