e0ipso/strikethroo/st-full-workflow

st-full-workflow

Critical Rule

Execute all three steps sequentially without waiting for user input between them.

Inputs

The user supplies the work order conversationally.

Operating Procedure

Step 1: Plan Creation

1. Locate the strikethroo root

Run scripts/find-strikethroo-root.cjs from the user's working directory. If it exits non-zero, stop and ask the user to run npx strikethroo init.

Treat the path it prints as <root> for every subsequent step.

2. Load project context

Read these files, in order:

• <root>/config/STRIKETHROO.md for this project's directory conventions.
• <root>/config/hooks/PRE_PLAN.md, and execute its instructions before

proceeding.

3. Analyze the work order

Identify:

• Objective.
• Scope and explicit boundaries.
• Success criteria.
• Dependencies, prerequisites, blockers.
• Technical requirements and constraints.
• Blast radius size.

4. Clarification loop

If any critical context is missing, ask the user targeted questions. Keep looping until you have no further questions. Explicitly confirm whether backwards compatibility is required. Never invent answers; never paper over a missing answer.

If the user declines to clarify a blocking question, stop and report the plan as needing clarification. Do not produce a partial plan.

Read <root>/config/shared/anti-rationalization.md and apply it to this rationalization table:

5. Allocate the next plan ID

Run scripts/get-next-plan-id.cjs for the next available plan ID. Compute its zero-padded form for the directory name ({padded-id}--{slug}) and use the unpadded integer in the plan frontmatter.

6. Emit the plan

Read <root>/config/templates/PLAN_TEMPLATE.md. Projects customize this template, so follow it instead of any default plan layout.

Write the plan to <root>/plans/{padded-id}--{slug}/plan-{padded-id}--{slug}.md, conforming to the plan template in both frontmatter and sections. Derive <slug> from the plan summary: lowercase, alphanumeric and hyphens only, no prepositions, no conjunctions, repeated hyphens collapsed, trimmed.

Do not include time estimates, task lists, or code samples.

7. Run post-plan hook

Execute <root>/config/hooks/POST_PLAN.md.

8. Emit the Step 1 structured summary

