Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
ctsstc avatar

Gsd

  • 3k installs
  • 8 repo stars
  • Updated January 20, 2026
  • ctsstc/get-shit-done-skills

gsd is the Get Shit Done agent project system for initialization, phase planning, wave execution, verification, debugging, and codebase mapping.

About

gsd is an agent skill implementing Get Shit Done, a modular project management system for developers working with Claude agents. It transforms project ideas into shipped software through deep questioning, domain research, roadmap creation, phase planning, execution, verification, and systematic debugging. Core philosophy treats PLAN.md files as execution prompts rather than passive documents, uses goal-backward planning starting from what must be true, enforces atomic commits per task, and stops before context degrades around fifty percent usage. Commands include new-project, plan-phase, execute-phase, map-codebase, debug, verify-work, and progress, backed by specialized agents such as codebase-mapper, planner, executor, debugger, verifier, and researchers. The system creates a dot planning directory with PROJECT.md, REQUIREMENTS.md, ROADMAP.md, STATE.md, phase artifacts, and codebase analysis files. Wave-based execution groups independent plans into parallel waves while anti-patterns reject enterprise ceremony, horizontal layer grouping, vague success criteria, and time estimates. Developers reach for it when initializing new software projects, planning and executing phases, mapp.

  • Commands: new-project, plan-phase, execute-phase, map-codebase, debug, verify-work, progress.
  • Goal-backward planning derives build tasks from what must be true for the goal.
  • Creates dot planning directory with PROJECT, REQUIREMENTS, ROADMAP, STATE, and phase artifacts.
  • Wave-based parallel execution with atomic commits per task.
  • Context budget guidance: peak quality under thirty percent, avoid work above seventy percent usage.

Gsd by the numbers

  • 2,952 all-time installs (skills.sh)
  • +95 installs in the week ending Aug 5, 2026 (Skillselion tracking)
  • Ranked #191 of 3,282 Productivity & Planning skills by installs in the Skillselion catalog
  • Security screen: CRITICAL risk (skills.sh audit)
  • Data as of Aug 5, 2026 (Skillselion catalog sync)
At a glance

gsd capabilities & compatibility

Capabilities
project initialization and questioning · phase planning and wave execution · codebase mapping with parallel agents · systematic debugging and verification · atomic commit workflow enforcement
Use cases
planning · project management · debugging
From the docs

What gsd says it does

Stop before context degrades (~50% usage)
SKILL.md
npx skills add https://github.com/ctsstc/get-shit-done-skills --skill gsd

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs3k
repo stars8
Security audit1 / 3 scanners passed
Last updatedJanuary 20, 2026
Repositoryctsstc/get-shit-done-skills

How do I structure a software project from idea to shipped phases with agent-friendly plans, verification, and clean git history?

Run the GSD agent project system for initialization, phase planning, wave execution, verification, debugging, and codebase mapping with atomic commits.

Who is it for?

Developers using Claude agents who need structured project initialization, phase plans, and systematic verification workflows.

Skip if: Skip when the task is a single-file fix or enterprise stakeholder ceremony rather than agent-driven phased delivery.

When should I use this skill?

User initializes a new project, plans or executes a phase, maps a codebase, debugs systematically, or verifies phase completion.

What you get

Dot planning artifacts, executable phase plans, wave-executed implementation, and goal-backward verification of outcomes.

  • `.planning/codebase/` analysis markdown files

By the numbers

  • Skill version 1.0.0
  • Uses 5 agent tools: Read, Bash, Grep, Glob, Write

Files

agents/codebase-mapper/SKILL.mdMarkdownGitHub ↗

GSD Codebase Mapper

Explores a codebase for a specific focus area and writes analysis documents directly to .planning/codebase/.

When to Use

Use this agent when:

  • You need to understand an existing codebase structure
  • Starting work on a brownfield project (existing code)
  • Need to document technology stack, architecture, or patterns
  • Want to identify technical debt and concerns
  • Preparing for a new phase that requires codebase context

Focus Areas

The mapper is spawned with one of four focus areas:

  • tech - Analyze technology stack and external integrations → writes STACK.md and INTEGRATIONS.md
  • arch - Analyze architecture and file structure → writes ARCHITECTURE.md and STRUCTURE.md
  • quality - Analyze coding conventions and testing patterns → writes CONVENTIONS.md and TESTING.md
  • concerns - Identify technical debt and issues → writes CONCERNS.md

Core Responsibilities

1. Explore thoroughly - Read relevant files, understand patterns, identify key components 2. Write directly - Create documents in .planning/codebase/ to reduce orchestrator context load 3. Be prescriptive - Document HOW things are done, not just WHAT exists 4. Include file paths - Every finding should have a file path in backticks for navigation 5. Return confirmation only - Don't return document contents, just confirm what was written

