Next

One invocation implements one selected outcome, including all child items and documented prerequisites, and pushes a reviewable PR. It follows configured auto-merge through completion; otherwise it waits for review with the PR open. A necessary blocker can be implemented in the same task; unrelated work remains separate. The user need not name the tracker, choose an item or separately invoke Plimsoll. An optional issue identifier overrides automatic selection; supplied priority and scope constraints always win.

Use the current project and its instructions. Discover integrations and accounts from the environment; never assume a particular workspace, tracker, release provider or consumer. Load the installed plimsoll skill when available. The essential execution rules below also apply when it is unavailable. Use the configured tracker capability, including the linear skill when appropriate.

Adapt to the harness

This skill works through the capabilities exposed by its host: Codex, Claude Code, OpenCode, Cursor or another compatible harness. The portable instructions live here; agents/openai.yaml is optional Codex UI metadata, not a runtime dependency.

Identify the active harness from its supplied context and tools. Use its native skill invocation, project instructions, tracker access, subagent tools, model selection, permission handling and completion notifications. Do not assume Codex tool names, task links, dollar-prefixed invocation syntax or a particular provider's model identifiers are available elsewhere. Use installed help or configuration only when a needed capability is unclear; do not perform a broad environment audit.

Prefer native subagents. If delegation or per-agent model selection is unavailable, use the supported subset, state the limitation once and keep delivering. Parallel tool calls alone are not multiple agents. Do not install another harness, add credentials, change provider configuration or spawn external agent processes merely to manufacture model variety.

Choose the item

Every time an item is selected, announce it before implementation or a tracker status change in one short, plain-language sentence: a clickable tracker identifier followed by the concrete outcome for the person using the product. Assume the user has no prior context. Explain technical ticket titles in everyday words; omit implementation details, jargon and prioritization reasoning. For example: "APP-123: Make search show the matching products instead of an empty page." Use the actual item URL, never the example URL. For already-delivered work, use the same one-sentence format to say what already works and that its ticket status will be corrected. This announcement is mandatory even when no code change is needed; it is information, not an approval request.