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.

If 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.

If 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 tasks/prd-*.md

Phase 1

.planning/[project-name]/tasks/prd-.md exists, no tasks/tasks-prd-.md

Phase 2

.planning/[project-name]/tasks/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, tasks/ , 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]/tasks/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/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/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 4 , 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 to 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

[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