Why This Matters

These documents are consumed by other GSD commands:

`/gsd:plan-phase` loads relevant codebase docs when creating implementation plans:

Phase TypeDocuments Loaded
UI, frontend, componentsCONVENTIONS.md, STRUCTURE.md
API, backend, endpointsARCHITECTURE.md, CONVENTIONS.md
database, schema, modelsARCHITECTURE.md, STACK.md
testing, testsTESTING.md, CONVENTIONS.md
integration, external APIINTEGRATIONS.md, STACK.md
refactor, cleanupCONCERNS.md, ARCHITECTURE.md
setup, configSTACK.md, STRUCTURE.md

`/gsd:execute-phase` references codebase docs to:

  • Follow existing conventions when writing code
  • Know where to place new files (STRUCTURE.md)
  • Match testing patterns (TESTING.md)
  • Avoid introducing more technical debt (CONCERNS.md)

Process

Step 1: Parse Focus Area

Read the focus area from your prompt. It will be one of: tech, arch, quality, concerns.

Step 2: Determine Output Documents

Based on focus, determine which documents to write:

  • tech → STACK.md, INTEGRATIONS.md
  • arch → ARCHITECTURE.md, STRUCTURE.md
  • quality → CONVENTIONS.md, TESTING.md
  • concerns → CONCERNS.md

Step 3: Explore Codebase

Use appropriate exploration commands for your focus area:

For tech focus:

# Package manifests
ls package.json requirements.txt Cargo.toml go.mod pyproject.toml 2>/dev/null
cat package.json 2>/dev/null | head -100

# Config files
ls -la *.config.* .env* tsconfig.json .nvmrc .python-version 2>/dev/null

# Find SDK/API imports
grep -r "import.*stripe\|import.*supabase\|import.*aws\|import.*@" src/ --include="*.ts" --include="*.tsx" 2>/dev/null | head -50

For arch focus:

# Directory structure
find . -type d -not -path '*/node_modules/*' -not -path '*/.git/*' | head -50

# Entry points
ls src/index.* src/main.* src/app.* src/server.* app/page.* 2>/dev/null

# Import patterns to understand layers
grep -r "^import" src/ --include="*.ts" --include="*.tsx" 2>/dev/null | head -100

For quality focus:

# Linting/formatting config
ls .eslintrc* .prettierrc* eslint.config.* biome.json 2>/dev/null
cat .prettierrc 2>/dev/null

# Test files and config
ls jest.config.* vitest.config.* 2>/dev/null
find . -name "*.test.*" -o -name "*.spec.*" | head -30

# Sample source files for convention analysis
ls src/**/*.ts 2>/dev/null | head -10

For concerns focus:

# TODO/FIXME comments
grep -rn "TODO\|FIXME\|HACK\|XXX" src/ --include="*.ts" --include="*.tsx" 2>/dev/null | head -50

# Large files (potential complexity)
find src/ -name "*.ts" -o -name "*.tsx" | xargs wc -l 2>/dev/null | sort -rn | head -20

# Empty returns/stubs
grep -rn "return null\|return \[\]\|return {}" src/ --include="*.ts" --include="*.tsx" 2>/dev/null | head -30

Step 4: Write Documents

Write documents to .planning/codebase/ using the templates. Use the Write tool.

Document naming: UPPERCASE.md (e.g., STACK.md, ARCHITECTURE.md)

Template filling: 1. Replace [YYYY-MM-DD] with current date 2. Replace [Placeholder text] with findings from exploration 3. If something is not found, use "Not detected" or "Not applicable" 4. Always include file paths with backticks

Step 5: Return Confirmation

Return a brief confirmation. DO NOT include document contents.

Format:

## Mapping Complete

**Focus:** {focus}
**Documents written:**
- `.planning/codebase/{DOC1}.md` ({N} lines)
- `.planning/codebase/{DOC2}.md` ({N} lines)

Ready for orchestrator summary.

Document Templates

STACK.md Template

# Technology Stack

**Analysis Date:** [YYYY-MM-DD]

## Languages

**Primary:**
- [Language] [Version] - [Where used]

**Secondary:**
- [Language] [Version] - [Where used]

## Runtime

**Environment:**
- [Runtime] [Version]

**Package Manager:**
- [Manager] [Version]
- Lockfile: [present/missing]

## Frameworks

**Core:**
- [Framework] [Version] - [Purpose]

**Testing:**
- [Framework] [Version] - [Purpose]

**Build/Dev:**
- [Tool] [Version] - [Purpose]

## Key Dependencies

**Critical:**
- [Package] [Version] - [Why it matters]

**Infrastructure:**
- [Package] [Version] - [Purpose]

## Configuration

**Environment:**
- [How configured]
- [Key configs required]

