菜单
Scaffold a new amos node with proper frontmatter. Use when the user wants to add a new ticket, task, or plan entry tracked by amos. Produces a markdown file with the canonical `@github:<owner>/<repo>#<N>` name, a description, dependencies, and the adapter block.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Pick up and execute the next ready-to-start issue from the focused milestone, end-to-end: announce, gate on user confirmation, branch, do the work, run the tests listed in the issue body, open a PR, report. This is the skill to invoke when the user says "continue", "next task", "what's next", "pick up where we left off", "work on the next issue", "keep going", or similar. It replaces any project-local PROMPT.md protocol.
File a new GitHub issue with a well-shaped body, the right milestone, and native dependency relationships, from a short natural-language intent. Use when the user says "file this", "open an issue for X", "create a ticket", "log this as a bug", when discussion surfaces a new task that should be tracked, or after the assistant offered to file something and the user confirmed. Infers milestone and labels; asks in chat whenever confidence is low.
Load when working with amos nodes — markdown files carrying `whoami: amos` frontmatter — or when the user refers to "the plan", "the DAG", "the roadmap", "the tickets", "what's next", or similar work-tracking concepts. Installs the amos conventions (canonical naming, node format, when to reach for which sub-skill) into context so amos-graph, amos-show, amos-create, and amos-notify can be used correctly. Does not run the CLI on its own.
Set the milestone the user is currently working on. `amos next`, `amos blocked`, and `amos graph` scope their output to this milestone once set. Use when the user says "let's work on <milestone>", "focus on <milestone>", "switch to <milestone>", or wants to check which milestone is currently active. Accepts free-form milestone text — the tool resolves it against the adapter's known titles.
Print the amos dependency tree as a nested ASCII graph. Use when the user asks about open tasks, the roadmap, what's next, what's blocked, what depends on X, or wants a structural view of the plan. Returns every node with status and a short description; does NOT resolve `@github:...` references (use amos-show for full content). Trigger on phrases like "what's on my plate", "what's open", "show me the DAG", "what's blocking X", "what depends on Y", "where are we on <umbrella>".
Post a message to a node's source system through its adapter. For a `@github:...` node, this creates a comment on the referenced issue. Use when the user wants to share status, results, or context with everyone watching the upstream tracker — not for local scratch notes. The message is visible to anyone with access to the tracker.
| name | amos-create |
| description | Scaffold a new amos node with proper frontmatter. Use when the user wants to add a new ticket, task, or plan entry tracked by amos. Produces a markdown file with the canonical `@github:<owner>/<repo>#<N>` name, a description, dependencies, and the adapter block. |
| disable-model-invocation | true |
| argument-hint | <issue-number> <one-line-description> |
| allowed-tools | Bash |
When the user invokes /amos-create, scaffold a new node using the template below. See also
references/node-format.md for the bare template.
<issue-number> — the GitHub (or other adapter) issue number this node represents.<one-line-description> — short routing hint (free-form). This is not the identifier.<owner>/<repo> from the git remote of the current project, or ask the user if
ambiguous.plan/<N>-<kebab-slug>.md---
whoami: amos
name: "@github:<owner>/<repo>#<N>"
status: pending
description: "<one-line routing hint>"
github_issue: <N>
dependencies:
- "down:@github:<owner>/<repo>#<M>" # this node blocks M
- "up:@github:<owner>/<repo>#<K>" # this node waits on K
adapters:
github: builtin
---
@github:<owner>/<repo>#<N>
Local agent instructions below the adapter reference. These persist locally
even when the remote issue body changes.
name: is an identifier, not a title. Always @github:<owner>/<repo>#<N>.description:.github_issue: should match the #N in the name.<N>-<short-kebab-slug>.md under the plan/ directory.Why this matters: every down: / up: edge references another node by its literal name:
string. If you put "Refactor auth module" in name: and later rename it to "Refactor auth", every
edge pointing at the node breaks silently — the DAG edge resolver just finds no match and drops
it. Canonical @github:... names never need renaming; they're stable as long as the issue exists.
down:<target> — this node blocks <target>; <target> is waiting on this.up:<target> — this node is waiting on <target>; <target> blocks this.Prefer writing a single down: on the upstream node over an up: on the downstream. That gives
each edge exactly one source of truth and matches how the CLI is typically used.
adapters: { github: builtin } is the default and enables the built-in GitHub adapter. The
adapter is what lets @github:<owner>/<repo>#<N> references in the body resolve to the issue's
content. Leave as builtin unless wiring a custom adapter.
Run amos-graph to confirm the new node appears and its down: / up: edges resolve:
"$HOME/.local/bin/amos" graph | grep "#<N>"
If an edge target doesn't exist, the new node will appear at the top level (orphaned) instead of nested under its parent.