菜单
Use when the user says "start" with a Linear issue, asks to start work on a Linear ticket, or wants a new Codex peer agent launched in the current Codex project, usually with Codex App's first-class worktree mode, to work toward a draft PR.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when a tool, library, or framework doesn't support what you need and official docs don't cover it — finding solutions off the happy path. Triggers on "how do I make X do Y", "X doesn't support Y", undocumented behavior, bleeding-edge tool limitations, workarounds for missing features, or when the mainstream answer is "you can't do that"
Iteratively review, refactor, verify, and commit toward less code by sharing primitives and improving functional composition. Use when the user asks for a strict refactor review loop, "get a review strictly for refactoring to less code", "repeat review/fix/commit until empty", or similar wording.
Use when the user says "sync" or wants to commit, rebase, push, and converge this dotfiles repo. Uses just up as the public converge command.
Poll, diagnose, and report on a GitHub PR's CI. Use this skill whenever you're about to watch a PR's CI to a terminal state — after pushing commits to a PR, after /git_sync, when the user says "is CI green", "wait for CI", "check the PR's checks", "monitor CI", "did CI pass", "watch the workflow", "fix CI failures", or any phrasing that asks whether a PR is ready to merge based on its checks. ALSO use proactively whenever you push a commit to a branch that has an open PR — never spin up an ad-hoc `gh pr checks --watch` or count-based poll. This skill is the only authority for PR CI status; ignore any older guidance suggesting otherwise.
Complete GitHub PR review-comment closeout. Use whenever the user asks to address, fix, handle, clear, close, resolve, respond to, or follow up on PR review comments, review threads, requested changes, bot findings, CodeRabbit, Greptile, or Devin review feedback. Addressing a review thread includes a written thread reply and resolving the thread after the fix or justification is pushed.
Orchestrate land-pr, gh-ci, and land-merged into one end-to-end landing pipeline. Use when the user asks to land complete, land and merge, merge on green, finish a PR end to end, or land without another confirmation loop.
| name | start |
| description | Use when the user says "start" with a Linear issue, asks to start work on a Linear ticket, or wants a new Codex peer agent launched in the current Codex project, usually with Codex App's first-class worktree mode, to work toward a draft PR. |
Use this skill for start HEA-1234 style requests: Linear issue context in,
Codex App peer task out.
Given one Linear issue or one explicitly described task, start a peer agent in the current Codex project. Do not model each task as a new Codex project.
Keep these concepts separate:
Use Codex App's first-class worktree mode when the task needs isolation. A worktree is not a new project, and a fork is not a worktree.
Do not create a sibling project directory and then run codex app <new-dir>
as the default flow. That creates the wrong Codex App shape: multiple projects
for one repo.
Do not manually run git worktree add as the default flow. Codex App already
has a first-class worktree flow that allocates a managed worktree, can carry the
starting diff, and runs the selected environment setup.
Default shape:
codex/ branch inside the managed worktreeResolve the Linear issue id from the user request.
Fetch the issue from Linear. Include title, body, link, visual/Figma links, acceptance criteria, and explicit exclusions in the launch prompt.
If the issue is visual, tell the agent to open the Figma links and preserve attached/inline visuals as implementation targets.
Build a prompt that is specific enough for an autonomous agent:
Start the peer in the current Codex project. Prefer Codex App's first-class worktree task flow when the task should be isolated from the current checkout. Use the app's project/thread/worktree actions rather than opening a different workspace path as a new project.
If conversation history should be inherited, fork the session. From the CLI, the session fork surface is:
codex fork <session-id> "<prompt>"
Use codex fork --last "<prompt>" only when the current thread is known to
be the most recent recorded session for this cwd. Do not guess. Do not use
CLI fork by itself as a substitute for Codex App worktree mode.
Report the task/thread handle or the link/action the user should click.
For a batch of issues, prepare one task prompt per issue and launch each as a peer task in the same Codex project. Use managed worktrees for filesystem/git isolation.
For dashboard-style batch starts, the dashboard should expose Codex App task
actions and show the exact prompt before launch. It should not create project
directories, run codex app <new-dir>, or manually create worktrees as a side
effect.
The bundled scripts/start.ts and scripts/dashboard.ts currently implement
the old hand-rolled project-directory model. Treat them as legacy and do not use
them for the default start workflow until they are rewritten around Codex App
project/thread/worktree semantics.
Use a dashboard only when the user wants to review a batch of task prompts before starting them. The desired manifest shape is:
{
"actions": [
{
"id": "HEA-1234",
"title": "Dock controls",
"project": "/absolute/current/project",
"state": "Ready",
"prompt": "Full Codex prompt"
}
]
}
The dashboard must bind to 127.0.0.1, print DASHBOARD <url> on startup, and
report that URL in chat under:
Dashboard Open
The dashboard is intentionally allowlist-shaped: actions come from the manifest or built-in dummy data, prompts are visible before launch, and the route does not accept arbitrary shell commands.