GSDL — Get Shit Done Light

A collection of Cursor Agent Skills that guide you through a full project development pipeline, from raw idea to working implementation.

Overview

GSDL provides five skills that can be used individually or chained together as a complete end-to-end workflow:

Setup Project → Create PRD → Create Plan → Execute Plan → Document Decisions

An orchestrator skill (gsdl) coordinates all five phases automatically, with human checkpoints between each step.

---

Skills

gsdl — Full Pipeline Orchestrator

Runs the entire workflow end-to-end. Detects which phase a project is at and resumes from there. Phases 0–2 and Phase 4 run inline (interactively in the current context). Phase 3 spawns one subagent per parent task to keep context fresh.

Trigger phrases: "let's GSD", "build this from scratch", "get shit done", or "run the full workflow"

Pass a project name directly to resume instantly:

/gsdl my-project — picks up where you left off, no questions asked

Start from a Linear ticket, Notion doc, or Slite doc:

/gsdl linear https://linear.app/team/issue/ISSUE-123/issue-title /gsdl notion https://www.notion.so/workspace/Page-Title-abc123 /gsdl slite https://yourteam.slite.com/p/NOTE_ID/Doc-Title /gsdl https://linear.app/... — source is auto-detected from the URL

When a URL is provided, the orchestrator fetches the ticket or document content, pre-populates seed.md automatically, and proceeds into the pipeline — no manual idea description required.

Pipeline:

Phase 0: Setup       → creates project folder and seed file
Phase 1: PRD         → interactive Q&A to produce a requirements doc
Phase 2: Task List   → generates parent tasks → waits for "Go" → generates sub-tasks
Phase 3: Implement   → one subagent per parent task, with checkpoint between each
Phase 4: Document    → captures decisions & architecture changes, optionally publishes to Slite/Notion

A checkpoint is shown between every phase and between every parent task during implementation. The pipeline never auto-advances past a checkpoint without your confirmation.

At each checkpoint, you can edit the artifact directly (the PRD, task list, etc.) before confirming. The next phase always re-reads from disk, so your edits are automatically picked up.

Progress tracking: A progress.md file is maintained at .planning/[project-name]/progress.md. It records the current phase and the paths to the active PRD and task files. This lets the orchestrator resume exactly where it left off even after a session restart, context limit, or crash — just call /gsdl [project-name] again.

---

gsdl-fetch-source — Fetch from Linear / Notion / Slite

Fetches project context from a remote source URL and formats it as seed.md content for the GSDL pipeline. Called automatically by the gsdl orchestrator when a URL argument is detected.

Supported sources:

• Linear — fetches issue title, description, status, priority, labels, and assignee via the Linear GraphQL API
• Notion — fetches page title and content blocks via the Notion API
• Slite — fetches note title and content via the Slite API

Authentication — priority order:

1. MCP server (preferred) — if a matching MCP server is configured in .cursor/mcp.json or ~/.cursor/mcp.json, its tools are used automatically with no additional setup:

   Source	MCP server package
   Linear	@linear/mcp
   Notion	@notionhq/notion-mcp-server
   Slite	Check Slite docs

2. Environment variable — fallback if no MCP is configured:

   Source	Variable	Where to generate
   Linear	LINEAR_API_KEY	linear.app/settings/api
   Notion	NOTION_TOKEN	notion.so/my-integrations
   Slite	SLITE_API_KEY	Slite workspace settings → API

3. WebFetch — works for publicly shared content, no credentials needed

4. Manual — paste the content directly into the chat

---

gsdl-setup-project — Project Setup

Creates a standardized folder structure for a new project.

Trigger phrases: "start a new project", "set up a project", "initialize a new idea"

Creates:

.planning/
└── project-name/
    └── seed.md        ← initial idea capture

The seed.md file is intentionally informal — it captures your raw thinking (problem, rough feature ideas, questions, references) before anything gets formalized.

---

gsdl-create-prd — Create PRD

Generates a structured Product Requirements Document from your seed file or a verbal description. Asks clarifying questions before writing anything.

Trigger phrases: "create a PRD", "document requirements", "turn this idea into a spec"

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

The PRD covers: goals, user stories, functional requirements, non-goals, design/technical considerations, success metrics, and open questions. Written to be clear enough for a junior developer to implement from.

---

gsdl-create-plan — Generate Task List