Conclude Step 1 with exactly this block (an update notice, when present, follows the workflow's final summary):

---
 
Plan Summary:
- Plan ID: [numeric-id]
- Plan File: [absolute-path-to-plan-file]

Parse the Plan ID value from this output and pass it to Step 2.

Step 2: Task Generation

Using the plan ID from Step 1:

1. Resolve the plan

Run scripts/validate-plan-blueprint.cjs <plan-id> planFile for the plan file's absolute path. Another field name prints that field instead.

If the script exits non-zero, surface its stderr to the user and stop the workflow. Do not guess a different ID.

2. Load project context

Read these files, in order:

• <root>/config/STRIKETHROO.md — project and directory conventions.
• The plan body at the path returned by step 1 — the contract for

what tasks must exist.

• <root>/config/templates/TASK_TEMPLATE.md — the schema every task file

must match.

• <root>/config/shared/anti-rationalization.md — apply in step 3.

3. Analyze and decompose the plan

Read the entire plan. Identify all concrete deliverables explicitly stated. Decompose each deliverable into atomic tasks only when genuinely needed.

Task minimization (mandatory):

• Create only the minimum number of tasks necessary. Target a 20–30%

reduction from comprehensive lists by questioning the necessity of each candidate.

• Every task corresponds to an explicit requirement, never a nice-to-have, a

"best practice", or future extensibility the plan does not mention.

• Each task has a unique, non-overlapping purpose.
• Keep error handling inside the task that owns the behavior it guards.

Apply <root>/config/shared/anti-rationalization.md to this rationalization table:

4. Apply granularity and skill rules

Each task must be:

• Single-purpose — one clear deliverable.
• Atomic — cannot be meaningfully split further.
• Skill-specific — executable by an agent with 1–2 technical skills.
• Verifiable — has explicit acceptance criteria that include at least one

concrete, runnable verification step (a command plus its expected output, or another observable signal). Never settle for a vague "works correctly".

Infer skills in kebab-case from the task's technical requirements. Use one skill for a single-domain task and two for complementary domains, such as ["api-endpoints", "database"]. Three or more means the task must be broken down further.

5. Test philosophy: "write a few tests, mostly integration"

Write tests for:

• Custom business logic and algorithms.
• Critical user workflows and data transformations.
• Edge cases and error conditions in core functionality.
• Integration points between components.
• Complex validation or calculation logic.

Do not write tests for:

• Third-party library and framework functionality.
• Simple CRUD without custom logic.
• Trivial getters/setters and static configuration.
• Obvious functionality that would break immediately if incorrect.

Combine related test scenarios into one task ("Test user authentication flow", not separate tasks for login, logout, and validation). Favor integration and critical-path coverage over per-method unit tests. Never create one test task per CRUD operation.

Copy these rules into the "Implementation Notes" of every test task you generate.

6. Dependency analysis

Task B depends on task A when B requires A's output or artifacts, modifies code created by A, or tests functionality implemented by A. Record it as a hard dependency when B cannot start before A completes and as a soft dependency when B merely runs better after A. Validate that the final dependency graph is acyclic.

7. Complexity analysis

For every candidate task, assign a complexity_score (integer 1–10) before writing any file. Read references/complexity-rubric.md before scoring; it defines the four dimensions each band is judged on. Then apply these rules:

• Score ≥ 8 → decompose further; do not emit as-is.
• Score 6–7 → sharpen or split; do not emit without an explicit reason.
• Vague acceptance criteria → sharpen them into a concrete, runnable

verification step.

• Trivially small adjacent tasks → merge them.

Loop-back rule: after applying split, sharpen, or merge, re-run dependency analysis and re-score the adjusted tasks. Repeat no more than three times. If complexity is still unresolved after three passes, stop and surface the blocker to the user.

8. Allocate task IDs

Run scripts/get-next-task-id.cjs <plan-id> once for the first available task ID, then allocate the rest by incrementing in-process. Use the unpadded integer in the task frontmatter id field and the zero-padded form in the filename. The slug derives from a short task title: lowercase, alphanumeric and hyphens only, collapsed, trimmed.

9. Emit the task files

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. Add complexity_notes only when the score needs justification. Never write execution_profile; the routing helper writes it.

Fill every body section with task-specific content. Place detailed implementation guidance inside a <details> block under "Implementation Notes", written so a non-thinking LLM could execute the task from that section alone.

10. Validation checklist

Before declaring task generation complete, verify:

• Every explicitly stated deliverable in the plan is covered by a task.
• No two tasks overlap in purpose.
• Dependencies form an acyclic graph, with no orphan or circular references.
• Groups are consistent across the plan.
• After writing the task files, run

scripts/validate-plan-blueprint.cjs <plan-id> complexityScoresValid. Stop unless it prints yes; if it prints no, run scripts/validate-plan-blueprint.cjs <plan-id> invalidComplexityTasks to see which files are missing, non-integer, or out-of-range, fix them, and re-run.

11. Route task execution

Read <root>/config/hooks/TASK_EXECUTION_ROUTING.md and follow its instructions together with this procedure:

1. Run scripts/route-task-execution.cjs profiles <plan-id>. On no-config

or disabled, routing is off; skip the remaining routing steps and continue. On invalid-config, stop and surface the errors to the user; do not generate the blueprint.

1. Assign every task in the plan's tasks/ directory exactly one configured

profile name. Classify the tasks generated in this run from the content already in your context. If the plan carried task files from an earlier generation run, read those files to classify them.

1. Write the complete task-ID-to-profile mapping as a JSON object to a

temporary file, for example {"1": "routine", "2": "demanding"}.

1. Run scripts/route-task-execution.cjs apply <plan-id> <mapping-file>.

Target selection happens later at task dispatch, never during generation.

1. On routed, delete the temporary mapping file and continue. On any failure

result (invalid-assignments, invalid-tasks, routing-failure, infrastructure-failure), stop and surface the JSON errors to the user. Never continue to blueprint generation with partially routed tasks.

Never hand-write a concrete execution target into task frontmatter or task bodies.

12. Run the POST_TASK_GENERATION_ALL hook

Read <root>/config/hooks/POST_TASK_GENERATION_ALL.md and follow its instructions, using <root>/config/templates/BLUEPRINT_TEMPLATE.md for the Execution Blueprint structure. Run the hook only after routing succeeded or reported routing off.

Step 3: Blueprint Execution

Using the plan ID from Step 1:

1. Validate the plan and the tasks

1. Run scripts/validate-plan-blueprint.cjs <plan-id> planFile for the plan

file's absolute path. If the script exits non-zero, surface its stderr to the user and stop the workflow.

1. Run scripts/validate-plan-blueprint.cjs <plan-id> planDir and treat the

printed path as <plan-dir>.

1. Run scripts/validate-plan-blueprint.cjs <plan-id> taskCount and

scripts/validate-plan-blueprint.cjs <plan-id> blueprintExists.

2. Auto-generate tasks and blueprint if missing

If taskCount is 0 or blueprintExists is no:

Notify the user: "⚠️ Tasks or execution blueprint not found. Generating tasks automatically..."

• Execute the full task generation procedure from Step 2 for this plan ID.
• Re-run the planFile, planDir, taskCount, and blueprintExists queries to refresh the resolved paths and counts.