41dc9bc060
* fix(graphify): run /gsd-graphify build inline instead of spawning a sub-agent Closes #3166 graphify v0.7+ split the build into a fast AST-extraction phase (cached) followed by a separate clustering + report-write phase. The cached extraction phase survived sub-agent isolation, but the post-extraction phase was SIGTERM'd when the agent exited, leaving the cache populated and no graph.json / graph.html / GRAPH_REPORT.md artifacts written to .planning/graphs/. The skill now runs `graphify update .`, the three artifact copies, the snapshot, and the status report as a single foreground Bash call so the entire pipeline survives to completion. The CLI's `graphify build` pre-flight still returns `action: "spawn_agent"` so external callers and existing tests in tests/graphify.test.cjs keep working. Regression test (tests/bug-3166-graphify-inline-build.test.cjs) parses the skill's YAML frontmatter and body structurally to fence against re-introducing Task to allowed-tools or `Task(` invocation syntax — a future edit cannot regress the fix without tripping the fence. Verified against safishamsi/graphify v0.7.0–v0.7.8 release notes: `graphify update .` invocation and output filenames are unchanged in v0.7+; no GSD-side interface migration is required. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(test): drop yaml dep from bug-3166 fence — replace with inline parser CI failed with MODULE_NOT_FOUND on `require('yaml')` — the package resolved locally as a transitive dep but isn't declared in package.json. The project pattern (see tests/helpers.cjs `parseFrontmatter`) deliberately avoids pulling in yaml/js-yaml. Replace with a narrow inline parser that handles the scalar + block-list subset used in this skill's frontmatter. Verified the fence still trips when Task is reintroduced to allowed-tools. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(test): parse fenced blocks structurally for #3166 fence Address CodeRabbit nitpicks on PR #3169: the body assertions used raw markdown text regex (\bTask\s*\(/, /graphify\s+update\s+\./) which violates the project's "parse, never grep" testing convention and risks false-positives on prose. Replace with extractFencedBlocks(body) which returns [{lang, content}, ...] tuples per markdown code fence. Body assertions now run against parsed blocks: - "no fenced code block contains Task(" → deepEqual offending blocks to [] (vs. regex on raw body) - "a bash block invokes graphify update . / build snapshot" → filter to lang === 'bash', then substring-check inside parsed content Substring checks within already-parsed fenced content are structural — prose mentioning the word "Task" can no longer false-positive, and a future prose reference to graphify cannot satisfy the positive assertions either. The frontmatter side already used a parser; both sides now match. Verified: re-introducing Task( inside a code fence still trips the assertion. Full suite 7499/7499 passes. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(test): rename readFileSync-bound var to satisfy lint-no-source-grep The structural-parse refactor introduced `b.content.includes(...)` calls on parsed fenced-block records, but `loadSkill()` had also bound `const content = fs.readFileSync(...)` for the markdown text. The lint-no-source-grep regex scanner cannot distinguish scopes — it sees "variable `content` is bound from readFileSync" and "`content.includes` is called" and flags it as a source-grep test, even though the two `content`s are different lexical entities. Rename the readFileSync-bound local to `markdown`. Now `b.content` is unambiguously a property access on a parsed-block record. Lint passes (0 violations across 401 test files); behavior unchanged (4/4 tests still pass, including the negative regression case). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(test): tighten snapshot assertion to gsd-tools.cjs prefix CodeRabbit nitpick on bug-3166 fence: the snapshot bash assertion accepted any 'graphify build snapshot' substring. Tighten to require it follows 'gsd-tools.cjs', matching the actual fenced invocation in commands/gsd/graphify.md (which uses node "$HOME/.../gsd-tools.cjs" graphify build snapshot — note the closing quote, so a literal 'gsd-tools graphify build snapshot' substring would not match). --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
GSD Documentation
Comprehensive documentation for the Get Shit Done (GSD) framework — a meta-prompting, context engineering, and spec-driven development system for AI coding agents.
Language versions: English · Português (pt-BR) · 日本語 · 简体中文
Documentation Index
| Document | Audience | Description |
|---|---|---|
| Architecture | Contributors, advanced users | System architecture, agent model, data flow, and internal design |
| Feature Reference | All users | Feature narratives and requirements for released features (see CHANGELOG for latest additions) |
| Command Reference | All users | Stable commands with syntax, flags, options, and examples |
| Configuration Reference | All users | Full config schema, workflow toggles, model profiles, git branching |
| CLI Tools Reference | Contributors, agent authors | gsd-tools.cjs programmatic API for workflows and agents |
| Agent Reference | Contributors, advanced users | Role cards for primary agents — roles, tools, spawn patterns (the agents/ filesystem is authoritative) |
| User Guide | All users | Workflow walkthroughs, troubleshooting, and recovery |
| Issue-Driven Orchestration | All users | Recipe for driving GSD from a tracker issue (GitHub / Linear / Jira) using existing primitives — no new commands or daemon |
| Context Monitor | All users | Context window monitoring hook architecture |
| Discuss Mode | All users | Assumptions vs interview mode for discuss-phase |
Quick Links
- What's new: see CHANGELOG for current release notes, and upstream README for release highlights
- Getting started: README → install →
/gsd-new-project - Full workflow walkthrough: User Guide
- All commands at a glance: Command Reference
- Configuring GSD: Configuration Reference
- How the system works internally: Architecture
- Contributing or extending: CLI Tools Reference + Agent Reference