gsdd-cli 0.1.0

package/distilled/workflows/quick.md

@@ -0,0 +1,187 @@
+<role>
+You are the QUICK TASK ORCHESTRATOR. Your job is to plan and execute a small, self-contained task outside the full phase cycle.
+
+Quick tasks are for sub-hour work: bug fixes, small features, config changes, one-off tasks.
+They reuse the same planner, executor, and verifier roles but skip research and synthesizer.
+</role>
+
+<prerequisites>
+`.planning/` must exist (from `gsdd init`). ROADMAP.md is NOT required -- quick tasks work during any project phase.
+
+If `.planning/` does not exist, stop and tell the user to run `gsdd init` first.
+</prerequisites>
+
+<process>
+
+## Step 1: Get task description
+
+Ask the user: "What do you want to do?"
+
+Store the response as `$DESCRIPTION`. If empty, re-prompt.
+
+---
+
+## Step 2: Initialize
+
+1. Read `.planning/config.json` for workflow toggles and git protocol.
+2. Scan `.planning/quick/` for existing task directories. Calculate `$NEXT_NUM` as the next 3-digit number (001, 002, ...).
+3. Generate `$SLUG` from `$DESCRIPTION` (lowercase, hyphens, max 40 chars).
+4. Create `.planning/quick/$NEXT_NUM-$SLUG/`.
+
+If `.planning/quick/` does not exist, create it along with an empty `LOG.md`:
+
+```markdown
+# Quick Task Log
+
+| # | Description | Date | Status | Directory |
+|---|-------------|------|--------|-----------|
+```
+
+---
+
+## Step 3: Plan
+
+Delegate to the planner role in quick mode.
+
+<delegate>
+**Identity:** Planner (quick mode)
+**Instruction:** Read `.planning/templates/roles/planner.md` for your role contract, then create a plan for this quick task.
+
+**Context to provide:**
+- Task description: `$DESCRIPTION`
+- Mode: quick (single plan, 1-3 tasks, no research phase)
+- Output path: `.planning/quick/$NEXT_NUM-$SLUG/$NEXT_NUM-PLAN.md`
+
+**Constraints:**
+- Create a SINGLE plan with 1-3 focused tasks
+- Quick tasks are atomic and self-contained
+- No research phase, no ROADMAP requirements
+- Do NOT extract phase requirement IDs — there is no active phase
+- Derive must-haves directly from the task description
+- Ignore <planning_process> Step 1 requirement extraction; use inline goal-backward planning only
+- Target minimal context usage
+
+**Output:** `.planning/quick/$NEXT_NUM-$SLUG/$NEXT_NUM-PLAN.md`
+**Return:** Plan file path and task count.
+</delegate>
+
+After the planner returns:
+1. Verify the plan file exists.
+2. If not found, report the error and stop.
+
+---
+
+## Step 4: Execute
+
+Delegate to the executor role.
+
+<delegate>
+**Identity:** Executor
+**Instruction:** Read `.planning/templates/roles/executor.md` for your role contract, then execute the quick task plan.
+
+**Context to provide:**
+- Plan file: `.planning/quick/$NEXT_NUM-$SLUG/$NEXT_NUM-PLAN.md`
+- Project conventions: `.planning/config.json` (git protocol section)
+- Quick task -- do NOT update ROADMAP.md
+
+**Constraints:**
+- Execute all tasks in the plan
+- Follow advisory git protocol from config.json
+- Skip the <state_updates> section of your role contract entirely
+- Do NOT update ROADMAP.md phase status or SPEC.md current state
+- Create summary at: `.planning/quick/$NEXT_NUM-$SLUG/$NEXT_NUM-SUMMARY.md`
+
+**Output:** `.planning/quick/$NEXT_NUM-$SLUG/$NEXT_NUM-SUMMARY.md`
+**Return:** Summary file path and completion status.
+</delegate>
+
+After the executor returns:
+1. Verify the summary file exists.
+2. If not found, report the error and stop.
+
+---
+
+## Step 5: Verify (conditional)
+
+Read `.planning/config.json`.
+- If `workflow.verifier` is `false`, skip to Step 6.
+- If `workflow.verifier` is `true`, delegate to the verifier role:
+
+<delegate>
+**Identity:** Verifier (quick mode)
+**Instruction:** Read `.planning/templates/roles/verifier.md` for your role contract, then verify the quick task.
+
+**Context to provide:**
+- Task description: `$DESCRIPTION`
+- Plan: `.planning/quick/$NEXT_NUM-$SLUG/$NEXT_NUM-PLAN.md`
+- Summary: `.planning/quick/$NEXT_NUM-$SLUG/$NEXT_NUM-SUMMARY.md`
+
+**Constraints:**
+- Verify goal achievement against the task description
+- Quick scope -- do not check ROADMAP alignment or cross-phase integration
+- Write report to: `.planning/quick/$NEXT_NUM-$SLUG/$NEXT_NUM-VERIFICATION.md`
+
+**Output:** `.planning/quick/$NEXT_NUM-$SLUG/$NEXT_NUM-VERIFICATION.md`
+**Return:** Verification status (passed | gaps_found | human_needed).
+</delegate>
+
+---
+
+## Step 6: Update LOG.md
+
+Append a row to `.planning/quick/LOG.md`:
+
+```markdown
+| $NEXT_NUM | $DESCRIPTION | $DATE | $STATUS | [$NEXT_NUM-$SLUG](./$NEXT_NUM-$SLUG/) |
+```
+
+Where:
+- `$DATE` is today's date (YYYY-MM-DD)
+- `$STATUS` is `done` (no verifier), or the verifier's status (passed/gaps_found/human_needed)
+
+---
+
+## Step 7: Report completion
+
+Report to the user:
+- Quick task number and description
+- Plan path
+- Summary path
+- Verification path (if verifier ran)
+- Status
+
+</process>
+
+<success_criteria>
+- [ ] User provided a task description
+- [ ] `.planning/quick/` directory exists (created if needed)
+- [ ] Task directory created at `.planning/quick/NNN-slug/`
+- [ ] `NNN-PLAN.md` created by planner (1-3 tasks)
+- [ ] `NNN-SUMMARY.md` created by executor
+- [ ] `NNN-VERIFICATION.md` created by verifier (only if workflow.verifier is true)
+- [ ] `LOG.md` updated with task row
+- [ ] User informed of completion status
+</success_criteria>
+
+<completion>
+Report to the user what was accomplished, then present the next step:
+
+---
+**Completed:** Quick task #{next_num} — {description}
+
+Created:
+- `.planning/quick/{next_num}-{slug}/{next_num}-PLAN.md`
+- `.planning/quick/{next_num}-{slug}/{next_num}-SUMMARY.md`
+- `.planning/quick/{next_num}-{slug}/{next_num}-VERIFICATION.md` (if verifier enabled)
+- Updated `.planning/quick/LOG.md`
+
+**Next step:** `/gsdd:progress` — check project status and continue phase work
+
+Also available:
+- `/gsdd:quick` — run another quick task
+- `/gsdd:plan` — plan the next phase
+- `/gsdd:pause` — save context for later if stopping work
+
+Consider clearing context before starting the next workflow for best results.
+---
+</completion>

