菜单
Start work on a Linear ticket by gathering context, planning, creating a branch/worktree, implementing, testing, opening a draft PR, and updating Linear. Use when invoked as `$linear-plan` or when the user asks to start a Linear ticket.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
End-of-day — draft and post daily comments for tracked tickets missing a comment
Morning startup workflow for daily notes, yesterday summary, agenda, status comments, meeting sections, and daily branch setup. Use when invoked as `$work-start` or when the user asks to start the work day.
Track a Linear ticket or GitHub PR in today's daily note with fields and timestamped activity. Use when invoked as `$work-track` or when the user asks to track a work item.
Use for any question about a codebase, its architecture, file relationships, or project content — especially when graphify-out/ exists, where the question should be treated as a graphify query first. Turns any input (code, docs, papers, images, videos) into a persistent knowledge graph with god nodes, community detection, and query/path/explain tools.
Use for any question about a codebase, its architecture, file relationships, or project content — especially when graphify-out/ exists, where the question should be treated as a graphify query first. Turns any input (code, docs, papers, images, videos) into a persistent knowledge graph with god nodes, community detection, and query/path/explain tools.
Load the shared skill from ~/.agents/skills/linear-plan/SKILL.md.
| name | linear-plan |
| description | Start work on a Linear ticket by gathering context, planning, creating a branch/worktree, implementing, testing, opening a draft PR, and updating Linear. Use when invoked as `$linear-plan` or when the user asks to start a Linear ticket. |
Run an end-to-end Linear ticket workflow. If no ticket ID is provided, ask for one. If the user provides only a number, prefix it with DEVX-. Optional argument: --base <branch>; default is main.
Use the linear-cli:linear-cli skill before running Linear CLI commands.
On macOS, run every linear ... command outside the sandbox on the first
attempt so the CLI can access credentials stored in the system keychain. Use
scoped escalation with prefix_rule: ["linear"]. If a sandboxed command
reports No keyring entry or No API key configured, retry outside the
sandbox before asking the user to authenticate. Never print, log, or expose
linear auth token or an API key.
Fetch:
linear issue view <TICKET-ID> --no-pager
linear issue comment list <TICKET-ID> --json
Extract title, full description, labels, priority, assignee, state, and all clarifying comment threads.
Assign the issue and move it to in-progress:
linear issue update <TICKET-ID> --assignee self --state "In Progress"
Derive a branch name: ben/<ticket-id-lowercase>/<3-5-word-title-slug>.
Analyze the codebase enough to identify likely files, patterns, dependencies, and tests.
Create two alternative plans with different trade-off lenses, unless the user has explicitly asked for a single direct plan. Do not spawn subagents unless the user explicitly authorized parallel agents for this task.
Each plan should include:
Present the plans and stop for user selection before implementation.
After plan approval, create a worktree for the topic branch:
git fetch origin
repo_root=$(git rev-parse --show-toplevel)
if [ "$repo_root" = "$HOME" ]; then
path_key="dotfiles"
else
path_key=$(echo "${repo_root#$HOME/}" | tr '/' '-')
fi
worktree_path="${HOME}/.worktrees/${path_key}/<branch-name>"
git worktree add "${worktree_path}" -b <branch-name> origin/<base-branch>
Run subsequent implementation commands from that worktree.
Post the selected or synthesized plan to Linear:
linear issue comment add <TICKET-ID> --body-file /tmp/linear-plan-<TICKET-ID>.md
Save the plan comment URL or ID for later test-result replies.
Implement the approved plan. Commit in logical groups with conventional commit messages and uppercase ticket references such as Resolves DEVX-696 or Part of DEVX-696.
Push:
git push -u origin <branch-name>
Create a draft PR. Use $pr-create when the repo's standard PR style is sufficient; otherwise create with ticket-specific labels such as D-skip-changelog, K-*, A-*, S-*, and P-* as appropriate.
Run the approved test plan. Fix straightforward failures and commit fixes separately. If a failure is ambiguous or high-risk, pause and report.
Reply to the plan thread with test results and PR link. Update the PR description with completed test-plan items. Final report must include PR URL, test status, and any manual follow-up.