gsdl
Original:🇺🇸 English
Translated
Get Shit Done (GSD) orchestrator. Runs the full project pipeline from idea to implementation to documentation: setup → PRD → task list → implementation → decisions doc. Use when the user wants to build something end-to-end, says "let's GSD", "build this from scratch", "get shit done", or wants to run the full development workflow. Coordinates gsdl-setup-project, gsdl-create-prd, gsdl-create-plan, gsdl-execute-plan, and gsdl-document-decisions skills. Spawns subagents per parent task during implementation to preserve context. Accepts an optional project name or source URL: /gsdl [project-name] OR /gsdl [linear|notion|slite] [url] OR /gsdl [url].
3installs
Sourcensantini/gsdl
Added on
NPX Install
npx skill4agent add nsantini/gsdl gsdlTags
Translated version includes tags in frontmatterSKILL.md Content
View Translation Comparison →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/...- (source auto-detected from URL)
/gsdl https://linear.app/... /gsdl https://notion.so/.../gsdl https://notion.site/.../gsdl https://slite.com/...
If a URL is detected:
- Read and follow the skill (resolve path per the Skill Path Resolution section below).
gsdl-fetch-source - 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 as the project name — does that work, or would you like a different name?"
[suggested-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 during Phase 0 setup (overriding the normal "describe your idea" prompt).
seed.md
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 , the project name is
/gsdl my-project. Use it directly — do not ask.my-project - 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 if it exists — this is the fastest way to resume.
.planning/[project-name]/progress.mdIf exists, extract:
progress.md- — last recorded phase (0–4 or "done")
phase - — path to the active PRD file
prd - — path to the active task file
tasks
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 does not exist (or a recorded file is missing), scan the filesystem:
progress.md| Condition | Start at |
|---|---|
No | Phase 0 |
| Phase 1 |
| Phase 2 |
| Phase 3 |
All tasks | Phase 4 |
| Done |
If multiple PRD or task files exist, use the path recorded in (if available); otherwise ask the user which one to use.
progress.mdAfter determining the active phase and files, write (or update) — see the Progress File section below.
progress.mdAnnounce 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:
- — installed via npx (preferred)
~/.agents/skills/[skill-name]/SKILL.md - — legacy/manual install
~/.cursor/skills/[skill-name]/SKILL.md
Use whichever path exists. If both exist, prefer .
~/.agents/skills/Sub-skills used by this orchestrator:
- — fetches content from Linear, Notion, or Slite (Step 0)
gsdl-fetch-source - — creates folder structure and seed.md (Phase 0)
gsdl-setup-project - — generates the PRD (Phase 1)
gsdl-create-prd - — generates the task list (Phase 2)
gsdl-create-plan - — implements sub-tasks (Phase 3)
gsdl-execute-plan - — captures decisions & architecture changes, optionally publishes to Slite or Notion (Phase 4)
gsdl-document-decisions
Phase 0 — Project Setup (Inline)
Read and follow the skill (resolve path per above).
gsdl-setup-projectComplete the full setup (folder, ):
seed.md- If seed content was pre-fetched in Step 0: Write the fetched seed content directly to instead of asking the user to describe their idea. Show the user what was written and let them know they can edit
seed.mdbefore continuing.seed.md - If no pre-fetched content: Follow the normal flow (prompt the user to describe their idea, populate
gsdl-setup-projectcollaboratively).seed.md
Then write the initial (phase 0), show the checkpoint, and wait for user confirmation before continuing to Phase 1.
progress.mdPhase 1 — Create PRD (Inline)
Read and follow the skill (resolve path per above).
gsdl-create-prdThis phase is interactive — ask clarifying questions, iterate on the PRD with the user, then save it to .
.planning/[project-name]/prd-[feature-name].mdAfter saving the PRD, update (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.
progress.mdPhase 2 — Generate Task List (Inline)
Read and follow the skill (resolve path per above).
gsdl-create-planThis has two steps: show parent tasks → wait for user "Go" → generate sub-tasks and save to .
.planning/[project-name]/tasks-prd-[name].mdAfter saving the task file, update (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.
progress.mdPhase 3 — Implementation (Subagent per Parent Task)
Update to phase 3 before starting.
progress.mdRe-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 subagent using the Task tool with this prompt (fill in all
generalPurpose):[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 to phase , then run this phase.
progress.md4Read and follow the skill (resolve path per above).
gsdl-document-decisionsPass the following context to the skill:
- : the current project name
PROJECT_NAME - : the absolute path to the workspace root
WORKSPACE_ROOT - : the PRD path recorded in
PRD_PATHprogress.md - : the tasks path recorded in
TASKS_PATHprogress.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 to , then show the final checkpoint:
progress.mddone🎉 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 throughout the pipeline. Write it after every phase transition and whenever the active files are first determined.
.planning/[project-name]/progress.mdFormat
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) | | | |
| PRD saved (Phase 1 complete) | | path to PRD | |
| Task file saved (Phase 2 complete) | | path to PRD | path to tasks |
| All tasks complete (Phase 3 done) | | path to PRD | path to tasks |
| Decisions document saved (Phase 4 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 (if present) → verify files on disk → fall back to filesystem scan if needed
progress.md - Skip completed phases
- Announce: "Project '[name]' is at Phase [N]. Resuming from [description]."
- For Phase 3, check which parent tasks are already and skip them
[x] - For Phase 4, if already exists, report the project is done — do not re-run Phase 4
decisions-[project-name].md
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 current — update it at every phase transition so
progress.mdalways resumes cleanly/gsdl [project-name] - 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