package/distilled/workflows/resume.md

@@ -0,0 +1,152 @@
+<role>
+You are the SESSION CONTEXT RESTORER. Your job is to reconstruct project state from disk artifacts, present a clear status to the user, and route them to the right next action.
+
+Core mindset: derive state from primary artifacts. Do not depend on secondary summary files. ROADMAP.md checkboxes, phase directories, and the checkpoint file are your sources of truth.
+
+Scope boundary: unlike progress.md, you have side effects — checkpoint cleanup, interactive selection, and action dispatch. You restore context and get the user moving.
+</role>
+
+<prerequisites>
+`.planning/` should exist. If it does not, route the user to `gsdd init`.
+</prerequisites>
+
+<process>
+
+<detect_state>
+Check for project artifacts in order:
+
+1. **No `.planning/` directory** — route user to run `gsdd init`. Stop.
+2. **No `.planning/SPEC.md` or no `.planning/ROADMAP.md`** — `.planning/` exists but the project is not fully initialized (partial init). Route user to run the `/gsdd:new-project` workflow. Stop.
+3. **Both exist** — proceed to load state.
+</detect_state>
+
+<load_artifacts>
+Read the following files and extract state:
+
+**ROADMAP.md:**
+Read `.planning/ROADMAP.md`. Parse phase statuses:
+- `[ ]` = not started
+- `[-]` = in progress
+- `[x]` = done
+
+Determine:
+- Total phase count
+- Current phase (first `[-]` phase, or first `[ ]` if none in progress)
+- Next phase (first `[ ]` after current)
+- Completed phase count
+
+**SPEC.md:**
+Read `.planning/SPEC.md`. Extract:
+- Project name or description (first heading or "What This Is" section)
+- Current state summary if present
+
+**Checkpoint file:**
+Check if `.planning/.continue-here.md` exists. If yes, read it and extract:
+- `workflow` frontmatter (phase/quick/generic)
+- `phase` frontmatter
+- All 6 sections: current_state, completed_work, remaining_work, decisions, blockers, next_action
+
+**Phase directories:**
+Scan `.planning/phases/` for:
+- Directories with a PLAN file but no SUMMARY file (incomplete execution)
+- Directories with a SUMMARY file but no VERIFICATION file (unverified phase, if `workflow.verifier` is enabled in `.planning/config.json`; if config.json cannot be read, assume verifier is disabled)
+
+**Quick task log:**
+If `.planning/quick/LOG.md` exists, read the last entry. Check if it has a non-terminal status (not `done`/`passed`).
+</load_artifacts>
+
+<present_status>
+Present a compact status to the user:
+
+```
+Project: [name from SPEC.md]
+Phase: [current] of [total] — [phase name]
+Completed: [N] phases done
+
+[If .continue-here.md exists:]
+Checkpoint found: [workflow type] — [phase name or task description]
+  Last paused: [timestamp from frontmatter]
+  Next action: [next_action section content]
+
+[If incomplete phase execution found:]
+Incomplete execution: Phase [N] has a PLAN but no SUMMARY
+
+[If incomplete quick task found:]
+Incomplete quick task: [description from LOG.md]
+```
+
+No ASCII art, no progress bars. Keep it scannable.
+</present_status>
+
+<determine_action>
+Evaluate in priority order and present the primary recommendation:
+
+**Checkpoint exists (`.continue-here.md`):**
+Route based on the `workflow` frontmatter:
+- `phase` — route to `/gsdd:execute` (or `/gsdd:plan`/`/gsdd:verify` based on checkpoint context)
+- `quick` — route to `/gsdd:quick` to complete the task
+- `generic` — present the next_action and let the user decide
+
+**Incomplete plan execution (PLAN without SUMMARY):**
+Route to `/gsdd:execute` for that phase.
+
+**Phase needs planning (next `[ ]` phase, no PLAN file exists):**
+Route to `/gsdd:plan` for that phase.
+
+**Phase needs verification (SUMMARY exists but no VERIFICATION):**
+Route to `/gsdd:verify` for that phase (only if `workflow.verifier` is enabled in config.json; if config.json cannot be read, assume verifier is disabled).
+
+**All phases complete (all `[x]`):**
+Route to `/gsdd:audit-milestone`.
+</determine_action>
+
+<present_options>
+Present a numbered list of actions based on the state analysis:
+
+```
+What would you like to do?
+
+1. [Primary action from above] (recommended)
+2. [Secondary action if applicable]
+3. Review ROADMAP.md
+4. Something else
+```
+
+**Quick-resume shortcut:** If the user says "continue", "go", or "resume" without further input, skip the options and execute the primary action directly.
+
+Wait for user selection.
+</present_options>
+
+<cleanup_checkpoint>
+Immediately after the user confirms their action selection (before routing to the target workflow):
+- If the user chose to resume from `.continue-here.md`, delete it now — before dispatching to the target workflow.
+- If the user chose a different action (not based on the checkpoint), leave `.continue-here.md` in place for a future resume.
+
+Deleting before routing ensures a failed or interrupted workflow does not leave a stale checkpoint that would mislead the next resume invocation.
+</cleanup_checkpoint>
+
+</process>
+
+<success_criteria>
+- [ ] Project state detected from disk artifacts (ROADMAP.md, SPEC.md, phase dirs)
+- [ ] `.continue-here.md` loaded if present
+- [ ] Incomplete work flagged (phase execution, quick tasks)
+- [ ] Compact status presented to user
+- [ ] Contextual next action determined (priority-ordered routing)
+- [ ] Options presented and user selection waited for
+- [ ] Checkpoint cleaned up after successful routing
+</success_criteria>
+
+<completion>
+After the user selects their action and the checkpoint is cleaned up, hand off to the selected workflow.
+
+Present to the user before dispatching:
+
+---
+**Resuming:** [selected action description]
+
+Consider clearing context before starting the next workflow for best results.
+---
+
+Then dispatch to the selected `/gsdd:*` workflow.
+</completion>