Breaks down a PRD into a hierarchical, checkbox-tracked task list. Uses a two-phase process: shows parent tasks first, waits for your "Go", then generates detailed sub-tasks. The PRD is re-read from disk before each phase, so any edits you make between steps are picked up.

Trigger phrases: "create a plan", "generate tasks from the PRD", "break this down into tasks"

Output: .planning/[project-name]/tasks-prd-[feature-name].md

Task format:

- [ ] 1.0 Parent Task
  - [ ] 1.1 Sub-task
  - [ ] 1.2 Sub-task
- [ ] 2.0 Parent Task
  - [ ] 2.1 Sub-task

Also includes a Relevant Files section listing every file expected to be created or modified.

---

gsdl-execute-plan — Execute Plan

Works through a task list one sub-task at a time. Marks tasks complete as it goes, commits to git when a parent task finishes, and pauses for your approval before moving to the next sub-task. The task list is always read from disk at the start, so any manual edits you made before execution are respected.

Trigger phrases: "execute the plan", "start implementing", "work through the tasks"

Completion protocol per sub-task:

1. Implement the sub-task
2. Mark [ ] → [x] in the task file
3. If all sub-tasks under a parent are done, mark the parent [x] and commit to git
4. Pause and wait for your approval to continue

Permission phrases to continue: yes, y, go, continue, next, proceed, keep going

---

gsdl-document-decisions — Document Decisions

Analyzes what was built during a GSDL project, captures key decisions and architecture changes, saves them to a markdown file, and optionally publishes to Slite or Notion. Called automatically by the gsdl orchestrator after all implementation tasks are complete.

Trigger phrases: "document decisions", "capture architecture decisions", "write up what was built"

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

The document covers: a project summary, key decisions with rationale and impact, architecture changes (new structure, dependencies, integration points), what was explicitly not built, and a full file-change table.

Publishing: After saving the file, the skill asks whether to push the document to Slite or Notion as a child page. Provide a parent page URL to publish, or skip to keep it local only.

Supports:

• Slite — via MCP (create-note) or the Slite REST API ($SLITE_API_KEY)
• Notion — via MCP or the Notion REST API ($NOTION_TOKEN), with full Markdown-to-block conversion

---

File Structure

All planning files live under .planning/. Implementation code lives at the workspace root.

workspace-root/
├── .planning/
│   └── project-name/
│       ├── seed.md
│       ├── progress.md                    ← tracks current phase + active file paths
│       ├── prd-feature-name.md
│       ├── tasks-prd-feature-name.md
│       └── decisions-project-name.md      ← generated by Phase 4
├── src/
│   └── (implementation files)
└── README.md

---

Installation

Option 1 — npx skills (recommended)

Install using the open agent skills CLI:

Install to the current project (committed with your repo, shared with your team):

npx skills@1.4.0 add nsantini/gsdl -a cursor

Install globally (available across all your projects):

npx skills@1.4.0 add nsantini/gsdl -a cursor -g

nb: using skills@1.4.0 until bug causing not to properly symlic to cursor is fixed

Both commands target Cursor via the -a cursor flag. Cursor will automatically detect the skills and make them available to the agent.

Option 2 — Manual copy

Copy the .cursor/skills/ folder into your project or ~/.cursor/skills/ for a global install:

# Project-level
cp -r .cursor/skills/ /path/to/your/project/.cursor/skills/

# Global
cp -r .cursor/skills/ ~/.cursor/skills/

---

Usage

Trigger any skill by describing what you want in natural language in the Cursor chat. The agent will detect the relevant skill and follow the appropriate workflow.

Run the full pipeline on a new idea:

"Let's GSD — I want to build a CLI tool that syncs local files to S3"

Start from a Linear ticket:

/gsdl linear https://linear.app/myteam/issue/ENG-123/my-feature

Start from a Notion doc:

/gsdl notion https://www.notion.so/workspace/My-Spec-abc123def456

Start from a Slite doc:

/gsdl slite https://myteam.slite.com/p/abc123/My-Doc-Title

Auto-detect the source from the URL:

/gsdl https://linear.app/myteam/issue/ENG-123/my-feature

Resume an in-progress project:

/gsdl my-project — picks up where you left off, no questions asked

Jump straight to a specific phase:

"Create a PRD for the my-project seed file" "Generate a task list from .planning/my-project/prd-auth.md" "Execute the plan at .planning/my-project/tasks-prd-auth.md"