Plan Task
Turn a vague task file into testable acceptance criteria and complete scope using a scratchpad-first business analysis workflow.
Overview
Plan-task is an agent skill most often used in Validate (also Build pm) that refines task descriptions and writes comprehensive, testable acceptance criteria via a scratchpad-first business analysis process.
Install
npx skills add https://github.com/neolabhq/context-engineering-kit --skill plan-taskWhat is this skill?
- Scratchpad-first mandate: create .specs/scratchpad via create-scratchpad.sh before any analysis
- Four analysis phases: requirements discovery, concept extraction, requirements analysis, draft consolidation
- Explicit quality bar: no vague, untestable, or incomplete specifications
- Acceptance criteria oriented so developers know what to build and how success is measured
- Selective promotion from scratchpad into the task file after verification
- 4 staged business analysis phases in the documented process
- Mandatory scratchpad creation via create-scratchpad.sh before analysis
Adoption & trust: 542 installs on skills.sh; 1.1k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your task markdown sounds plausible but lacks testable acceptance criteria and clear scope, so implementation keeps reopening the same ambiguities.
Who is it for?
Indie builders using .specs task files who want agent-assisted BA before touching code.
Skip if: Throwaway spikes with no written task artifact or teams that already lock specs in a separate PM tool without markdown tasks.
When should I use this skill?
When a task file path is provided and requirements need refinement, concept extraction, and testable acceptance criteria before development.
What do I get? / Deliverables
The task file gains verified requirements and measurable acceptance criteria promoted from a completed scratchpad analysis, ready for implementation planning or coding.
- Updated task markdown with acceptance criteria
- Business analysis scratchpad under .specs/scratchpad/
- Verified scope promoted from scratchpad to task file
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Validate + scope is the first hard gate where ideas become bounded, measurable work—matching the skill’s goal to refine descriptions before developers implement. Scope subphase covers requirement discovery, concept extraction, and acceptance criteria—the staged business analysis process in the README.
Where it fits
Expand a one-line feature idea into bounded requirements and measurable acceptance tests before prototype work.
Harden an existing task-{name}.md so an implementation agent can execute without clarifying questions.
Reconcile shipped behavior against acceptance criteria drafted during plan-task for release sign-off.
How it compares
Structured requirements workflow with scratchpad gate—not a freestyle brainstorming or coding skill.
Common Questions / FAQ
Who is plan-task for?
Solo developers and small teams using the context-engineering-kit task files who need analyst-grade scope and acceptance criteria before build work starts.
When should I use plan-task?
In Validate when scoping a feature from a thin idea; in Build pm when a task file exists but criteria are weak; whenever vague requirements would block a developer or agent implementer.
Is plan-task safe to install?
It runs a bundled bash scratchpad script and writes under .specs—review the Security Audits panel on this Prism page and inspect scripts in your checkout.
SKILL.md
READMESKILL.md - Plan Task
# Analyse Business Requirements ## Goal Your goal is to refine the task description and create comprehensive acceptance criteria that enable developers to understand exactly what needs to be built and how success will be measured. Use a **scratchpad-first approach**: gather ALL analysis in a scratchpad file, then selectively copy only verified, relevant findings into the task file. **CRITICAL**: Vague requirements cause implementation failures. Untestable criteria waste developer time. Incomplete scope leads to endless rework. YOU are responsible for specification quality. There are NO EXCUSES for delivering incomplete, vague, or untestable requirements. ## Input - **Task File**: Path to the task file (e.g., `.specs/tasks/task-{name}.md`) ## Business Analysis Process ### STAGE 1: Setup Scratchpad **MANDATORY**: Before ANY analysis, create a scratchpad file for your business analysis thinking. 1. Run the scratchpad creation script `bash ${CLAUDE_PLUGIN_ROOT}/scripts/create-scratchpad.sh` - it will create the file: `.specs/scratchpad/<hex-id>.md` 2. Use this file for ALL your discoveries, analysis, and draft sections 3. The scratchpad is your workspace - dump EVERYTHING there first ```markdown # Business Analysis Scratchpad: [Task Title] Task: [task file path] Created: [date] --- ## Phase 1: Requirements Discovery [Stage 2 content...] ## Phase 2: Concept Extraction [Stage 3 findings...] ## Phase 3: Requirements Analysis [Stage 4 analysis...] ## Phase 4: Draft Output [Stage 5 synthesis...] ## Self-Critique [Stage 7 verification...] ``` --- ### STAGE 2: Requirements Discovery YOU MUST elicit the true business need behind the request. Probe beyond surface-level descriptions to uncover underlying problems, stakeholder motivations, and success criteria. NEVER accept the first description at face value. #### Template for Your Analysis Use this template to write in scratchpad file: ```markdown ## Phase 1: Requirements Discovery ### Task Overview - Initial User Prompt: [quote from task file] - Current Description: [existing description if any] - Task Type: [task/bug/feature] - Complexity: [S/M/L/XL] ### Problem Definition (Step-by-Step Analysis) Let's think step by step about what the user actually needs... Step 1: What is the surface-level user request? [Your analysis] Step 2: What is the user actually trying to accomplish? [Your analysis] Step 3: What is the business value? [Your analysis] Step 4: Who benefits from this change and how? [Your analysis] Step 5: What features of this solution may be added imidiatly or in future? [Your analysis] Step 6: What constraints or considerations exist? [Your analysis] Therefore, the root problem is: [Your conclusion] ### Scope - What is included in this task? - What is explicitly NOT included? - What are the boundaries? ### Ambiguous Areas - [List unclear aspects that need resolution] ``` If input is empty: Stop and report ERROR: "No task description provided" #### Examples of Problem Definition Step-by-Step Analysis Example 1: E-commerce Feature Request: **User Request**: "Add a wishlist feature to the product pages" Let's think step by step about what the user actually needs... Step 1: What is the surface-level request? The user wants a wishlist feature on product pages. This seems straightforward - a button to save products for later. Step 2: Why would users need a wishlist? Users browse products but aren't ready to buy immediately. They might be: comparing options, waiting for a sale, saving gift ideas, or budgeting for future purchases. The wishlist solves the problem of "I found something I like but can't act on it now." In simular way user may also want to save products for comparison with other products. Additionally, user may want to have multiple wishlists for different purposes: future purchases, gifts, etc. Step 3: What is the business value? It not directly allow to increase conversion rate, but it allows to increase customer engagement