feat(claude): add /work and /yolo Linear workflow skills

Replace the old /work command with two new skills backed by Linear:
- /work: proper flow (plan, PR, CI iteration, review loop)
- /yolo: fast flow (implement, push directly, done)

Both share common config via linear-common/COMMON.md and use
per-project .claude/linear.json for org, team, build commands, etc.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
naps62
2026-04-10 10:38:35 +00:00
parent 3d881785d5
commit 181ee03cc2
5 changed files with 254 additions and 6 deletions
@@ -1,5 +0,0 @@
In a worktrees directory inside the git project's root, create a new worktree for the requested feature.
create the directory if it doesn't exist.
keep the branch name concise, and don't include "claude" in its name.
do all the work for the feature in the new worktree.
run "kitty @ set-tab-title" to set the tab title of this kitty sessionn to "<project>/<feature>"
+5 -1
View File
@@ -23,7 +23,6 @@
# Commands
home.file.".claude/commands/merge.md".source = ./commands/merge.md;
home.file.".claude/commands/update.md".source = ./commands/update.md;
home.file.".claude/commands/work.md".source = ./commands/work.md;
home.file.".claude/commands/download-playlist.md".source = ./commands/download-playlist.md;
# Skills: agents
@@ -51,6 +50,11 @@
home.file.".claude/skills/worktree-compare/SKILL.md".source = ./skills/worktree-compare/SKILL.md;
home.file.".claude/skills/worktree-list/SKILL.md".source = ./skills/worktree-list/SKILL.md;
# Skills: linear workflow
home.file.".claude/skills/linear-common/COMMON.md".source = ./skills/linear-common/COMMON.md;
home.file.".claude/skills/work/SKILL.md".source = ./skills/work/SKILL.md;
home.file.".claude/skills/yolo/SKILL.md".source = ./skills/yolo/SKILL.md;
home.file.".claude/statusline.sh" = {
source = ./statusline.sh;
executable = true;
@@ -0,0 +1,116 @@
# Linear Common - Shared Config & Setup
This document is referenced by the `/work` and `/yolo` skills. Do not invoke it directly.
## Project config
Look for `.claude/linear.json` in the current git repo root (`git rev-parse --show-toplevel`). If it doesn't exist, run **First-time setup** below, then continue.
### Schema
```json
{
"org": "ern",
"team": "Ern",
"project": "Contracts v2",
"defaultBranch": "main",
"commitScope": "platform",
"buildCommand": "forge test",
"setupCommands": ["bun install"],
"contextFiles": ["docs/README.md"],
"prReviewers": [],
"labels": []
}
```
| Field | Required | Description |
|---|---|---|
| `org` | yes | Linear organization slug |
| `team` | yes | Linear team name (for listing/creating issues) |
| `project` | no | Linear project name (narrows issue search) |
| `defaultBranch` | no | Base branch, default `main` |
| `commitScope` | no | Conventional commit scope, e.g. `platform` -> `feat(platform): ...` |
| `buildCommand` | no | Command to verify the build. Run after implementation. |
| `setupCommands` | no | Commands to run inside a new worktree (install deps, etc.) |
| `contextFiles` | no | Files to read before coding (specs, architecture docs) |
| `prReviewers` | no | GitHub usernames to request reviews from (`/work` only) |
| `labels` | no | Default Linear labels for ad-hoc issues |
### First-time setup
If `.claude/linear.json` doesn't exist:
1. Ask the user for: `org`, `team`, and optionally `project`.
2. Ask which optional fields they want. Show the table above.
3. Write the file. Suggest they commit it or gitignore it depending on preference.
4. Continue with the task.
## Linear MCP auth
The Linear MCP server supports one org at a time. Before making Linear API calls, verify the current auth matches the configured `org`. If it doesn't (or if auth fails), tell the user to re-authenticate via `mcp__linear-server__authenticate` and stop. Don't try to work around auth issues silently.
## Task selection
Based on `$ARGUMENTS`:
### Linear issue ID provided (e.g. `ERN-347`)
1. Fetch the issue via Linear MCP (`get_issue`).
2. Read the full description, acceptance criteria, and comments.
### Ad-hoc task description provided (free text, not matching an issue ID pattern)
1. Create a new Linear issue in the configured team (and project if set).
2. Apply any configured default `labels`.
3. Use the provided text as the issue title. If it's long, summarize for the title and use the full text as description.
### No argument (auto-pick)
1. List issues in the configured team/project that are unstarted (Backlog, Todo, Ready, or equivalent).
2. Pick the highest-priority unblocked issue.
3. If none found, tell the user and stop.
**In all cases:**
- Move the issue to "In Progress" immediately.
- Note the issue ID, title, and `gitBranchName` for later use.
- Use `gitBranchName` from the Linear response for branch naming (auto-links in Linear).
## Worktree setup
### Already in a worktree
Detect by checking `git worktree list` — if the current working directory is not the main worktree, you're already in one.
If already in a worktree: stay here. Check out the issue branch if the current branch doesn't match.
### Not in a worktree
1. Create a worktree at `worktrees/<branch-name>` relative to the repo root.
- Use `gitBranchName` from Linear. If unavailable, derive a concise name from the issue title.
- Do NOT include "claude" in branch names.
2. `cd` into the worktree.
3. Run each command in `setupCommands` from the config.
4. Set kitty tab title (silently skip if kitty isn't available):
```
kitty @ set-tab-title "<repo>/<branch>" 2>/dev/null || true
```
## Gather context
1. Read all `contextFiles` from the config.
2. Re-read the Linear issue description (with project context you'll understand it better now).
3. Read `CLAUDE.md` / `AGENTS.md` at the repo root or `.claude/` if they exist, for project conventions.
4. Check recent git history: `git log --oneline -20` to understand current patterns.
## Implementation guidelines
1. Work methodically through the requirements.
2. Commit after each logical step using conventional commits:
- With scope if configured: `feat(scope): description`
- Without: `feat: description`
- Prefixes: `feat`, `fix`, `refactor`, `test`, `docs`, `chore`
3. Follow existing code patterns. Match the style of surrounding code.
4. Write tests appropriate to the project (match existing test patterns and coverage level).
5. Never amend commits — always create new ones.
6. Keep the Linear issue updated if scope changes significantly.
## Rules
- **Never ask the user** during autonomous work unless you hit a genuine blocker (architectural contradiction, missing credentials, ambiguous requirements that could go very wrong).
- **If the build fails**, fix it before pushing.
- **Respect existing project conventions** from CLAUDE.md, AGENTS.md, etc.
@@ -0,0 +1,88 @@
---
name: work
description: "Pick a Linear task (or create one), implement in a worktree, open a PR, and iterate on reviews autonomously"
user-invocable: true
args:
- name: input
description: "A Linear issue ID (e.g. ERN-347), an ad-hoc task description, or omit to auto-pick next unblocked task"
required: false
---
# Work - Proper PR Flow
Autonomous workflow: Linear issue -> worktree -> implementation -> PR -> review iteration -> done.
**First:** Read `~/.claude/skills/linear-common/COMMON.md` for shared setup instructions.
## Workflow
### 1. Setup (from COMMON.md)
- Load project config
- Select task (from `$ARGUMENTS`)
- Set up worktree
- Gather context
### 2. Plan
1. Analyze the issue requirements and the codebase context you gathered.
2. Break the work into logical commits.
3. If the issue is non-trivial, write a brief plan as a comment on the Linear issue.
4. Identify risks or open questions. If they're blocking, ask the user. If not, note them and proceed with best judgment.
### 3. Implement
Follow the implementation guidelines from COMMON.md.
After implementation is complete:
1. Run the `buildCommand` from the config. All checks must pass before opening a PR.
2. If tests fail, fix them. Do not ship broken code.
### 4. Open PR
1. Push the branch: `git push -u origin <branch>`
2. Open a PR with `gh pr create`:
- Title: concise, under 70 characters
- Body format:
```
## Summary
<bullets>
## Linear
Closes <ISSUE-ID>
## Test plan
<what was tested and how>
```
- Request reviewers from `prReviewers` if configured.
3. Move the Linear issue to "In Review" (or equivalent status).
### 5. Review loop
Repeat until the PR is approved and CI passes:
1. Poll for reviews:
```
gh pr view <number> --json reviews,reviewRequests,statusCheckRollup
gh api repos/{owner}/{repo}/pulls/{number}/comments
```
2. For each review comment:
- **Valid feedback**: fix the code, commit, push.
- **Misunderstanding**: reply explaining, resolve the thread.
- Resolve addressed threads via GraphQL:
```
gh api graphql -f query='mutation { resolveReviewThread(input: {threadId: "<ID>"}) { thread { isResolved } } }'
```
- Find thread IDs:
```
gh api graphql -f query='{ repository(owner: "<OWNER>", name: "<REPO>") { pullRequest(number: <N>) { reviewThreads(first: 100) { nodes { id isResolved comments(first: 1) { nodes { body } } } } } } }'
```
3. After addressing all comments, verify the build still passes.
4. Continue until:
- All review threads resolved
- CI checks pass
- No pending review requests
5. Move the Linear issue to "Done" (or "Ready to merge" if that status exists).
@@ -0,0 +1,45 @@
---
name: yolo
description: "Pick a Linear task (or create one), implement in a worktree, push directly with minimal ceremony"
user-invocable: true
args:
- name: input
description: "A Linear issue ID (e.g. ERN-347), an ad-hoc task description, or omit to auto-pick next unblocked task"
required: false
---
# Yolo - Quick Ship Flow
Fast autonomous workflow: Linear issue -> worktree -> implementation -> push -> done. No PRs, no reviews.
**First:** Read `~/.claude/skills/linear-common/COMMON.md` for shared setup instructions.
## Workflow
### 1. Setup (from COMMON.md)
- Load project config
- Select task (from `$ARGUMENTS`)
- Set up worktree
- Gather context
### 2. Implement
Follow the implementation guidelines from COMMON.md. Move fast — this is yolo mode.
- Skip formal planning. Read the issue, understand it, start coding.
- Still write tests if the project has them, but don't block on edge cases.
- Run the `buildCommand` if configured. If it fails, fix it. If a failure is minor and unrelated to your change, warn the user but keep going.
### 3. Ship
1. Push the branch: `git push -u origin <branch>`
2. If the work is complete and self-contained, merge to the default branch:
```
git checkout <defaultBranch>
git merge <branch> --no-edit
git push
git checkout <branch>
```
Only do this if the change is clearly ready. If unsure, just push the branch and let the user decide.
3. Move the Linear issue to "Done".
4. That's it. No PR, no review loop.