diff options
| author | Paul Buetow <paul@buetow.org> | 2026-04-09 08:31:10 +0300 |
|---|---|---|
| committer | Paul Buetow <paul@buetow.org> | 2026-04-09 08:31:10 +0300 |
| commit | 68373439d4ab92f0b988bfbc42f38d7f6edbbc2b (patch) | |
| tree | f0efd8257765cfdd6c73b419550c2bb458bf890a /prompts | |
| parent | 2150ed27d539a0adc7c3a74c9f16a2a20988e37a (diff) | |
Add run-command skill; use full path for do CLI in agent-task-management
Document running prompts from ~/Notes/Prompts/commands by command name,
placeholder mapping, and positional arguments. Update task-management
skill and references to invoke ~/go/bin/do explicitly.
Made-with: Cursor
Diffstat (limited to 'prompts')
8 files changed, 97 insertions, 55 deletions
diff --git a/prompts/skills/agent-task-management/SKILL.md b/prompts/skills/agent-task-management/SKILL.md index a12d4e6..f51e903 100644 --- a/prompts/skills/agent-task-management/SKILL.md +++ b/prompts/skills/agent-task-management/SKILL.md @@ -1,33 +1,33 @@ --- name: agent-task-management -description: "Manage agent tasks scoped to the current git project using the `do` CLI. Use when asked to list, add, start, complete, annotate, or organize tasks for the project. Prefer compaction over starting a new context when beginning a new task. May start work in parallel (e.g. multiple sub-agents on different tasks) as long as agents do not conflict with each other. Triggers on: tasks, todo, task list, pick next task, what's next." +description: "Manage agent tasks scoped to the current git project using the `~/go/bin/do` CLI. Use when asked to list, add, start, complete, annotate, or organize tasks for the project. Prefer compaction over starting a new context when beginning a new task. May start work in parallel (e.g. multiple sub-agents on different tasks) as long as agents do not conflict with each other. Triggers on: tasks, todo, task list, pick next task, what's next." --- # Agent Task Management -Tasks are scoped to the current git repository via the `do` CLI. **Load only the files you need** for the current action so the whole skill does not need to be in context. +Tasks are scoped to the current git repository via the `~/go/bin/do` CLI. **Load only the files you need** for the current action so the whole skill does not need to be in context. -The `do` CLI provides subcommands (`list`, `ready`, `add`, `info`, `start`, `stop`, `done`, `annotate`, `modify`, `tag`, `priority`, `dep`, `delete`, `urgency`) that operate on agent-managed tasks in the current project. `do` is not a natural-language interface and does not understand skill names. Use normal subcommand syntax only. +The task CLI at `~/go/bin/do` provides subcommands (`list`, `ready`, `add`, `info`, `start`, `stop`, `done`, `annotate`, `modify`, `tag`, `priority`, `dep`, `delete`, `urgency`) that operate on agent-managed tasks in the current project. It is not a natural-language interface and does not understand skill names. Use normal subcommand syntax only. Valid examples: -- `do list` -- `do ready` -- `do add +cli "Add feature X"` # prints `created task <alias-id>` -- `do add +cli depends:0,1 "Add feature X"` -- `do info <id>` -- `do start <id>` -- `do annotate <id> "progress note"` -- `do done <id>` +- `~/go/bin/do list` +- `~/go/bin/do ready` +- `~/go/bin/do add +cli "Add feature X"` # prints `created task <alias-id>` +- `~/go/bin/do add +cli depends:0,1 "Add feature X"` +- `~/go/bin/do info <id>` +- `~/go/bin/do start <id>` +- `~/go/bin/do annotate <id> "progress note"` +- `~/go/bin/do done <id>` Invalid examples: -- `do agent-task-management ...` -- `do list tasks` -- `do show task 298` -- any other natural-language phrasing passed to `do` +- `~/go/bin/do agent-task-management ...` +- `~/go/bin/do list tasks` +- `~/go/bin/do show task 298` +- any other natural-language phrasing passed to `~/go/bin/do` -**Alias IDs are the selectors to use for task work.** `do add` prints `created task <alias-id>`, and subsequent task commands in this workflow should keep using that alias ID throughout the workflow. +**Alias IDs are the selectors to use for task work.** `~/go/bin/do add` prints `created task <alias-id>`, and subsequent task commands in this workflow should keep using that alias ID throughout the workflow. ## Context and compaction diff --git a/prompts/skills/agent-task-management/references/00-context.md b/prompts/skills/agent-task-management/references/00-context.md index 3a08e24..c4f3110 100644 --- a/prompts/skills/agent-task-management/references/00-context.md +++ b/prompts/skills/agent-task-management/references/00-context.md @@ -6,7 +6,7 @@ Load this with any of the action files (1–5) when working with tasks. It defin ## Rules that apply to all task commands -- **Always use `do <subcommand>` for all task operations.** The `do` CLI provides subcommands (`list`, `ready`, `add`, `info`, `start`, `stop`, `done`, `annotate`, `modify`, `tag`, `priority`, `dep`, `delete`, `urgency`) that operate on agent-managed tasks. It is not a natural-language interface and does not understand skill names. -- **Shell note:** On zsh, `do` is a reserved word. From an interactive shell, run the CLI as `command do …` or `\do …` so the shell does not parse `do` as syntax. +- **Always use `~/go/bin/do <subcommand>` for all task operations.** The task CLI is installed at `~/go/bin/do` and provides subcommands (`list`, `ready`, `add`, `info`, `start`, `stop`, `done`, `annotate`, `modify`, `tag`, `priority`, `dep`, `delete`, `urgency`) that operate on agent-managed tasks. It is not a natural-language interface and does not understand skill names. +- **Shell note:** The full path avoids zsh treating `do` as a reserved word. If you invoke a copy on `PATH` named `do`, use `command do …` or `\do …` from an interactive zsh shell. - **One task in progress per project.** Do not start a second task while another is started and not completed, unless the user explicitly asks. - **Parallel work via sub-agents** — the agent may spawn sub-agents to work on tasks in parallel if those tasks would not conflict each other. diff --git a/prompts/skills/agent-task-management/references/1-create-task.md b/prompts/skills/agent-task-management/references/1-create-task.md index 020b865..ad7b11a 100644 --- a/prompts/skills/agent-task-management/references/1-create-task.md +++ b/prompts/skills/agent-task-management/references/1-create-task.md @@ -9,7 +9,7 @@ Use with `00-context.md`. Project name and global rules apply. New tasks get `+a - **Every task MUST have at least one tag** for sub-project/feature/area (e.g. `+integrationtests`, `+flamegraph`, `+bpf`, `+cli`, `+refactor`, `+bugfix`). - **After creating a task, add annotation** — one with the agent workflow reminder: ``` - do annotate <id> "Agent workflow: load the agent-task-management skill as instructions only, not as a shell command. Use only normal do subcommand syntax. Also load and apply: (1) the best-practices skill for the programming language used in the project, (2) solid-principles. When all tests and sub-agent reviews pass, commit and automatically progress to the next ready task." + ~/go/bin/do annotate <id> "Agent workflow: load the agent-task-management skill as instructions only, not as a shell command. Use only normal ~/go/bin/do subcommand syntax. Also load and apply: (1) the best-practices skill for the programming language used in the project, (2) solid-principles. When all tests and sub-agent reviews pass, commit and automatically progress to the next ready task." ``` - **Include references to all context required** to work on the task. So that work can be done with a fresh context, every task must list or link everything needed: relevant files, docs, specs, other tasks, or project guidelines (e.g. paths, doc links, `AGENTS.md`, `README` sections). Put these in the task description or in an initial annotation so that an agent starting with no prior conversation has everything they need in the task itself. @@ -17,28 +17,28 @@ Use with `00-context.md`. Project name and global rules apply. New tasks get `+a ## Add a task -`do add` already injects `project:<name> +agent`, so only add the extra feature tag(s), optional priority, optional `depends:` modifier, and description. +`~/go/bin/do add` already injects `project:<name> +agent`, so only add the extra feature tag(s), optional priority, optional `depends:` modifier, and description. **Each part must be a separate shell argument — never quote tag and description together:** ```bash -do add +<tag> "Description" -do add priority:H +<tag> "Description" -do add priority:M +<tag> "Description" -do add +<tag> depends:<id1>,<id2> "Description" +~/go/bin/do add +<tag> "Description" +~/go/bin/do add priority:H +<tag> "Description" +~/go/bin/do add priority:M +<tag> "Description" +~/go/bin/do add +<tag> depends:<id1>,<id2> "Description" ``` Do NOT do this (causes tag/priority to appear in the description instead of being applied): ```bash -do add "+<tag> Description" # wrong: tag and desc in one quoted string -do add "+<tag> -p M Description" # wrong: everything in one quoted arg +~/go/bin/do add "+<tag> Description" # wrong: tag and desc in one quoted string +~/go/bin/do add "+<tag> -p M Description" # wrong: everything in one quoted arg ``` -`do add` prints `created task <alias-id>`. Reuse that alias ID directly for follow-up commands: +`~/go/bin/do add` prints `created task <alias-id>`. Reuse that alias ID directly for follow-up commands: ```bash -id=$(do add +<tag> "Description" | sed -n 's/^created task //p') -do annotate "$id" "Agent workflow: load the agent-task-management skill as instructions only, not as a shell command. Never run do agent-task-management ... or other natural-language do commands. Use only normal do subcommand syntax. Also load and apply: (1) the best-practices skill for the programming language used in the project, (2) solid-principles, and (3) beyond-solid-principles. When all tests and sub-agent reviews pass, commit and automatically progress to the next ready task." +id=$(~/go/bin/do add +<tag> "Description" | sed -n 's/^created task //p') +~/go/bin/do annotate "$id" "Agent workflow: load the agent-task-management skill as instructions only, not as a shell command. Never run ~/go/bin/do agent-task-management ... or other natural-language ~/go/bin/do commands. Use only normal ~/go/bin/do subcommand syntax. Also load and apply: (1) the best-practices skill for the programming language used in the project, (2) solid-principles, and (3) beyond-solid-principles. When all tests and sub-agent reviews pass, commit and automatically progress to the next ready task." ``` ## With dependency @@ -46,13 +46,13 @@ do annotate "$id" "Agent workflow: load the agent-task-management skill as instr Add dependencies inline during task creation: ```bash -id=$(do add +<tag> depends:<dep-id> "Description" | sed -n 's/^created task //p') +id=$(~/go/bin/do add +<tag> depends:<dep-id> "Description" | sed -n 's/^created task //p') ``` Multiple dependencies: ```bash -id=$(do add +<tag> depends:<dep-id1>,<dep-id2> "Description" | sed -n 's/^created task //p') +id=$(~/go/bin/do add +<tag> depends:<dep-id1>,<dep-id2> "Description" | sed -n 's/^created task //p') ``` After adding (with or without dependency), run the same annotations using that alias ID directly. @@ -61,6 +61,6 @@ After adding (with or without dependency), run the same annotations using that a - **Keep tasks small:** each task should be a chunk that fits in the context window (description + refs + work to do). Split large efforts into multiple dependent tasks. - Pick or create a meaningful tag for the sub-project or feature. -- **Always check for dependencies:** before adding a task, determine if it depends on other tasks in the project; if so, add `depends:<id>,...` during `do add`. +- **Always check for dependencies:** before adding a task, determine if it depends on other tasks in the project; if so, add `depends:<id>,...` during `~/go/bin/do add`. - Add dependencies when one task must complete before another can start. - When creating a task, add references to all required context (files, docs, specs) so the task is self-contained for fresh-context work. diff --git a/prompts/skills/agent-task-management/references/2-start-task.md b/prompts/skills/agent-task-management/references/2-start-task.md index ac3a234..074ed2d 100644 --- a/prompts/skills/agent-task-management/references/2-start-task.md +++ b/prompts/skills/agent-task-management/references/2-start-task.md @@ -15,7 +15,7 @@ The task itself should already contain references to all required context (added ## Finding a task ```bash -do ready | head +~/go/bin/do ready | head ``` ## Mark task as started @@ -23,7 +23,7 @@ do ready | head When you begin working on a task, **always mark it as started** so current work is visible: ```bash -do start <id> +~/go/bin/do start <id> ``` Do this as soon as you start work on the task. @@ -31,6 +31,6 @@ Do this as soon as you start work on the task. ## Conventions - Start each new task with a fresh context; rely on the task's description and annotations for all required context. -- Run `do start <id>` when you start working on the task, not only when listing or completing. +- Run `~/go/bin/do start <id>` when you start working on the task, not only when listing or completing. - Do not start a second task for the same project while one is already started and not done, unless the user explicitly asks. - When a task is selected via the review/overview step, use the alias ID from the list or task details for subsequent `start` operations. diff --git a/prompts/skills/agent-task-management/references/3-complete-task.md b/prompts/skills/agent-task-management/references/3-complete-task.md index 98f48e9..3e18125 100644 --- a/prompts/skills/agent-task-management/references/3-complete-task.md +++ b/prompts/skills/agent-task-management/references/3-complete-task.md @@ -45,19 +45,19 @@ If the answer suggests improvements or inconsistencies, address them first. Only 6. Only then: ```bash -do done <id> +~/go/bin/do done <id> ``` Use the alias ID from the selection step or current task details when marking the task complete. -7. **Automatically progress to the next task in the list.** After marking the task done, if there are more agent-managed tasks in the project (e.g. `do list` shows pending/ready tasks), start the next one: load `00-context.md` and `2-start-task.md`, pick the next task from the list (respecting dependencies and "one task in progress" rule), and begin work on it. Do not stop after completing a task when a next task is available — continue to the next task in the list. +7. **Automatically progress to the next task in the list.** After marking the task done, if there are more agent-managed tasks in the project (e.g. `~/go/bin/do list` shows pending/ready tasks), start the next one: load `00-context.md` and `2-start-task.md`, pick the next task from the list (respecting dependencies and "one task in progress" rule), and begin work on it. Do not stop after completing a task when a next task is available — continue to the next task in the list. ## Conventions - When creating or changing tests, add negative tests (invalid input, errors, failure paths) wherever plausible; the review sub-agent will check for this. - A task is not done until: best practices met, code compiles, all tests pass, negative tests included where plausible, and all first-round review comments are addressed (including coverage and test-quality checks), **and all changes are committed to git**. If code changed after review comments, a second sub-agent review must confirm the updated code. - Before every sub-agent review handoff, do the self-review: "Did it all make sense? Is there a better way?" Fix anything that comes up, then hand off. -- **On completion, commit all changes to git** before running `do done <id>`; do not leave uncommitted work when marking a task complete. -- Complete with `do done <id>` only after completion criteria, self-review(s), first review, addressing all comments, and git commit are satisfied. Add a follow-up sub-agent review only when code changed after review comments. +- **On completion, commit all changes to git** before running `~/go/bin/do done <id>`; do not leave uncommitted work when marking a task complete. +- Complete with `~/go/bin/do done <id>` only after completion criteria, self-review(s), first review, addressing all comments, and git commit are satisfied. Add a follow-up sub-agent review only when code changed after review comments. - When completing a task, note which tasks were unblocked (dependents that became ready), if any. -- **After completing a task, automatically progress to the next task in the list** (when all tests and required sub-agent review(s) pass and the task is done). Start the next ready task from `do ready`; do not stop unless no next task is available or the user asks to stop. +- **After completing a task, automatically progress to the next task in the list** (when all tests and required sub-agent review(s) pass and the task is done). Start the next ready task from `~/go/bin/do ready`; do not stop unless no next task is available or the user asks to stop. diff --git a/prompts/skills/agent-task-management/references/4-annotate-update-task.md b/prompts/skills/agent-task-management/references/4-annotate-update-task.md index d1bb415..b32f90f 100644 --- a/prompts/skills/agent-task-management/references/4-annotate-update-task.md +++ b/prompts/skills/agent-task-management/references/4-annotate-update-task.md @@ -9,13 +9,13 @@ When working on a task, **always read the full context:** description, summary, View full task (including annotations): ```bash -do info <id> +~/go/bin/do info <id> ``` ## Annotate a task ```bash -do annotate <id> "Note about progress or context" +~/go/bin/do annotate <id> "Note about progress or context" ``` While making progress, **add annotations** to reflect progress, challenges, or decisions. You may refer to files, documents, or other resources (paths, doc links, snippets) so the task history stays useful for later work and for the pre-completion review. @@ -25,17 +25,17 @@ Whenever you mention another task inside an annotation (for example, as a depend ## Modify a task ```bash -do modify <id> +<tag> -do dep add <id> <dep-id> -do modify <id> priority:H +~/go/bin/do modify <id> +<tag> +~/go/bin/do dep add <id> <dep-id> +~/go/bin/do modify <id> priority:H ``` -Use the alias ID shown by `do list`, `do ready`, or `do info` when modifying tasks selected earlier or referenced from annotations or other docs. +Use the alias ID shown by `~/go/bin/do list`, `~/go/bin/do ready`, or `~/go/bin/do info` when modifying tasks selected earlier or referenced from annotations or other docs. ## Delete a task ```bash -do delete <id> +~/go/bin/do delete <id> ``` ## Conventions diff --git a/prompts/skills/agent-task-management/references/5-review-overview-tasks.md b/prompts/skills/agent-task-management/references/5-review-overview-tasks.md index 8d85d60..3ad76a2 100644 --- a/prompts/skills/agent-task-management/references/5-review-overview-tasks.md +++ b/prompts/skills/agent-task-management/references/5-review-overview-tasks.md @@ -7,13 +7,13 @@ Use with `00-context.md`. Project name and global rules apply. Only list tasks that have `+agent` (project + tag matching). When listing, order by **priority first, then urgency**: ```bash -do list sort:priority-,urgency- +~/go/bin/do list sort:priority-,urgency- ``` By tag (keep `+agent`, same order): ```bash -do list +<tag> sort:priority-,urgency- +~/go/bin/do list +<tag> sort:priority-,urgency- ``` ## Picking what to work on (next task) @@ -23,14 +23,14 @@ do list +<tag> sort:priority-,urgency- **Check already-started tasks first.** Before suggesting or starting a new task: ```bash -do list start.any: sort:priority-,urgency- +~/go/bin/do list start.any: sort:priority-,urgency- ``` - If any tasks are already started, **use one of those** (pick by priority, then urgency) — do not start a second task unless the user explicitly asks. - Only if no tasks are in progress, show the next actionable (READY) task, ordered by priority then urgency: ```bash -do ready +~/go/bin/do ready ``` Once you have chosen a task from one of these lists, **use its alias ID** from the list output for all subsequent operations and handoffs. When returning or recording the chosen task for another agent or a later step, **include its alias ID**. @@ -38,7 +38,7 @@ Once you have chosen a task from one of these lists, **use its alias ID** from t ## View task details ```bash -do info <id> +~/go/bin/do info <id> ``` Always read description, summary, and **all annotations** when working on or reviewing a task. @@ -48,14 +48,14 @@ Always read description, summary, and **all annotations** when working on or rev Dependency tree (all agent tasks): ```bash -do list +~/go/bin/do list ``` Blocked vs ready (with `+agent`): ```bash -do list +BLOCKED sort:priority-,urgency- -do ready +~/go/bin/do list +BLOCKED sort:priority-,urgency- +~/go/bin/do ready ``` ## Conventions diff --git a/prompts/skills/run-command/SKILL.md b/prompts/skills/run-command/SKILL.md new file mode 100644 index 0000000..c74e93a --- /dev/null +++ b/prompts/skills/run-command/SKILL.md @@ -0,0 +1,42 @@ +--- +name: run-command +description: Runs a slash-style prompt from the user's commands library by command name only; resolves the markdown file automatically and maps user-supplied arguments onto {{placeholders}} in the command. Use when the user mentions run-command, passes parameters after the command name, or should not use a full path to a command .md file. +--- + +# run-command + +## When to Use + +- The user asks to run a slash command via `run-command` or to load a prompt by **name** (not by filesystem path). +- You need to locate the definition for commands like `create-skill`, `update-context`, etc., without hard-coding repo-specific absolute paths. +- The user insists on **command name only**; path resolution is your job. + +## Arguments and parameters + +- **Invocation shape:** `run-command <command-name> [arguments...]` — the first token after `run-command` is always the command basename; everything after it is input for the loaded prompt (not part of the filename). +- **Read the command header** in `<command-name>.md` for a **Parameters:** list (e.g. `skill_name`, `command_name`). Those names match `{{parameter}}` placeholders in the **Prompt** section. +- **Map user input to placeholders:** + - If the user gives **positional** args (e.g. `run-command create-skill docker-compose`), assign them to parameters in the order listed under **Parameters:** (first arg → first parameter, and so on). + - If the user uses **natural language** (e.g. “run create-skill for docker-compose”), infer the same mapping from names and context; ask one short clarifying question only if required parameters are missing or ambiguous. + - If a command defines **one** parameter and the user passes **one** trailing string, treat that string as that parameter’s value. +- **Substitute** every `{{parameter}}` in the prompt with the resolved value before executing the steps. Do not leave unreplaced placeholders. + +## Instructions + +1. **Resolve the command file** from the **command name** (basename, no `.md`): + - Primary: `~/Notes/Prompts/commands/<command-name>.md` + - If that path is missing, try the same basename under any project-local commands folder the user has configured; do not guess random directories. + +2. **Do not** require or construct a full path like `/home/.../dotfiles/prompts/commands/...` unless the user explicitly points you at one. The contract is: **name → single predictable file** under the commands root. + +3. **Read** the resolved `.md` file. Parse the **Parameters:** block and the **Prompt** section (after the `---` separator following metadata). Resolve placeholder values using **Arguments and parameters** above. + +4. **Execute** by following that prompt after substitution; run requested tools and produce the outcome the command describes. + +5. If `<command-name>.md` does not exist, list available `*.md` files in `~/Notes/Prompts/commands/` (or report that the directory is missing) and stop. + +## Examples + +- `run-command create-skill docker-compose` → `command-name` = `create-skill`; first parameter `skill_name` = `docker-compose`; substitute `{{skill_name}}` in the prompt, then execute. +- `run-command create-skill` with no trailing arg → load the file; if the prompt needs `skill_name`, ask the user for it (or use prior message context if clearly stated). +- `run-command review-changes` → no parameters in the header (typical) → run the prompt as written. |