**Build:**
- [Build config files]

## Platform Requirements

**Development:**
- [Requirements]

**Production:**
- [Deployment target]

---

*Stack analysis: [date]*

ARCHITECTURE.md Template

# Architecture

**Analysis Date:** [YYYY-MM-DD]

## Pattern Overview

**Overall:** [Pattern name]

**Key Characteristics:**
- [Characteristic 1]
- [Characteristic 2]
- [Characteristic 3]

## Layers

**[Layer Name]:**
- Purpose: [What this layer does]
- Location: `[path]`
- Contains: [Types of code]
- Depends on: [What it uses]
- Used by: [What uses it]

## Data Flow

**[Flow Name]:**

1. [Step 1]
2. [Step 2]
3. [Step 3]

**State Management:**
- [How state is handled]

## Key Abstractions

**[Abstraction Name]:**
- Purpose: [What it represents]
- Examples: `[file paths]`
- Pattern: [Pattern used]

## Entry Points

**[Entry Point]:**
- Location: `[path]`
- Triggers: [What invokes it]
- Responsibilities: [What it does]

## Error Handling

**Strategy:** [Approach]

**Patterns:**
- [Pattern 1]
- [Pattern 2]

## Cross-Cutting Concerns

**Logging:** [Approach]
**Validation:** [Approach]
**Authentication:** [Approach]

---

*Architecture analysis: [date]*

STRUCTURE.md Template

# Codebase Structure

**Analysis Date:** [YYYY-MM-DD]

## Directory Layout

[project-root]/ ├── [dir]/ # [Purpose] ├── [dir]/ # [Purpose] └── [file] # [Purpose]


## Directory Purposes

**[Directory Name]:**
- Purpose: [What lives here]
- Contains: [Types of files]
- Key files: `[important files]`

## Key File Locations

**Entry Points:**
- `[path]`: [Purpose]

**Configuration:**
- `[path]`: [Purpose]

**Core Logic:**
- `[path]`: [Purpose]

**Testing:**
- `[path]`: [Purpose]

## Naming Conventions

**Files:**
- [Pattern]: [Example]

**Directories:**
- [Pattern]: [Example]

## Where to Add New Code

**New Feature:**
- Primary code: `[path]`
- Tests: `[path]`

**New Component/Module:**
- Implementation: `[path]`

**Utilities:**
- Shared helpers: `[path]`

## Special Directories

**[Directory]:**
- Purpose: [What it contains]
- Generated: [Yes/No]
- Committed: [Yes/No]

---

*Structure analysis: [date]*

CONVENTIONS.md Template

# Coding Conventions

**Analysis Date:** [YYYY-MM-DD]

## Naming Patterns

**Files:**
- [Pattern observed]

**Functions:**
- [Pattern observed]

**Variables:**
- [Pattern observed]

**Types:**
- [Pattern observed]

## Code Style

**Formatting:**
- [Tool used]
- [Key settings]

**Linting:**
- [Tool used]
- [Key rules]

## Import Organization

**Order:**
1. [First group]
2. [Second group]
3. [Third group]

**Path Aliases:**
- [Aliases used]

## Error Handling

**Patterns:**
- [How errors are handled]

## Logging

**Framework:** [Tool or "console"]

**Patterns:**
- [When/how to log]

## Comments

**When to Comment:**
- [Guidelines observed]

**JSDoc/TSDoc:**
- [Usage pattern]

## Function Design

**Size:** [Guidelines]

**Parameters:** [Pattern]

**Return Values:** [Pattern]

## Module Design

**Exports:** [Pattern]

**Barrel Files:** [Usage]

---

*Convention analysis: [date]*

TESTING.md Template

# Testing Patterns

**Analysis Date:** [YYYY-MM-DD]

## Test Framework

**Runner:**
- [Framework] [Version]
- Config: `[config file]`

**Assertion Library:**
- [Library]

**Run Commands:**

[command] # Run all tests [command] # Watch mode [command] # Coverage


## Test File Organization

**Location:**
- [Pattern: co-located or separate]

**Naming:**
- [Pattern]

**Structure:**

[Directory pattern]


## Test Structure

**Suite Organization:**

[Show actual pattern from codebase]


**Patterns:**
- [Setup pattern]
- [Teardown pattern]
- [Assertion pattern]

## Mocking

**Framework:** [Tool]

**Patterns:**

[Show actual mocking pattern from codebase]


**What to Mock:**
- [Guidelines]

**What NOT to Mock:**
- [Guidelines]

## Fixtures and Factories

**Test Data:**

[Show pattern from codebase]


**Location:**
- [Where fixtures live]

## Coverage

**Requirements:** [Target or "None enforced"]

**View Coverage:**

[command]


## Test Types

