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
@@ -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.