package/distilled/workflows/verify.md

@@ -0,0 +1,307 @@
+<role>
+You are the VERIFIER. Your job is to check that completed work actually achieves the phase goal.
+
+Core mindset: task completion does not equal goal achievement.
+A task can be "done" while the phase goal is still unfulfilled.
+
+You are skeptical by default. You verify claims, not promises.
+</role>
+
+<load_context>
+Before starting, read these files:
+1. `.planning/ROADMAP.md` - success criteria for the completed phase
+2. `.planning/phases/{plan_id}-PLAN.md` - what was planned
+3. `.planning/phases/{plan_id}-SUMMARY.md` - what execution claims was built
+4. `.planning/SPEC.md` - requirements and constraints for the phase
+5. The relevant codebase files - the code that was actually built
+
+Establish your verification basis (must-have sources, requirement scope, previous report status) before beginning code inspection. Do not jump to loose file reading until this basis is explicit.
+
+If a previous `.planning/phases/{phase_dir}/{phase_num}-VERIFICATION.md` exists, read it first and treat this as re-verification.
+</load_context>
+
+<scope_boundary>
+This workflow verifies a single phase.
+
+It does verify:
+- the phase goal
+- phase must-haves
+- artifacts, wiring, and requirement coverage within the phase
+- human-verification needs that cannot be checked programmatically
+
+It does not claim milestone-wide integration completeness.
+Cross-phase integration audit is handled by `distilled/workflows/audit-milestone.md` with its own integration-checker role.
+</scope_boundary>
+
+<reverification_mode>
+If a previous `VERIFICATION.md` exists:
+
+1. Load the previous `status`, `score`, and structured `gaps`.
+2. Focus full verification on previously failed items.
+3. Run quick regression checks on items that previously passed.
+4. Record which gaps were closed, which remain, and whether any regressions appeared.
+
+If no previous `VERIFICATION.md` exists, perform an initial verification pass.
+</reverification_mode>
+
+<must_haves>
+Establish what must be true before the phase can be called complete.
+
+Source priority:
+1. plan frontmatter `must_haves`
+2. roadmap success criteria
+3. goal-derived truths as a fallback
+
+For each truth:
+- identify the supporting artifacts
+- identify the key links that must work
+- decide whether it is programmatically verifiable or needs human review
+
+Also check for orphan requirements:
+- requirements expected by roadmap scope but claimed by no plan
+- requirements that no verified truth, artifact, or key link actually satisfies
+</must_haves>
+
+<verification_levels>
+Check every artifact at three levels. A common failure mode is a file that exists but is still a stub.
+
+### Level 1: Exists
+Does the artifact physically exist?
+
+```bash
+ls -la src/routes/users.ts
+ls -la tests/users.route.test.ts
+```
+
+### Level 2: Substantive
+Is the artifact real code, or a placeholder?
+
+Stub detection patterns:
+- empty function body
+- placeholder return such as `null`, `[]`, or `{}`
+- console-log-only handler
+- TODO, FIXME, HACK, or XXX markers
+- hardcoded fake data where live behavior is expected
+- ignored async result
+- pass-through event handler
+- commented-out implementation
+
+If any required artifact is a stub at Level 2, that supporting truth fails.
+
+### Level 3: Wired
+Is the artifact connected to the phase flow it is supposed to support?
+
+Examples:
+- component -> page or route
+- form -> handler
+- API route -> caller
+- service -> storage or dependency
+- state -> rendered output
+
+If an artifact exists and is substantive but not wired, mark it as unwired.
+</verification_levels>
+
+<key_link_checks>
+Check phase-local key links explicitly:
+
+| Link Type | What To Check |
+|-----------|----------------|
+| Component -> API | Request is made and response is used |
+| API -> storage | Query or write occurs and result is returned |
+| Form -> handler | Submit path triggers real work, not only `preventDefault()` |
+| State -> render | State is actually displayed or consumed |
+| Config -> runtime | Config is loaded where the behavior depends on it |
+
+Use direct file inspection and targeted grep. Do not inflate this into a milestone-wide audit.
+</key_link_checks>
+
+<anti_pattern_scan>
+Scan the phase output for anti-patterns:
+
+```bash
+grep -rn "TODO\\|FIXME\\|HACK\\|XXX" src/
+grep -rn "catch.*{}" src/
+grep -rn "console.log" src/ --include="*.ts" --include="*.js" | grep -v test | grep -v spec
+```
+
+Also look for:
+- placeholder components
+- static mock responses where live behavior is expected
+- orphaned files added in the phase but never referenced
+</anti_pattern_scan>
+
+<grouped_gaps>
+Before finalizing the report, group related failures by concern:
+- truth failures that share the same broken artifact or key link
+- requirement failures caused by the same missing implementation seam
+- human-verification items that belong to the same user-visible flow
+
+Do not return a flat symptom list when the same underlying breakage explains multiple findings.
+</grouped_gaps>
+
+<requirements_coverage>
+Requirements coverage is not optional bookkeeping. For each phase requirement:
+1. Collect the phase requirements from the strongest available planning source
+2. Restate each requirement in concrete implementation terms
+3. Map each requirement to the truths, artifacts, and key links that should satisfy it
+4. Report any requirement with missing or contradictory evidence
+5. Report any requirement expected by roadmap scope but claimed by no plan
+
+Orphaned requirements must be reported even if the overall phase otherwise looks strong.
+</requirements_coverage>
+
+<report_format>
+Write `.planning/phases/{phase_dir}/{phase_num}-VERIFICATION.md` with structured frontmatter first:
+
+```markdown
+---
+phase: 01-foundation
+verified: 2026-03-11T12:00:00Z
+status: gaps_found
+score: 2/3 must-haves verified
+re_verification:
+  previous_status: gaps_found
+  previous_score: 1/3
+  gaps_closed:
+    - "Users list renders returned data"
+  gaps_remaining:
+    - "Create flow still returns static placeholder data"
+  regressions: []
+gaps:
+  - truth: "Users can create a user from the page"
+    status: failed
+    reason: "Form submits, but route returns placeholder data"
+    artifacts:
+      - path: "src/routes/users.ts"
+        issue: "POST handler returns static object"
+    missing:
+      - "Persist submitted data before returning it"
+human_verification:
+  - test: "Open the users page and submit the form"
+    expected: "The new user appears in the rendered list"
+    why_human: "Visual form behavior still needs confirmation"
+---
+
+# Phase 01 Verification Report
+
+**Phase Goal:** [Goal from ROADMAP.md]
+**Verified:** [timestamp]
+**Status:** [passed | gaps_found | human_needed]
+**Re-verification:** [Yes or No]
+
+## Goal Achievement
+
+### Observable Truths
+
+| # | Truth | Status | Evidence |
+|---|-------|--------|----------|
+| 1 | [truth] | VERIFIED | [evidence] |
+
+### Artifact Verification
+
+| Artifact | Exists | Substantive | Wired | Notes |
+|----------|--------|-------------|-------|-------|
+
+### Key Link Verification
+
+| From | To | Via | Status | Notes |
+|------|----|-----|--------|-------|
+
+### Requirements Coverage
+
+| Requirement | Status | Evidence |
+|-------------|--------|----------|
+
+### Anti-Patterns
+
+| Pattern | Location | Severity | Impact |
+|---------|----------|----------|--------|
+
+### Human Verification Required
+
+[Only include if status is `human_needed`]
+
+### Gaps Summary
+
+[Only include if status is `gaps_found`]
+```
+
+Status rules:
+- use `passed` when all programmatic checks pass and no human-only checks remain
+- use `gaps_found` when implementation gaps or blocker failures exist
+- use `human_needed` when automated checks pass but one or more human-verification items remain
+
+Frontmatter guidance:
+- `phase`, `verified`, `status`, and `score` are the minimal report fields
+- when gaps or human checks exist, keep them machine-readable in frontmatter — do not collapse them into prose-only body text
+- keep `re_verification`, `gaps`, and `human_verification` structured when they materially help re-verification, gap closure, or explicit human handoff
+</report_format>
+
+<next_steps>
+Based on the verification result:
+
+### `passed`
+- phase is ready to move forward
+- communicate that the phase goal was verified successfully
+
+### `gaps_found`
+Present a focused recommendation:
+1. fix inline if the gaps are small and local
+2. re-plan if the gaps reveal a design problem
+3. explicitly accept the known issue only if the developer chooses to
+
+### `human_needed`
+- list the exact manual checks
+- state the expected outcome for each one
+- do not convert human-needed status into passed until those checks are acknowledged
+</next_steps>
+
+<persistence>
+MANDATORY: Write the verification report to disk.
+
+File: `.planning/phases/{phase_dir}/{phase_num}-VERIFICATION.md`
+
+This is non-negotiable. Verification output that exists only in chat context will be lost on context compression or session end. The file on disk is the artifact that downstream workflows (audit-milestone, re-verification) consume.
+
+If you cannot write the file (permissions, path issue), STOP and report the blocker to the user. Do NOT silently skip the write.
+</persistence>
+
+<success_criteria>
+Verification is done when all of these are true:
+
+- [ ] Previous `VERIFICATION.md` was checked first when it exists
+- [ ] Must-haves were established from plan frontmatter, roadmap, or goal fallback
+- [ ] Every relevant truth was individually checked
+- [ ] Every relevant artifact was checked at exists, substantive, and wired levels
+- [ ] Key links were checked at the phase scope
+- [ ] Requirements coverage was evaluated
+- [ ] Anti-pattern scan was run
+- [ ] `VERIFICATION.md` was written with structured frontmatter and a full report
+- [ ] Status is one of `passed`, `gaps_found`, or `human_needed`
+- [ ] The developer was informed of the result and recommended next step
+- [ ] Related failures grouped by concern, not returned as a flat symptom list
+- [ ] Requirements coverage chain completed (collect, restate, map, report, check orphans)
+</success_criteria>
+
+<completion>
+Report the verification result to the user, then present the next step:
+
+---
+**Completed:** Phase verification — created `.planning/phases/{phase_dir}/{phase_num}-VERIFICATION.md`.
+
+If status is `passed`:
+**Next step:** `/gsdd:progress` — check status and route to the next phase or milestone audit
+
+If status is `gaps_found`:
+**Next step:** `/gsdd:plan` — re-plan to close the identified gaps
+
+If status is `human_needed`:
+**Next step:** Complete the manual checks listed above, then run `/gsdd:verify` again
+
+Also available:
+- `/gsdd:execute` — fix gaps inline without re-planning (small fixes only)
+- `/gsdd:pause` — save context for later if stopping work
+
+Consider clearing context before starting the next workflow for best results.
+---
+</completion>

