---
name: Task Queueing
slug: task-queueing
category: Automation
description: Task Queueing turns an agreed-upon conversation into a queued task with tsk add. Use it when you want to capture a design, bug fix, or feature request as a self-contained prompt for an async agent.
github: "https://github.com/dtormoen/tsk-tsk/tree/main/skills/tsk-add/skills/tsk-add"
language: Rust
stars: 170
forks: 18
install: "npx degit https://github.com/dtormoen/tsk-tsk/tree/main/skills/tsk-add/skills/tsk-add ~/.claude/skills/tsk-add"
installs_to: ~/.claude/skills/tsk-add
source_path: skills/tsk-add/skills/tsk-add/SKILL.md
collection_size: 3
category_size: 2226
collection_url: "https://dirskills.com/collections/dtormoen/tsk-tsk"
added: 2026-09-08T05:33:42.389Z
last_synced: 2026-09-08T05:33:42.389Z
canonical_url: "https://dirskills.com/skills/task-queueing"
---

# Task Queueing

Task Queueing turns an agreed-upon conversation into a queued task with tsk add. Use it when you want to capture a design, bug fix, or feature request as a self-contained prompt for an async agent.

**Install:**

```bash
npx degit https://github.com/dtormoen/tsk-tsk/tree/main/skills/tsk-add/skills/tsk-add ~/.claude/skills/tsk-add
```

## README

# Queue Task from Conversation

You are helping the user queue a task based on the conversation you just had. The user has been discussing a design, architecture decision, or code change with you, and now wants to queue it as an asynchronous task.

## Available Templates

These are the task templates available for use with `tsk add -t <template>`:

```
!`tsk template list`
```

To see the full content of a template, run `tsk template show <template>`. When a task is created, the `{{PROMPT}}` placeholder in the template is replaced with whatever you pipe in via heredoc or pass via the `-p` flag, and any YAML frontmatter is stripped. The result is what gets sent to the agent.

## Your Job

1. **Summarize the agreed-upon work**: Review the conversation above and identify:
   - What change or feature was discussed
   - Key design decisions that were made
   - Any specific files, components, or areas mentioned
   - Acceptance criteria or requirements that were established
   - Ask clarifying questions about requirements, architecture choices, or task details
   - Only proceed once agreement has been reached

2. **Create a task name**: Come up with a short, branch-friendly name (e.g., `add-auth`, `refactor-api`, `fix-validation`)

3. **Pick the best template**: Based on the nature of the task, choose the template from the list above that best matches the work to be done (e.g., `feat` for new features, `fix` for bug fixes, `refactor` for restructuring, `doc` for documentation).

4. **Write the task prompt**: Create a clear, self-contained prompt that includes:
   - The goal of the change
   - Key design decisions from the conversation
   - Specific files or areas to focus on (if discussed)
   - Acceptance criteria

5. **Queue the task**: Use `tsk add` to create the task:
   - If you have already written a plan markdown file, prefer using `--prompt-file`
   - If you do not already have a plan in a file, prefer piping in the input

```bash
tsk add -t <template> -n "<task-name>" <<'EOF'
<task description>
EOF

# Alternatively:

tsk add -t <template> --prompt-file <path_to_the_plan>
```

## Guidelines

- Include enough context that an agent without access to this conversation can understand and execute the task
- Reference specific files, functions, or architectural patterns discussed in the conversation
- If the user provided additional context via $ARGUMENTS, incorporate that as well
- Keep the prompt concise but complete - the agent can explore the codebase for details
- Either pipe in input using HEREDOC format OR use the `-p` flag. They do not work together.

## Example Output When There Is Not a Plan File

```bash
tsk add -t feat -n "add-rate-limiting" <<'EOF'
Add rate limiting to the API endpoints.

### Context
The API currently has no rate limiting, which could allow abuse. We discussed using a token bucket algorithm with Redis for distributed rate limiting.

### Requirements
- Add rate limiting middleware to all /api/* routes
- Use token bucket algorithm: 100 requests per minute per API key
- Store rate limit state in Redis (connection config already exists)
- Return 429 Too Many Requests with Retry-After header when limit exceeded

### Files to Focus On
- src/middleware/ - add new rate limiting middleware
- src/routes/api.ts - apply middleware to routes
- src/config/redis.ts - reuse existing Redis connection

### Acceptance Criteria
- Rate limiting works correctly under load
- Proper error responses with Retry-After header
- Tests cover rate limit enforcement and reset behavior
EOF
```

After queuing the task, remind the user they can run `tsk server start` if the server isn't already running.

## How To Use tsk

`tsk` is installed and on the path. Here are the main commands:
```
!`tsk help`
```

Here are the options for adding tasks:
```
!`tsk add --help`
```