Project Task Orchestrator

Cascade

by Parcha-ai · MIT license · ★ 62 on GitHub

Carry large projects through verifiable tasks, parallel work, and durable progress. Use when asked for Cascade, work in loops, or sustained project execution.

---
name: cascade
description: Carry large projects through verifiable tasks, parallel work, and durable progress. Use when asked for Cascade, work in loops, or sustained project execution. Skip small edits.
---

# Cascade

Keep one living plan in `.cascade/<project>.md` or the existing project plan:

- Outcome and final acceptance check.
- Context needed to resume: workspace, constraints, decisions, source links.
- Tasks: ID, deliverable, dependencies, exit check, status, evidence.
- Current owners, blockers, and next actions.

**Decompose.** Split by verifiable outcomes or subsystems; detail only near-term work. Expand large
tasks into children while retaining the parent's acceptance check. Convert chains into dependency
graphs by keeping actual prerequisites and removing ordering that serves no dependency.

Overview

Keep one living plan in .cascade/<project>.md or the existing project plan:

Manual install (npx, ZIP)

Claude Codenpx skills add Parcha-ai/parcha-skills --skill cascade -g -a claude-code

Claude Code (degit)npx degit Parcha-ai/parcha-skills/cascade/skills/cascade#main ~/.claude/skills/cascade

Claude.ai / desktopZip the folder and upload it under Settings → Capabilities → Skills.

Codex, Cursor, other agentsPoint them at SKILL.md. The other files are plain text.

Connects with Agent Alley MCP · agentalley.io/mcp

Files included

SKILL.md2.1 KB

Read SKILL.md here

Parcha-ai/main1 file shown

SKILL.md2.1 KB

Browse every file on GitHub↗

SKILL.md

Show the full text37 lines

cascade/SKILL.md37 lines · 2.1 KB

PreviewCodeRawView on GitHub

Cascade

Keep one living plan in .cascade/<project>.md or the existing project plan:

Outcome and final acceptance check.
Context needed to resume: workspace, constraints, decisions, source links.
Tasks: ID, deliverable, dependencies, exit check, status, evidence.
Current owners, blockers, and next actions.

Decompose. Split by verifiable outcomes or subsystems; detail only near-term work. Expand large tasks into children while retaining the parent's acceptance check. Convert chains into dependency graphs by keeping actual prerequisites and removing ordering that serves no dependency.

Execute. Pick tasks whose prerequisites passed. Build, verify, update the plan, repeat while authorized work remains. Use todo, doing, done, blocked. Failed checks remain unfinished; change approach when attempts stop producing information. Respect session limits and continue independent work when a task is blocked.

Parallelize. Use available subagents for independent ready tasks. Give each worker context, owned files or worktree, deliverable, and exit check. Serialize overlapping edits. Workers return changes, evidence, and unresolved issues; the lead owns integration and the plan. Mirror the graph into native tasks when useful; otherwise the file suffices.

Verify. Mark done only when the exit check passes on the actual candidate. Record check, result, and revision or working-tree identity. Test relevant failure cases; establish a baseline for measured improvements. Never weaken acceptance to hide failure. Verify the assembled system against the original outcome after its required tasks pass.

Resume. Save progress at meaningful boundaries and before handoff. Compare the plan with actual files and workers; recheck stale evidence. Continue until the overall acceptance passes or no authorized work can advance. Leave concrete blockers and next actions when stopping.

1	---
2	name: cascade
3	description: Carry large projects through verifiable tasks, parallel work, and durable progress. Use when asked for Cascade, work in loops, or sustained project execution. Skip small edits.
4	---
5
6	# Cascade
7
8	Keep one living plan in `.cascade/<project>.md` or the existing project plan:
9
10	- Outcome and final acceptance check.
11	- Context needed to resume: workspace, constraints, decisions, source links.
12	- Tasks: ID, deliverable, dependencies, exit check, status, evidence.
13	- Current owners, blockers, and next actions.
14
15	Decompose. Split by verifiable outcomes or subsystems; detail only near-term work. Expand large
16	tasks into children while retaining the parent's acceptance check. Convert chains into dependency
17	graphs by keeping actual prerequisites and removing ordering that serves no dependency.
18
19	Execute. Pick tasks whose prerequisites passed. Build, verify, update the plan, repeat while
20	authorized work remains. Use `todo`, `doing`, `done`, `blocked`. Failed checks remain unfinished;
21	change approach when attempts stop producing information. Respect session limits and continue
22	independent work when a task is blocked.
23
24	Parallelize. Use available subagents for independent ready tasks. Give each worker context,
25	owned files or worktree, deliverable, and exit check. Serialize overlapping edits. Workers return
26	changes, evidence, and unresolved issues; the lead owns integration and the plan. Mirror the graph
27	into native tasks when useful; otherwise the file suffices.
28
29	Verify. Mark done only when the exit check passes on the actual candidate. Record check, result,
30	and revision or working-tree identity. Test relevant failure cases; establish a baseline for measured
31	improvements. Never weaken acceptance to hide failure. Verify the assembled system against the
32	original outcome after its required tasks pass.
33
34	Resume. Save progress at meaningful boundaries and before handoff. Compare the plan with actual
35	files and workers; recheck stale evidence. Continue until the overall acceptance passes or no
36	authorized work can advance. Leave concrete blockers and next actions when stopping.
37