kata-execute-quick-task
Execute small ad-hoc tasks with Kata guarantees, running quick tasks without full planning, or handling one-off work outside the roadmap. Triggers include "quick task", "quick mode", "quick fix", "ad-hoc task", "small task", and "one-off task".
What this skill does
<objective>
Execute small, ad-hoc tasks with Kata guarantees (atomic commits, STATE.md tracking) while skipping optional agents (research, plan-checker, verifier).
Quick mode is the same system with a shorter path:
- Spawns kata-planner (quick mode) + kata-executor(s)
- Skips kata-phase-researcher, kata-plan-checker, kata-verifier
- Quick tasks live in `.planning/quick/` separate from planned phases
- Updates STATE.md "Quick Tasks Completed" table (NOT ROADMAP.md)
Use when: You know exactly what to do and the task is small enough to not need research or verification.
</objective>
<execution_context>
Orchestration is inline - no separate workflow file. Quick mode is deliberately simpler than full Kata.
</execution_context>
<context>
@.planning/STATE.md
</context>
<process>
**Step 0: Resolve Model Profile**
Read model profile for agent spawning:
```bash
MODEL_PROFILE=$(node "${CLAUDE_PLUGIN_ROOT}/skills/kata-execute-quick-task/scripts/kata-lib.cjs" read-config "model_profile" "balanced")
```
Default to "balanced" if not set.
**Model lookup table:**
| Agent | quality | balanced | budget |
| ------------- | ------- | -------- | ------ |
| kata-planner | opus | opus | sonnet |
| kata-executor | opus | sonnet | sonnet |
Store resolved models for use in Task calls below.
---
**Step 1: Pre-flight validation**
Check that an active Kata project exists:
```bash
if [ ! -f .planning/ROADMAP.md ]; then
echo "Quick mode requires an active project with ROADMAP.md."
echo "Run /kata-new-project first."
exit 1
fi
```
If validation fails, stop immediately with the error message.
Quick tasks can run mid-phase - validation only checks ROADMAP.md exists, not phase status.
---
**Step 1.5: Parse issue argument (optional)**
Check for issue file path argument:
```bash
ISSUE_FILE=""
ISSUE_NUMBER=""
ISSUE_TITLE=""
ISSUE_PROBLEM=""
# Check for --issue flag
if echo "$ARGUMENTS" | grep -q -- "--issue"; then
ISSUE_FILE=$(echo "$ARGUMENTS" | grep -oE '\-\-issue [^ ]+' | cut -d' ' -f2)
if [ -f "$ISSUE_FILE" ]; then
# Extract issue metadata
ISSUE_TITLE=$(grep "^title:" "$ISSUE_FILE" | cut -d':' -f2- | xargs)
PROVENANCE=$(grep "^provenance:" "$ISSUE_FILE" | cut -d' ' -f2)
if echo "$PROVENANCE" | grep -q "^github:"; then
ISSUE_NUMBER=$(echo "$PROVENANCE" | grep -oE '#[0-9]+' | tr -d '#')
fi
# Extract problem section for context
ISSUE_PROBLEM=$(sed -n '/^## Problem/,/^## /p' "$ISSUE_FILE" | tail -n +2 | head -n -1)
fi
fi
```
If `ISSUE_FILE` provided but file not found: error and exit.
If `ISSUE_FILE` provided and valid: Use issue title as description (skip Step 2 prompt).
---
**Step 2: Get task description**
**If `$ISSUE_FILE` is set (issue-driven quick task):**
```bash
DESCRIPTION="$ISSUE_TITLE"
echo "Using issue title: $DESCRIPTION"
```
Skip the AskUserQuestion prompt — use the issue title as the description.
**If no issue context (standard quick task):**
Prompt user interactively for the task description:
```
AskUserQuestion(
header: "Quick Task",
question: "What do you want to do?",
followUp: null
)
```
Store response as `$DESCRIPTION`.
If empty, re-prompt: "Please provide a task description."
**Generate slug from description (both paths):**
Generate slug from description:
```bash
slug=$(echo "$DESCRIPTION" | tr '[:upper:]' '[:lower:]' | sed 's/[^a-z0-9]/-/g' | sed 's/--*/-/g' | sed 's/^-//;s/-$//' | cut -c1-40)
```
---
**Step 3: Calculate next quick task number**
Ensure `.planning/quick/` directory exists and find the next sequential number:
```bash
# Ensure .planning/quick/ exists
mkdir -p .planning/quick
# Find highest existing number and increment
last=$(ls -1d .planning/quick/[0-9][0-9][0-9]-* 2>/dev/null | sort -r | head -1 | xargs -I{} basename {} | grep -oE '^[0-9]+')
if [ -z "$last" ]; then
next_num="001"
else
next_num=$(printf "%03d" $((10#$last + 1)))
fi
```
---
**Step 4: Create quick task directory**
Create the directory for this quick task:
```bash
QUICK_DIR=".planning/quick/${next_num}-${slug}"
mkdir -p "$QUICK_DIR"
```
Report to user:
```
Creating quick task ${next_num}: ${DESCRIPTION}
Directory: ${QUICK_DIR}
```
Store `$QUICK_DIR` for use in orchestration.
---
**Step 4.5: Read context files**
Read files before spawning agents using the Read tool. The `@` syntax does not work across Task() boundaries - content must be inlined.
**Read these files:**
- `.planning/STATE.md` (required) — store as `STATE_CONTENT`
- `skills/kata-plan-phase/references/planner-instructions.md` (cross-skill reference) — store as `planner_instructions_content`
- `skills/kata-execute-phase/references/executor-instructions.md` (cross-skill reference) — store as `executor_instructions_content`
Store content for use in Task prompts below.
---
**Step 5: Spawn planner (quick mode)**
Spawn kata-planner with quick mode context:
```
Task(
prompt="<agent-instructions>\n{planner_instructions_content}\n</agent-instructions>\n\n" +
"<planning_context>
**Mode:** quick
**Directory:** ${QUICK_DIR}
**Description:** ${DESCRIPTION}
**Project State:**
${STATE_CONTENT}
**Issue Context (if from issue):**
${ISSUE_FILE:+Issue File: $ISSUE_FILE}
${ISSUE_NUMBER:+GitHub Issue: #$ISSUE_NUMBER}
${ISSUE_PROBLEM:+
Problem:
$ISSUE_PROBLEM}
</planning_context>
<constraints>
- Create a SINGLE plan with 1-3 focused tasks
- Quick tasks should be atomic and self-contained
- No research phase, no checker phase
- Target ~30% context usage (simple, focused)
</constraints>
<output>
Write plan to: ${QUICK_DIR}/${next_num}-PLAN.md
Return: ## PLANNING COMPLETE with plan path
</output>
",
subagent_type="general-purpose",
model="{planner_model}",
description="Quick plan: ${DESCRIPTION}"
)
```
After planner returns:
1. Verify plan exists at `${QUICK_DIR}/${next_num}-PLAN.md`
2. Extract plan count (typically 1 for quick tasks)
3. Report: "Plan created: ${QUICK_DIR}/${next_num}-PLAN.md"
If plan not found, error: "Planner failed to create ${next_num}-PLAN.md"
---
**Step 6: Spawn executor**
Read the plan content before spawning using the Read tool:
- `${QUICK_DIR}/${next_num}-PLAN.md`
Spawn kata-executor with inlined plan (use the STATE_CONTENT from step 4.5):
```
Task(
prompt="<agent-instructions>\n{executor_instructions_content}\n</agent-instructions>\n\n" +
"Execute quick task ${next_num}.
<plan>
${PLAN_CONTENT}
</plan>
<project_state>
${STATE_CONTENT}
</project_state>
<constraints>
- Execute all tasks in the plan
- Commit each task atomically
- Create summary at: ${QUICK_DIR}/${next_num}-SUMMARY.md
- Do NOT update ROADMAP.md (quick tasks are separate from planned phases)
</constraints>
",
subagent_type="general-purpose",
model="{executor_model}",
description="Execute: ${DESCRIPTION}"
)
```
After executor returns:
1. Verify summary exists at `${QUICK_DIR}/${next_num}-SUMMARY.md`
2. Extract commit hash from executor output
3. Report completion status
If summary not found, error: "Executor failed to create ${next_num}-SUMMARY.md"
Note: For quick tasks producing multiple plans (rare), spawn executors in parallel waves per phase-execute patterns.
---
**Step 7: Update STATE.md**
Update STATE.md with quick task completion record.
**7a. Check if "Quick Tasks Completed" section exists:**
Read STATE.md and check for `### Quick Tasks Completed` section.
**7b. If section doesn't exist, create it:**
Insert after `### Blockers/Concerns` section:
```markdown
### Quick Tasks Completed
| # | Description | Date | Commit | Directory |
| --- | ----------- | ---- | ------ | --------- |
```
**7c. Append new row to table:**
```markdown
| ${next_num} | ${DESCRIPTION} | $(date +%Y-%m-%d) | ${commit_hash} | [${next_num}-${slug}](./quick/${next_num}-${slug}/) |
```
**7d. Update "Last activity" line:**
Find and update the line:
```
Last activity: $(date +%Y-%m-%d) - Completed quick task ${next_num}: ${DESCRIPTION}
```
Use Edit tool to make these changes atomically
---
**SteRelated in Ads & Marketing
ads
IncludedMulti-platform paid advertising audit and optimization skill. Analyzes Google, Meta, YouTube, LinkedIn, TikTok, Microsoft, and Apple Ads. 250+ checks with scoring, parallel agents, industry templates, and AI creative generation.
banana
IncludedAI image generation Creative Director powered by Google Gemini Nano Banana models. Use this skill for ANY request involving image creation, editing, visual asset production, or creative direction. Triggers on: generate an image, create a photo, edit this picture, design a logo, make a banner, visual for my anything, and all /banana commands. Handles text-to-image, image editing, multi-turn creative sessions, batch workflows, and brand presets.
rpg-migration-analyzer
IncludedAnalyzes legacy RPG (Report Program Generator) programs from AS/400 and IBM i systems for migration to modern Java applications. Extracts business logic from RPG III/IV/ILE source code, identifies data structures (D-specs), file operations (F-specs), program dependencies (CALLB/CALLP), and converts RPG constructs to Java equivalents. Generates migration reports, complexity estimates, and Java implementation strategies with POJO classes, JPA entities, and service methods. Use when modernizing AS/400 or IBM i legacy systems, analyzing RPG source files (.rpg, .rpgle, .RPGLE), converting RPG to Java, mapping data specifications to Java classes, planning legacy system migration, or when user mentions RPG analysis, Report Program Generator, RPG III/IV/ILE, AS/400 modernization, IBM i migration, packed decimal conversion, or mainframe application rewrite.
brand-library-architect
IncludedBuild a complete brand library for a product — visual asset render pipeline, brand documentation set (BRAND, COPY, MANIFESTO, BIOS, FAQ, GLOSSARY, TONE, PRICING), open-source convention files (README, CONTRIBUTING, SECURITY, CODE_OF_CONDUCT), and a self-contained press kit. This skill should be used when the user asks to "build a brand library / brand kit / press kit / brand assets" for a product, "set up a brand library workflow," "create a positioning manifesto plus visual identity," or any combination of brand documentation + visual asset pipeline. Apply phase-by-phase or run end-to-end. Templates are product-agnostic and use {{TOKEN}} placeholders the skill prompts the user to fill.
writing-tech-post
IncludedAuthors engineering blog posts end-to-end: launch deep-dives, incident postmortems, architecture migrations, performance case studies, tutorials, AI/agent system writeups, security disclosures, and research-to-product translations. Picks the correct archetype, plans the abstraction ladder, enforces an evidence cadence (diagrams, benchmarks, profiles, traces, code, ablations), tunes voice against publisher house styles (Datadog, Vercel, GitHub, AWS, Meta, Cloudflare, Jane Street), and runs a pre-publish gate for narrative momentum and disclosure ethics. Use when drafting a new engineering post, restructuring a draft that feels flat, deciding which evidence form belongs where, validating that depth and product context are balanced, or preparing a postmortem, migration, or performance narrative for external publication. Do not use for API reference documentation, README authoring, marketing copy, release notes, generic SEO content, ghost-written executive thought leadership, or non-engineering long-form essays.
blog-google
IncludedGoogle API integration for blog performance: PageSpeed Insights, CrUX Core Web Vitals with 25-week history, Search Console performance, URL Inspection, Indexing API, GA4 organic traffic, NLP entity analysis for E-E-A-T, YouTube video search for embedding, and Google Ads Keyword Planner. Progressive feature availability based on credential tier (API key, OAuth/service account, GA4, Ads). Shares config with claude-seo at ~/.config/claude-seo/google-api.json. Use when user says "google data", "page speed", "core web vitals", "search console", "indexation", "GA4", "keyword research", "nlp entities", "blog performance", "youtube search", "google api setup".