get-shit-done-cc 1.10.0-experimental.0 → 1.10.0

package/get-shit-done/skills/gsd-extend/templates/workflow-template.md

@@ -1,169 +0,0 @@
----
-name: workflow-template
-description: Template for creating custom workflow extensions
-used_by:
-  - create-workflow
-placeholders:
-  - name
-  - description
-  - triggers
-  - replaces
-  - requires
-  - purpose
-  - when_to_use
-  - required_reading
-  - steps
-  - success_criteria
----
-
-<template>
-
-```yaml
----
-name: {name}
-description: {description}
-triggers: [{triggers}]
-replaces: {replaces}
-requires: [{requires}]
----
-```
-
-```xml
-<purpose>
-{purpose}
-</purpose>
-
-<when_to_use>
-{when_to_use}
-</when_to_use>
-
-<required_reading>
-{required_reading}
-</required_reading>
-
-<process>
-
-{steps}
-
-</process>
-
-<success_criteria>
-{success_criteria}
-</success_criteria>
-```
-
-</template>
-
-<guidelines>
-
-## How to Fill This Template
-
-**{name}:** kebab-case identifier matching filename (e.g., `my-custom-workflow`)
-
-**{description}:** One sentence describing what this workflow accomplishes
-
-**{triggers}:** Array of trigger points:
-- `plan-phase` - Triggered by /gsd:plan-phase
-- `execute-plan` - Triggered during plan execution
-- `execute-phase` - Triggered by /gsd:execute-phase
-- `verify-phase` - Triggered during verification
-- `custom` - Only triggered via explicit reference
-
-**{replaces}:** Name of built-in workflow to override, or `null` for new capability
-
-**{requires}:** Array of reference names this workflow needs, or `[]` for none
-
-**{purpose}:** 2-3 sentences explaining what this workflow does and why
-
-**{when_to_use}:** Bullet list of conditions that make this workflow appropriate
-
-**{required_reading}:** @-references to files that must be loaded
-
-**{steps}:** Series of `<step name="step_name">` elements, each containing:
-- Clear description of what the step does
-- Code examples if needed
-- Conditional logic if needed
-
-**{success_criteria}:** Markdown checklist of completion criteria
-
-</guidelines>
-
-<examples>
-
-## Good Example
-
-```yaml
----
-name: spike-first-planning
-description: Plan by creating a spike implementation first
-triggers: [plan-phase]
-replaces: null
-requires: []
----
-```
-
-```xml
-<purpose>
-Alternative planning workflow that creates a spike implementation first,
-then derives formal plans from what worked. Use when exploring unfamiliar
-domains where requirements are fuzzy.
-</purpose>
-
-<when_to_use>
-- Domain is unfamiliar and approach is uncertain
-- Requirements are vague or evolving
-- Learning through implementation is valuable
-- Risk of over-planning is high
-</when_to_use>
-
-<process>
-
-<step name="create_spike">
-Create a time-boxed spike task focusing on the core uncertainty.
-Goal is learning, not production quality.
-</step>
-
-<step name="execute_spike">
-Execute spike with 1-2 hour time limit. Document:
-- What worked
-- What didn't work
-- Key decisions made
-- Approach to formalize
-</step>
-
-<step name="derive_plans">
-From spike learnings, create formal PLAN.md files:
-- Extract the successful approach
-- Add proper verification
-- Define success criteria
-</step>
-
-</process>
-
-<success_criteria>
-- [ ] Spike completed within time box
-- [ ] Learnings documented
-- [ ] Formal plans derived from spike
-- [ ] Ready for normal execution
-</success_criteria>
-```
-
-## Bad Example
-
-```yaml
----
-name: workflow
-description: Does stuff
-triggers: []
----
-```
-
-Problems:
-- Name is too generic
-- Description is vague
-- No triggers defined
-- No purpose section
-- No steps documented
-- No success criteria
-
-</examples>

package/get-shit-done/skills/gsd-extend/workflows/create-approach.md