**Unit Tests:**
- [Scope and approach]

**Integration Tests:**
- [Scope and approach]

**E2E Tests:**
- [Framework or "Not used"]

## Common Patterns

**Async Testing:**

[Pattern]


**Error Testing:**

[Pattern]


---

*Testing analysis: [date]*

INTEGRATIONS.md Template

# External Integrations

**Analysis Date:** [YYYY-MM-DD]

## APIs & External Services

**[Category]:**
- [Service] - [What it's used for]
  - SDK/Client: [package]
  - Auth: [env var name]

## Data Storage

**Databases:**
- [Type/Provider]
  - Connection: [env var]
  - Client: [ORM/client]

**File Storage:**
- [Service or "Local filesystem only"]

**Caching:**
- [Service or "None"]

## Authentication & Identity

**Auth Provider:**
- [Service or "Custom"]
  - Implementation: [approach]

## Monitoring & Observability

**Error Tracking:**
- [Service or "None"]

**Logs:**
- [Approach]

## CI/CD & Deployment

**Hosting:**
- [Platform]

**CI Pipeline:**
- [Service or "None"]

## Environment Configuration

**Required env vars:**
- [List critical vars]

**Secrets location:**
- [Where secrets are stored]

## Webhooks & Callbacks

**Incoming:**
- [Endpoints or "None"]

**Outgoing:**
- [Endpoints or "None"]

---

*Integration audit: [date]*

CONCERNS.md Template

# Codebase Concerns

**Analysis Date:** [YYYY-MM-DD]

## Tech Debt

**[Area/Component]:**
- Issue: [What's the shortcut/workaround]
- Files: `[file paths]`
- Impact: [What breaks or degrades]
- Fix approach: [How to address it]

## Known Bugs

**[Bug description]:**
- Symptoms: [What happens]
- Files: `[file paths]`
- Trigger: [How to reproduce]
- Workaround: [If any]

## Security Considerations

**[Area]:**
- Risk: [What could go wrong]
- Files: `[file paths]`
- Current mitigation: [What's in place]
- Recommendations: [What should be added]

## Performance Bottlenecks

**[Slow operation]:**
- Problem: [What's slow]
- Files: `[file paths]`
- Cause: [Why it's slow]
- Improvement path: [How to speed up]

## Fragile Areas

**[Component/Module]:**
- Files: `[file paths]`
- Why fragile: [What makes it break easily]
- Safe modification: [How to change safely]
- Test coverage: [Gaps]

## Scaling Limits

**[Resource/System]:**
- Current capacity: [Numbers]
- Limit: [Where it breaks]
- Scaling path: [How to increase]

## Dependencies at Risk

**[Package]:**
- Risk: [What's wrong]
- Impact: [What breaks]
- Migration plan: [Alternative]

## Missing Critical Features

**[Feature gap]:**
- Problem: [What's missing]
- Blocks: [What can't be done]

## Test Coverage Gaps

**[Untested area]:**
- What's not tested: [Specific functionality]
- Files: `[file paths]`
- Risk: [What could break unnoticed]
- Priority: [High/Medium/Low]

---

*Concerns audit: [date]*

Critical Rules

  • WRITE DOCUMENTS DIRECTLY - Do not return findings to orchestrator. The whole point is reducing context transfer.
  • ALWAYS INCLUDE FILE PATHS - Every finding needs a file path in backticks. No exceptions.
  • USE THE TEMPLATES - Fill in the template structure. Don't invent your own format.
  • BE THOROUGH - Explore deeply. Read actual files. Don't guess.
  • RETURN ONLY CONFIRMATION - Your response should be ~10 lines max. Just confirm what was written.
  • DO NOT COMMIT - The orchestrator handles git operations.

Success Criteria

  • [ ] Focus area parsed correctly
  • [ ] Codebase explored thoroughly for focus area
  • [ ] All documents for focus area written to .planning/codebase/
  • [ ] Documents follow template structure
  • [ ] File paths included throughout documents
  • [ ] Confirmation returned (not document contents)

Related Skills

  • @skills/gsd/commands/map-codebase - Command that spawns this agent
  • @skills/gsd/references/git-integration - Git workflow patterns

Related skills

How it compares

Pick gsd over ad-hoc repo questions when you need durable, structured planning documents agents can reload across sessions.

FAQ

What is goal-backward planning in GSD?

Start from what must be true for the goal, then derive what to build instead of listing tasks forward from features.

What directory does GSD create?

A dot planning directory with PROJECT.md, config.json, REQUIREMENTS.md, ROADMAP.md, STATE.md, research, phases, and codebase folders.

When should agents stop working in GSD?

Before context degrades around fifty percent usage; quality drops significantly above seventy percent.

Is Gsd safe to install?

skills.sh reports 1 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.