GSD — Get Shit Done Orchestrator

Coordinates the full project pipeline across five phases. Phases 0–2 and Phase 4 run inline (interactive, in this context). Phase 3 (implementation) spawns one subagent per parent task to keep context fresh.

Pipeline Overview

Phase 0: Setup       → gsdl-setup-project SKILL.md        (inline)
Phase 1: PRD         → gsdl-create-prd SKILL.md           (inline, interactive Q&A)
Phase 2: Task List   → gsdl-create-plan SKILL.md          (inline, two-phase with "Go")
Phase 3: Implement   → gsdl-execute-plan SKILL.md         (subagent per parent task)
Phase 4: Document    → gsdl-document-decisions SKILL.md   (inline, optional publish to Slite/Notion)

Step 0: Detect Source URL (Pre-flight)

Before resolving the project name, check if the user's message contains a URL argument.

Recognized patterns:

```
/gsdl linear https://linear.app/...
```
```
/gsdl notion https://notion.so/...
```
```
/gsdl slite https://slite.com/...
```
```
/gsdl https://linear.app/...
```
(source auto-detected from URL)
```
/gsdl https://notion.so/...
```
```
/gsdl https://notion.site/...
```
```
/gsdl https://slite.com/...
```

If a URL is detected:

Read and follow the
```
gsdl-fetch-source
```
skill (resolve path per the Skill Path Resolution section below).
Pass the URL and optional source-type hint to the skill.
The skill returns:
- A suggested project name (kebab-case, derived from the fetched title)
- Seed content (pre-formatted Markdown for
```
seed.md
```
  )
- A source summary (one-line description of what was fetched)
Present the suggested project name to the user and confirm: "I fetched the content from [source summary]. I'll use
[suggested-name]
as the project name — does that work, or would you like a different name?"
Once confirmed (or adjusted), store both the project name and seed content in context.
Proceed to Step 2: Detect Current Phase — the seed content will be written to
```
seed.md
```
during Phase 0 setup (overriding the normal "describe your idea" prompt).

If no URL is detected, skip this step entirely and proceed to Step 1.

Step 1: Resolve Project Name

Check the user's message for a project name argument. If the user typed
```
/gsdl my-project
```
, the project name is
```
my-project
```
. Use it directly — do not ask.
If a source URL was provided in Step 0, the project name was already resolved there — use it.
If no project name was provided and no URL was given, ask: "What's the project name?"
Normalize to kebab-case.

Step 2: Detect Current Phase

Read

.planning/[project-name]/progress.md

if it exists — this is the fastest way to resume.

progress.md

exists, extract:

```
phase
```
— last recorded phase (0–4 or "done")
```
prd
```
— path to the active PRD file
```
tasks
```
— path to the active task file

Then verify the recorded files still exist on disk before trusting them. If a file is missing, fall back to the filesystem scan below.

progress.md

does not exist (or a recorded file is missing), scan the filesystem:

Condition	Start at
No `.planning/[project-name]/` folder	Phase 0
`.planning/[project-name]/seed.md` exists, no `prd-*.md`	Phase 1
`.planning/[project-name]/prd-.md` exists, no `tasks-prd-.md`	Phase 2
`.planning/[project-name]/tasks-prd-*.md` exists with unchecked `[ ]` items	Phase 3
All tasks `[x]` , no `decisions-*.md` file	Phase 4
`decisions-[project-name].md` exists	Done

If multiple PRD or task files exist, use the path recorded in

progress.md

(if available); otherwise ask the user which one to use.

After determining the active phase and files, write (or update)
progress.md
— see the Progress File section below.

Announce which phase you're starting from and why before proceeding.

Step 3: Run Each Phase

Skill Path Resolution

When reading a sub-skill, resolve its path using this priority order:

```
~/.agents/skills/[skill-name]/SKILL.md
```
— installed via npx (preferred)
```
~/.cursor/skills/[skill-name]/SKILL.md
```
— legacy/manual install

Use whichever path exists. If both exist, prefer

~/.agents/skills/

Sub-skills used by this orchestrator:

```
gsdl-fetch-source
```
— fetches content from Linear, Notion, or Slite (Step 0)
```
gsdl-setup-project
```
— creates folder structure and seed.md (Phase 0)
```
gsdl-create-prd
```
— generates the PRD (Phase 1)
```
gsdl-create-plan
```
— generates the task list (Phase 2)
```
gsdl-execute-plan
```
— implements sub-tasks (Phase 3)
```
gsdl-document-decisions
```
— captures decisions & architecture changes, optionally publishes to Slite or Notion (Phase 4)

Phase 0 — Project Setup (Inline)

Read and follow the

gsdl-setup-project

skill (resolve path per above).

Complete the full setup (folder,

seed.md

If seed content was pre-fetched in Step 0: Write the fetched seed content directly to
```
seed.md
```
instead of asking the user to describe their idea. Show the user what was written and let them know they can edit
```
seed.md
```
before continuing.
If no pre-fetched content: Follow the normal
```
gsdl-setup-project
```
flow (prompt the user to describe their idea, populate
```
seed.md
```
collaboratively).

Then write the initial

progress.md

(phase 0), show the checkpoint, and wait for user confirmation before continuing to Phase 1.

Phase 1 — Create PRD (Inline)

Read and follow the

gsdl-create-prd

skill (resolve path per above).

This phase is interactive — ask clarifying questions, iterate on the PRD with the user, then save it to

.planning/[project-name]/prd-[feature-name].md

After saving the PRD, update

progress.md

(phase 1, prd path). Show the checkpoint and wait for confirmation before Phase 2. Before proceeding to Phase 2, re-read the PRD from disk at its saved path — the user may have edited the file after reviewing it.

Phase 2 — Generate Task List (Inline)

Read and follow the

gsdl-create-plan

skill (resolve path per above).

This has two steps: show parent tasks → wait for user "Go" → generate sub-tasks and save to

.planning/[project-name]/tasks-prd-[name].md

After saving the task file, update

progress.md

(phase 2, tasks path). Show the checkpoint and wait for confirmation before Phase 3. Before proceeding to Phase 3, re-read the task file from disk at its saved path — the user may have edited the file (reordering, rewording, or adding tasks) after reviewing it.

Phase 3 — Implementation (Subagent per Parent Task)

Update

progress.md

to phase 3 before starting.

Re-read the task file from disk to identify all parent tasks (1.0, 2.0, 3.0, ...). Use the on-disk version as the source of truth, not any prior in-context copy.

For each parent task, in order:

Read the task file to get the parent task title and its sub-tasks
Spawn a
```
generalPurpose
```
subagent using the Task tool with this prompt (fill in all
```
[placeholders]
```
):

Read and follow the skill at: ~/.agents/skills/gsdl-execute-plan/SKILL.md (if it exists, otherwise ~/.cursor/skills/gsdl-execute-plan/SKILL.md)

You are running in BATCH MODE. Complete ALL sub-tasks under the assigned parent task
without pausing for user approval between sub-tasks. Apply the full completion protocol
after each sub-task (mark [x], update task file, update Relevant Files), but immediately
continue to the next sub-task without waiting.

Project context:
- Project name: [project-name]
- Workspace root: [absolute path to workspace root]
- Task file: [absolute path to .planning/[project-name]/tasks-prd-*.md]
- Assigned parent task: [N.0] [Parent Task Title]
- Sub-tasks to complete: [N.1] [title], [N.2] [title], ... (list all)

When all sub-tasks under [N.0] are marked [x] and the parent is marked [x]:
- Return a summary: what was built, files created/modified, any issues or blockers
- Do NOT start the next parent task ([N+1].0)

After the subagent returns, show the user the summary
Show the checkpoint and wait for confirmation before spawning the next subagent

Phase 4 — Document Decisions (Inline)

After all parent tasks are complete, update

progress.md

to phase

, then run this phase.

Read and follow the

gsdl-document-decisions

skill (resolve path per above).

Pass the following context to the skill:

```
PROJECT_NAME
```
: the current project name
```
WORKSPACE_ROOT
```
: the absolute path to the workspace root
```
PRD_PATH
```
: the PRD path recorded in
```
progress.md
```
```
TASKS_PATH
```
: the tasks path recorded in
```
progress.md
```

The skill will:

Analyze git history and the PRD/task files

Generate a structured decisions document at

.planning/[project-name]/decisions-[project-name].md

Ask the user if they want to publish it to Slite or Notion
Handle publishing if the user provides a parent page URL

This phase runs inline (no subagent). After the decisions document is saved and the user has answered the publish prompt, update

progress.md

done

, then show the final checkpoint:

🎉 Project '[project-name]' is complete.

Decisions document: .planning/[project-name]/decisions-[project-name].md
[If published: Published to [Slite/Notion]: [URL]]

Run /gsdl [project-name] again if you want to resume or extend this project.

Progress File

Maintain

.planning/[project-name]/progress.md

throughout the pipeline. Write it after every phase transition and whenever the active files are first determined.

Format

markdown

# [project-name] — GSDL Progress

## State

- Phase: [0 | 1 | 2 | 3 | 4 | done]
- Last Updated: [YYYY-MM-DD]

## Active Files

- PRD: [relative path to active prd-*.md, or "none"]
- Tasks: [relative path to active tasks-prd-*.md, or "none"]

When to write/update

Event	Phase value	PRD	Tasks
Phase 0 complete (setup done)	`1`	`none`	`none`
PRD saved (Phase 1 complete)	`2`	path to PRD	`none`
Task file saved (Phase 2 complete)	`3`	path to PRD	path to tasks
All tasks complete (Phase 3 done)	`4`	path to PRD	path to tasks
Decisions document saved (Phase 4 done)	`done`	path to PRD	path to tasks

Checkpoint Format

Show this between every phase transition and between every parent task in Phase 3:

✅ [Phase name / Task N.0 title] complete.

What was done: [1–3 sentence summary]
Files touched: [key files created or modified]

👉 Review the output file before continuing — you can edit it directly and your changes will be picked up automatically.

Ready to continue to [next phase / Task N+1.0]?
Type "yes" / "go" / "next" to continue, or tell me what to review or change first.

Never proceed past a checkpoint without user confirmation. Always re-read the relevant artifact from disk after the user confirms, to pick up any edits they made during the review window.

Resuming Mid-Pipeline

If GSD is triggered on a project that already has work done:

Read
```
progress.md
```
(if present) → verify files on disk → fall back to filesystem scan if needed
Skip completed phases
Announce: "Project '[name]' is at Phase [N]. Resuming from [description]."
For Phase 3, check which parent tasks are already
```
[x]
```
and skip them
For Phase 4, if
```
decisions-[project-name].md
```
already exists, report the project is done — do not re-run Phase 4

Rules

Always show a checkpoint between phases and between parent tasks — never chain them automatically
Phases 0–2 and Phase 4 are inline — do not spawn subagents for setup, PRD, task generation, or documentation
Each Phase 3 subagent handles exactly one parent task — never assign two parent tasks to one subagent
Surface blockers immediately — if a subagent reports an error or missing dependency, pause Phase 3 and resolve with the user before continuing
All files stay within the project folder — never create files at workspace root
Keep
progress.md
current — update it at every phase transition so
```
/gsdl [project-name]
```
always resumes cleanly
Phase 4 is mandatory but publishing is optional — always generate the decisions document; only push to Slite/Notion if the user provides a parent URL

gsdl

NPX Install

Tags

SKILL.md Content

GSD — Get Shit Done Orchestrator

Pipeline Overview

Step 0: Detect Source URL (Pre-flight)

Step 1: Resolve Project Name

Step 2: Detect Current Phase

Step 3: Run Each Phase

Skill Path Resolution

Phase 0 — Project Setup (Inline)

Phase 1 — Create PRD (Inline)

Phase 2 — Generate Task List (Inline)

Phase 3 — Implementation (Subagent per Parent Task)

Phase 4 — Document Decisions (Inline)

Progress File

Format

When to write/update

Checkpoint Format

Resuming Mid-Pipeline

Rules