@@ -1,332 +0,0 @@
-<purpose>
-Create a complete GSD approach through conversational discovery. An approach is a cohesive methodology - a workflow with supporting references, agents, and templates that work together.
-
-You are a thinking partner, not an interviewer. The user knows what they want to achieve differently. Your job is to understand their vision and translate it into GSD components.
-</purpose>
-
-<required_reading>
-@~/.claude/get-shit-done/skills/gsd-extend/references/extension-anatomy.md
-</required_reading>
-
-<philosophy>
-**User = methodology designer. Claude = builder.**
-
-The user knows:
-- What frustrates them about current workflow
-- What they imagine working better
-- When they'd use this approach
-- What success looks like
-
-The user doesn't know (and shouldn't need to):
-- GSD extension architecture
-- Workflow vs agent vs reference distinctions
-- XML structure and frontmatter format
-- How to wire components together
-
-Ask about their vision. You figure out the implementation.
-</philosophy>
-
-<process>
-
-<step name="open_conversation" priority="first">
-**Display stage banner:**
-
-```
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- GSD ► CREATE APPROACH
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-```
-
-**Open the conversation:**
-
-Ask inline (freeform, NOT AskUserQuestion):
-
-"What would you like GSD to do differently? Describe the workflow or approach you have in mind."
-
-Wait for their response. This gives you context to ask intelligent follow-up questions.
-</step>
-
-<step name="follow_the_thread">
-Based on what they said, ask follow-up questions that dig into their response.
-
-**Use AskUserQuestion with options that probe what they mentioned:**
-- Interpretations of vague terms
-- Clarifications on triggers
-- Concrete examples of what success looks like
-
-**Keep following threads.** Each answer opens new threads. Ask about:
-- What frustrates them about the current approach
-- What specifically would be different
-- When this approach applies vs doesn't
-- What outputs or artifacts they expect
-- What domain knowledge would help
-
-**Example follow-up patterns:**
-
-If they mention "spike first":
-- "When you say spike, do you mean throwaway code or a minimal prototype?"
-- "What happens after the spike? Formal plans, or iterate on the spike?"
-- "How do you know when the spike is done?"
-
-If they mention "security review":
-- "At what point - before commit, before PR, after each task?"
-- "What should it check? OWASP top 10, or specific patterns?"
-- "Should it block on findings or just report?"
-
-If they mention "API first":
-- "OpenAPI spec, or informal contract?"
-- "Generate code from spec, or just validate against it?"
-- "Who writes the spec - you or Claude?"
-
-**The 4-then-check pattern:**
-
-After ~4 questions on a thread, check:
-
-- header: "Thread"
-- question: "More questions about [topic], or move on?"
-- options:
-  - "More questions" — I want to clarify further
-  - "Move on" — I've said enough about this
-
-If "More questions" → ask 4 more, then check again.
-</step>
-
-<step name="identify_components">
-As you converse, mentally map what they're describing to GSD components:
-
-**Workflow signals:**
-- "First I want to..., then..." → sequence of steps
-- "At this point, check..." → verification step
-- "If X happens, then..." → conditional logic
-- "This replaces..." → override built-in
-
-**Reference signals:**
-- "Claude should know about..." → domain knowledge
-- "There are patterns for..." → best practices
-- "Watch out for..." → anti-patterns
-- "In our codebase, we..." → project conventions
-
-**Agent signals:**
-- "Specialized analysis of..." → focused worker
-- "Review for..." → auditing task
-- "Research..." → investigation task
-- "Generate..." → creation task
-
-**Template signals:**
-- "The output should look like..." → structured format
-- "Always include..." → required sections
-- "Following this format..." → consistency need
-
-Don't surface this analysis. Just track it internally.
-</step>
-
-<step name="ready_check">
-When you could design the approach, use AskUserQuestion:
-
-- header: "Ready?"
-- question: "I think I understand what you're after. Ready to design the approach?"
-- options:
-  - "Design it" — Let's see what you've got
-  - "Keep exploring" — I want to share more
-
-If "Keep exploring" — ask what they want to add, or identify gaps and probe naturally.
-
-Loop until "Design it" selected.
-</step>
-
-<step name="present_design">
-Present the approach design:
-
-```
-## Proposed Approach: {name}
-
-Based on our conversation, here's what I'll create:
-
-**Workflow:** {name}.md
-- Triggers: {when it activates}
-- {Replaces: {built-in} OR Adds new capability}
-- Flow:
-  1. {step 1}
-  2. {step 2}
-  3. {step 3}
-
-{If reference needed:}
-**Reference:** {name}-patterns.md
-- Domain knowledge about: {what}
-- Loaded when: {triggers}
-
-{If agent needed:}
-**Agent:** {name}-{role}.md
-- Purpose: {what it does}
-- Spawned: {when in the workflow}
-
-{If template needed:}
-**Template:** {name}-{artifact}.md
-- Produces: {what artifact}
-- Used by: {workflow step}
-
----
-
-Does this capture your approach?
-```
-
-Use AskUserQuestion:
-- header: "Design"
-- question: "Does this design capture what you described?"
-- options:
-  - "Yes, create it" — Build all the components
-  - "Adjust" — Let me tell you what's different
-  - "Start over" — I want to describe it differently
-
-If "Adjust" — get their feedback, update design, present again.
-If "Start over" — return to open_conversation.
-</step>
-
-<step name="determine_scope">
-Use AskUserQuestion:
-
-- header: "Scope"
-- question: "Where should this approach be available?"
-- options:
-  - "All my projects (Recommended)" — Install to ~/.claude/gsd-extensions/
-  - "This project only" — Install to .planning/extensions/
-</step>
-
-<step name="generate_components">
-Create all components with proper cross-references.
-
-**1. Create directories:**
-
-```bash
-if [[ "$SCOPE" == "global" ]]; then
-  BASE="$HOME/.claude/gsd-extensions"
-else
-  BASE=".planning/extensions"
-fi
-
-mkdir -p "$BASE/workflows"
-[[ -n "$NEEDS_REFERENCE" ]] && mkdir -p "$BASE/references"
-[[ -n "$NEEDS_AGENT" ]] && mkdir -p "$BASE/agents"
-[[ -n "$NEEDS_TEMPLATE" ]] && mkdir -p "$BASE/templates"
-```
-
-**2. Generate each component:**
-
-For each component, use the appropriate structure from references/:
-- Workflow: @references/workflow-structure.md
-- Agent: @references/agent-structure.md
-- Reference: @references/reference-structure.md
-- Template: @references/template-structure.md
-
-**3. Wire components together:**
-
-In the workflow, add @-references to other components:
-
-```xml
-<required_reading>
-@{BASE}/references/{name}-patterns.md
-</required_reading>
-
-<step name="spawn_specialized_agent">
-Task(
-  prompt="@{BASE}/agents/{name}-{role}.md
-
-  <context>
-  {context from workflow state}
-  </context>",
-  subagent_type="general-purpose",
-  model="sonnet",
-  description="{brief}"
-)
-</step>
-
-<output>
-Use template: @{BASE}/templates/{name}-{artifact}.md
-</output>
-```
-</step>
-
-<step name="validate">
-Validate all components:
-
-```bash
-echo "Validating approach..."
-
-for file in "$BASE"/*/"${PREFIX}"*.md; do
-  echo "  Checking: $(basename $file)"
-
-  # YAML frontmatter
-  head -5 "$file" | grep -q "^---" && echo "    ✓ Frontmatter" || echo "    ✗ Missing frontmatter"
-
-  # Required fields
-  grep -q "^name:" "$file" && echo "    ✓ Name field" || echo "    ✗ Missing name"
-  grep -q "^description:" "$file" && echo "    ✓ Description" || echo "    ✗ Missing description"
-done
-
-# Check cross-references resolve
-echo "  Checking references..."
-grep -ohE '@[~./][^[:space:]<>]+' "$BASE/workflows/${PREFIX}"*.md 2>/dev/null | while read ref; do
-  path="${ref#@}"
-  path="${path/#\~/$HOME}"
-  [[ -f "$path" ]] && echo "    ✓ $ref" || echo "    ✗ $ref NOT FOUND"
-done
-
-echo "Validation complete."
-```
-</step>
-
-<step name="present_result">
-```
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- GSD ► APPROACH CREATED ✓
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-## {Approach Name}
-
-| Component | Location |
-|-----------|----------|
-| Workflow | {path} |
-| Reference | {path} |
-| Agent | {path} |
-| Template | {path} |
-
-───────────────────────────────────────────────────────────────
-
-## How to Use
-
-{If replaces built-in:}
-Automatically activates when you run `{command}`.
-GSD uses your workflow instead of the built-in.
-
-{If new capability:}
-Reference in your plans or workflows:
-@{workflow_path}
-
-Or invoke the workflow step name from your commands.
-
-───────────────────────────────────────────────────────────────
-
-## To Customize
-
-Edit files directly:
-{list paths}
-
-## To Remove
-
-/gsd:extend remove {name}
-
-───────────────────────────────────────────────────────────────
-```
-</step>
-
-</process>
-
-<success_criteria>
-- [ ] User's vision fully understood through conversation
-- [ ] Follow-up questions probed what user mentioned (not generic)
-- [ ] User confirmed design before generation
-- [ ] All needed components identified and created
-- [ ] Components properly cross-referenced
-- [ ] All components pass validation
-- [ ] User knows how to use and customize the approach
-</success_criteria>