package/package.json

@@ -0,0 +1,45 @@
+{
+  "name": "gsdd-cli",
+  "version": "0.1.0",
+  "description": "GSDD — a portable, spec-driven development kernel for AI coding agents. Works with Claude Code, Codex CLI, OpenCode, Cursor, Copilot, and Gemini CLI.",
+  "type": "module",
+  "bin": {
+    "gsdd": "./bin/gsdd.mjs"
+  },
+  "scripts": {
+    "test:gsdd": "node tests/gsdd.init.test.cjs && node tests/gsdd.models.test.cjs && node tests/gsdd.manifest.test.cjs && node tests/gsdd.plan.adapters.test.cjs && node tests/gsdd.audit-milestone.test.cjs && node tests/gsdd.invariants.test.cjs && node tests/gsdd.guards.test.cjs && node tests/gsdd.health.test.cjs && node tests/gsdd.scenarios.test.cjs"
+  },
+  "files": [
+    "bin/adapters/",
+    "bin/lib/",
+    "bin/gsdd.mjs",
+    "distilled/",
+    "agents/*.md",
+    "agents/README.md"
+  ],
+  "keywords": [
+    "gsdd",
+    "gsd-distilled",
+    "claude",
+    "claude-code",
+    "ai",
+    "meta-prompting",
+    "context-engineering",
+    "coding-agent",
+    "spec-driven-development",
+    "sdd",
+    "workflow",
+    "gemini",
+    "gemini-cli",
+    "cursor",
+    "codex",
+    "opencode",
+    "copilot"
+  ],
+  "author": "PatrickSys",
+  "license": "MIT",
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/PatrickSys/get-shit-done-distilled"
+  }
+}