Help us improve
Share bugs, ideas, or general feedback.
From strikethroo
Generates atomic Markdown tasks for a Strikethroo plan. Use to decompose a plan ID into individual task files conforming to a template.
npx claudepluginhub e0ipso/strikethrooHow this skill is triggered — by the user, by Claude, or both
Slash command
/strikethroo:st-generate-tasksThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Drive the end-to-end decomposition of an existing Strikethroo plan into
Orchestrates the full Strikethroo workflow: plan creation, task generation, and blueprint execution in a single automated sequence. Use when the user requests the complete end-to-end workflow for a work order.
Generates structured TASKS.json/md files with phased tasks, dependencies, story points, acceptance criteria, and agent prompts from features, PRDs, and SDDs.
Plans tasks or features: loads project context including monorepo checks, clarifies requirements, spawns Plan agent, persists validated plans to .groundwork-plans/.
Share bugs, ideas, or general feedback.
Drive the end-to-end decomposition of an existing Strikethroo plan into
atomic Markdown task files. The skill is assistant-agnostic and self-contained:
every script it invokes lives under this skill's scripts/ directory and is
referenced by relative path.
The user supplies the numeric plan ID conversationally. Treat it as the only authoritative source of intent. Do not invent answers to clarifying questions — prompt the user instead.
Run scripts/find-strikethroo-root.cjs from the user's working directory.
The script walks up looking for .ai/strikethroo/.init-metadata.json and
prints the absolute path of the resolved root on success.
If the script exits non-zero, the working directory is not inside an
initialized strikethroo workspace. Stop and ask the user to run the project
initializer (e.g. npx strikethroo init) before continuing. Do
not attempt to generate tasks outside of a valid root.
For every subsequent step, treat the path printed by this script as <root>.
Run scripts/validate-plan-blueprint.cjs <plan-id> planFile to obtain the
absolute path of the plan file. The same script also accepts these field
names (single-field output mode) and exposes them on demand:
planDir — absolute path of the plan directorytaskCount — number of existing task files in that plan's tasks/blueprintExists — yes or notaskManagerRoot — absolute path of <root>planId — the resolved numeric plan IDIf the script exits non-zero, stop and ask the user to confirm the plan ID. Do not guess a different ID.
Read these files, in order:
<root>/config/STRIKETHROO.md — directory conventions for plans, tasks,
and the archive layout.<root>/config/templates/TASK_TEMPLATE.md — every task file you emit must
conform to this template's frontmatter schema and section structure.Read the entire plan. Identify all concrete deliverables explicitly stated. Decompose each deliverable into atomic tasks only when genuinely needed.
Task minimization (mandatory):
Antipatterns to avoid:
Each task must be:
Skill assignment (kebab-case, automatically inferred from the task's technical requirements):
["css"], ["jest"]).["api-endpoints", "database"],
["react-components", "jest"]).When generating test tasks, keep this constraint:
Definition. Meaningful tests verify custom business logic, critical paths, and edge cases specific to this application. Test your code, not the framework or library.
When TO write tests:
When NOT to write tests:
Test task creation rules:
If any test task is generated, restate this section verbatim or near-verbatim in that task's "Implementation Notes" so the executing agent applies it.
For each task, identify:
A task B depends on A if B requires A's output or artifacts, modifies code created by A, or tests functionality implemented by A. Validate that the final dependency graph is acyclic.
Run scripts/get-next-task-id.cjs <plan-id> to obtain the first available
task ID. Allocate subsequent IDs by incrementing in-process; do not invoke
the script repeatedly. Use the unpadded integer in the task frontmatter id
field and the zero-padded form ({padded-id}--{slug}) for the filename.
The slug derives from a short task title: lowercase, alphanumeric and hyphens only, collapsed, trimmed.
Write each task to:
<root>/plans/<plan-dir-name>/tasks/{padded-id}--{slug}.md
Each file must conform to <root>/config/templates/TASK_TEMPLATE.md,
including required frontmatter fields:
id (integer)group (string)dependencies (array of task IDs, possibly empty)status — pending for new taskscreated (YYYY-MM-DD)skills (array of 1–2 kebab-case skills)Optional frontmatter for high-complexity or decomposed tasks:
complexity_score (number, 1–10, include only if >4 or for decomposed
tasks)complexity_notes (string)The body sections (Objective, Skills Required, Acceptance Criteria, Technical
Requirements, Input Dependencies, Output Artifacts, Implementation Notes)
must be filled with task-specific content. Place detailed implementation
guidance inside a <details> block under "Implementation Notes" — write it
so a non-thinking LLM could execute the task from that section alone.
Before declaring task generation complete, verify:
get-next-task-id.cjs.Read <root>/config/hooks/POST_TASK_GENERATION_ALL.md and follow its
instructions. This typically requires:
<root>/config/templates/BLUEPRINT_TEMPLATE.md for structure.Conclude with exactly this block as the final output:
---
Task Generation Summary:
- Plan ID: [numeric-id]
- Tasks: [count]
- Status: Ready for execution
The summary is consumed by downstream automation; keep the format exact.
status: "needs-clarification" and document the open question in the
task's "Implementation Notes". Do not invent answers.