package/get-shit-done/skills/gsd-extend/workflows/list-extensions.md

@@ -1,133 +0,0 @@
-<purpose>
-Discover and list all GSD extensions, grouped by approach when components share naming conventions.
-</purpose>
-
-<process>
-
-<step name="scan_extensions">
-Scan all extension locations:
-
-```bash
-echo "Scanning extensions..."
-
-# Collect all extension files
-PROJECT_EXTS=$(find .planning/extensions -name "*.md" 2>/dev/null | sort)
-GLOBAL_EXTS=$(find ~/.claude/gsd-extensions -name "*.md" 2>/dev/null | sort)
-BUILTIN_WORKFLOWS=$(ls ~/.claude/get-shit-done/workflows/*.md 2>/dev/null | wc -l | xargs)
-BUILTIN_REFS=$(ls ~/.claude/get-shit-done/references/*.md 2>/dev/null | wc -l | xargs)
-BUILTIN_TEMPLATES=$(ls ~/.claude/get-shit-done/templates/*.md 2>/dev/null | wc -l | xargs)
-```
-</step>
-
-<step name="identify_approaches">
-Group extensions by shared prefix to identify approaches:
-
-For each extension file:
-1. Extract the base name (e.g., `spike-first-planning.md` → `spike-first`)
-2. Group files with same prefix across types
-3. Identify cohesive approaches vs standalone components
-
-```bash
-# Example grouping logic
-for ext in $GLOBAL_EXTS; do
-  type=$(dirname "$ext" | xargs basename)
-  name=$(basename "$ext" .md)
-  prefix=$(echo "$name" | sed 's/-[^-]*$//')  # Remove last segment
-  echo "$prefix|$type|$name"
-done | sort
-```
-</step>
-
-<step name="format_output">
-Present extensions organized by scope and approach:
-
-```
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- GSD ► EXTENSIONS
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-## Project Extensions (.planning/extensions/)
-
-{If none:}
-None installed.
-
-{If found, group by approach:}
-
-### spike-first (approach)
-- workflows/spike-first-planning.md
-- references/spike-patterns.md
-- agents/spike-evaluator.md
-
-### security-audit (standalone workflow)
-- workflows/security-audit.md
-
-───────────────────────────────────────────────────────────────
-
-## Global Extensions (~/.claude/gsd-extensions/)
-
-{Same format}
-
-───────────────────────────────────────────────────────────────
-
-## Built-in GSD
-
-- {N} workflows
-- {N} references
-- {N} templates
-- {N} agents
-
-───────────────────────────────────────────────────────────────
-
-## Override Status
-
-{List any custom extensions that override built-ins}
-
-───────────────────────────────────────────────────────────────
-
-## Actions
-
-/gsd:extend create    — Create a new approach
-/gsd:extend remove X  — Remove an extension
-
-───────────────────────────────────────────────────────────────
-```
-</step>
-
-<step name="detail_on_request">
-If user asks about a specific extension, show details:
-
-```bash
-# Read frontmatter
-head -20 "$EXT_PATH" | sed -n '/^---$/,/^---$/p'
-
-# Show structure
-wc -l "$EXT_PATH"
-
-# Show cross-references
-grep -oE '@[~./][^[:space:]]+' "$EXT_PATH"
-```
-
-Present:
-```
-## Extension: {name}
-
-**Type:** {workflow/agent/reference/template}
-**Location:** {path}
-**Description:** {from frontmatter}
-
-**Cross-references:**
-{list of @-references}
-
-**Structure:**
-{line count, sections present}
-```
-</step>
-
-</process>
-
-<success_criteria>
-- [ ] All scopes scanned (project, global, built-in)
-- [ ] Extensions grouped by approach where applicable
-- [ ] Override status identified
-- [ ] User knows how to create/remove
-</success_criteria>