* chore(#604): rename get-shit-done/ runtime directory to gsd-core/ Renames the installed runtime directory `get-shit-done/` to `gsd-core/` so the on-disk name matches the package (`@opengsd/gsd-core`), repo, and binary (`gsd-tools`). The npm package name and binary are unchanged; npx/npm consumers are unaffected. Mechanical (bulk, ~90% of the diff): - `git mv get-shit-done gsd-core` - Swept path/identifier references across the repo via `perl -pe 's/get-shit-done(?!-\w)/gsd-core/g'`. The negative lookahead preserves the five legitimate slug variants that are NOT the directory: get-shit-done-{OLD,cc,classic,cli,redux} (old package/repo names). - Build/manifest wiring: package.json (bin, files, coverage globs), tsconfig.build.json (outDir), ~86 .gitignore build-output entries, stryker.config.mjs, scan-ignore files, install.js path strings. - Frozen (not rewritten): CHANGELOG.md history; translated docs (README.<locale>.md and docs/{ja-JP,ko-KR,pt-BR,zh-CN}/). New logic (review here): - src/installer-migrations/003-rename-get-shit-done-to-gsd-core.cts: a proper ADR-0008 installer migration. On upgrade it walks the legacy `~/.claude/get-shit-done/` tree, classifies each file via the prior install manifest, and emits remove-managed / backup-and-remove for managed files while PRESERVING unknown user-added files. Symlink-safe (skips a symlinked root and symlinked entries; bounds-checks every path under configDir). The framework rolls back on install failure. Emptied dirs may remain (framework has no recursive dir-removal primitive) — documented. - scripts/lint-legacy-dir-name.cjs: CI regression guard forbidding the bare `get-shit-done` directory token (split token to avoid self-match; case- insensitive; `(?!-\w)` lookahead allows the slug variants; allowlists CHANGELOG, translated docs, and `gsd-allow-legacy-name` marker lines). Wired into the lint-tests CI job. - Restored scripts/lint-package-identity-drift.cjs detection regexes (the mechanical sweep had wrongly rewritten the old-name patterns it exists to detect) and marked them as intentional legacy references. - TDD tests for the migration and the guard; do.md slash-command guard regex tightened so a `/gsd-core/bin` path segment is not mistaken for a command; changeset + docs/installer-migrations.md row added. Breaking: the installed runtime path moves `~/.claude/get-shit-done/` -> `~/.claude/gsd-core/`. Migration 003 removes the stale legacy dir's managed files (preserving user files) on upgrade. Users with custom hooks/configs hardcoding the old path must update them. Closes #604 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(#604): unsweep pending changesets + allowlist injection-example docs CI fixes for the rename PR: - Do not sweep pending .changeset/*.md (ephemeral release-note fragments, like CHANGELOG); reverted those body edits so 5 pre-existing malformed fragments (missing type/pr) no longer enter the PR diff and trip docs-lint. Allowlisted .changeset/ in the legacy-name guard accordingly. - Allowlisted TEST-EXAMPLES.md and docs/explanation/security-model.md in prompt-injection-scan.sh: they contain intentional injection examples / security-model prose; the path-reference rewrites are kept. CodeQL alerts on this PR are pre-existing (alert lines unchanged by this PR; none in the new migration/guard) and are out of scope for the rename. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(#604): resolve CodeQL alerts surfaced on this PR The rename diff touched files carrying pre-existing CodeQL findings; per the no-pre-existing-dismissal rule, fixing every surfaced alert rather than waving them off. All behavior-preserving: - scripts/ci-test-scope.cjs: build the config-path match from string .includes() instead of a RegExp over an arg-derived value (js/regex-injection). - src/profile-output.cts: escape backslashes before pipe-escaping desc/safeName so the table-cell escape is complete (js/incomplete-sanitization). - tests/{bug-2643,bug-2808,docs-parity-live-registry}: two-pass HTML-comment strip so a bare/unclosed `<!--` cannot survive (js/incomplete-multi-character-sanitization). - tests/inline-plan-threshold: drop the no-op `\s`->`\s` identity replace, keep the meaningful POSIX-class conversion (js/identity-replacement). Verified: build:lib green; the touched test files + ci-test-scope + profile-output suites pass; lint:legacy-name clean. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(#604): correctly resolve remaining CodeQL alerts (regex-injection + sanitization) The prior commit's fixes for two alerts were ineffective: - ci-test-scope.cjs js/regex-injection: the alert is the CLI-arg-derived `file` reaching static regex `.test(file)` calls (not the config rule). Removed ALL regex over file/t — startsWith/includes/=== string checks + an isWindowsHint helper — so there is no regex sink for the tainted value. - js/incomplete-multi-character-sanitization (3 test files): a single `.replace(/<!--...-->/g,'')` can let `<!--` re-form. Replaced with a fixpoint loop (replace until stable) plus a final bare-opener strip. Verified: no regex over file/t remains; ci-test-scope + the 3 test suites pass; lint:legacy-name clean. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(#604): make ci-test-scope + comment-strippers regex-free to clear CodeQL CodeQL flags the regex PATTERNS syntactically (regex-injection on the --files arg split; incomplete-multi-character-sanitization on the <!--...--> replace), so loop fixes do not satisfy it. Made these paths regex-free: - ci-test-scope.cjs splitFiles: char-by-char separator tokenizer (no /[,\\s]+/). - 3 test files: indexOf/slice HTML-comment stripper (no .replace(/<!--/)). Behavior preserved; ci-test-scope + the 3 suites pass; guard clean. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(#604): unblock security base64 scan on the large rename diff The security job hit its 10m timeout: base64-scan.sh choked on the binary test fixture tests/feat-3594-parser-property-style.test.cjs (embedded NUL/ non-UTF8 bytes -> thousands of bogus blobs + "ignored null byte" warnings), and the ~800-file rename diff is slow to scan regardless. - scripts/base64-scan.sh: skip binary-by-content files (grep -Iq .) — they can't carry base64-obfuscated *text* and feeding NUL bytes through the per-line scanner is pathologically slow. collect_files already filtered binary *extensions*; this catches binary *content* in text extensions. - .github/workflows/security-scan.yml: raise the security job timeout 10m->30m to accommodate very large diffs (the scan itself is unchanged). Verified locally: scan skips the fixture, 0 "ignored null byte" warnings, 0 findings, exit 0. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(#604): sweep get-shit-done refs introduced by merging next The branch was updated with next (#614/#384/#618 etc.), which reference the get-shit-done/ dir (still named that on next). Swept the stale references in the merged files to gsd-core so the rename stays consistent and lint:legacy-name passes: - commands/gsd/discuss-phase.md (runtime-launcher shim paths) - src/core.cts (getAgentsDir layout comments) - tests/bug-384-agents-runtime-aware.test.cjs (require path to runtime lib) Verified: guard 0 violations; build green. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(#604): exclude gsd-core/ path segments from bug-3683 command cross-ref invariant The #614 runtime-launcher shim added to discuss-phase.md references `${_GSD_RUNTIME_ROOT}/gsd-core/bin/...`. bug-3683's REF_PATTERN excluded path-y refs only via lookbehind, but `}` precedes `/gsd-core/` in the shim, so it mis-read the directory path as a dangling `/gsd-core` command ref (same class as the #604 bug-2954 fix). Added a trailing `(?![\w-]*\/)` so `/gsd-<x>/...` path segments are not treated as slash-command references. Verified locally on BOTH platforms before pushing: - mac (node 26) full suite: 0 failures - gsd-test-runner (linux, node22 image) full suite: 0 failures - bug-3683 + bug-2954 pass. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(#604): lazily resolve findProjectRoot in gsd-tools (harden flaky CI) CI intermittently failed state.test's gsd-tools subprocess with "findProjectRoot is not a function" (flip-flopping across legs; not reproducible on mac full suite, gsd-test linux full suite, test:unit, or state.test x8). findProjectRoot is a re-export from core.cjs (sourced from project-root.cjs); binding it via destructure at module-load can be undefined under a load-ordering edge. Resolve it lazily at call time via a small wrapper so the lookup happens after core.cjs is fully initialized. Verified green on BOTH platforms before pushing: - mac (node 26) full suite: 0 failures - gsd-test-runner (linux, node22) full suite: 0 failures - state.test.cjs: 106/106; gsd-tools loads cleanly. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(#604): allowlist verification-patterns.md placeholder examples in secret scan The rename git-mv'd references/verification-patterns.md into gsd-core/, pulling it into the secret-scan diff. It documents stub/placeholder RED-FLAG env-var examples (illustrative Stripe test-key / database-URL / API-key placeholders) — not real credentials. Added it to .secretscanignore with the strict annotation, mirroring the existing gsd-core/workflows/plan-phase.md exception. Verified locally: secret-scan-lint --strict OK; secret-scan --diff origin/next exits 0 with 0 findings. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
14 KiB
Grok Build + GSD Compatibility & Local Multi-Runtime Sync (May 2026)
Date: 2026-05-16
Status: Discussion active on closed issue. Awaiting maintainer response.
Purpose of this document: Serve as the primary context file for future Grok (or other) agent sessions started inside this repository (/home/cristian/bum/gsd-core) so they can work on local Grok Build support and improved synchronization across multiple AI coding harnesses.
1. Executive Summary & Goals
Goal: Achieve reliable, first-class GSD support when using Grok Build, while maintaining excellent compatibility and low-friction synchronization across the four runtimes the author uses daily:
- Grok Build (current primary TUI)
- Claude Code
- Gemini CLI
- Codex
Currently, Grok Build is only supported via its Claude compatibility layer. This creates daily friction in paths, skill discovery, command surfaces, hooks, grok inspect output, and mental models.
Long-term vision:
- Run GSD natively and cleanly inside Grok Build.
- Maintain a single source of truth in this repository.
- Have a robust, automated (or semi-automated) sync mechanism that deploys adapted skills/agents/hooks to all four runtime environments (
~/.agents/,~/.claude/,~/.grok/, Gemini location, Codex location). - Keep the work clean enough that high-quality pieces can eventually be contributed upstream.
2. Current Multi-Runtime Setup (as of May 2026)
Development Source (Single Source of Truth)
- Path:
/home/cristian/bum/gsd-core(this repo — your working fork ofopen-gsd/gsd-core)
Installed Locations
~/.agents/gsd-core/— Core workflows, references, templates,gsd-tools.cjs,bin/~/.agents/skills/gsd-*— ~125 skills (heavily GSD + many large reference skills likeuserinterface-wiki,react-best-practices, etc.)~/.agents/agents/— 22 GSD sub-agents (with.md+.toml)~/.claude/skills/gsd-*+~/.claude/gsd-core/+~/.claude/agents/— Parallel Claude Code install (~208 skills total)~/.grok/skills/— Mostly empty (only the 7 official bundled Grok skills)~/.grok/— Not yet properly used by GSD
Existing Sync Tooling
gsd-sync-skillsskill exists in~/.agents/skills/gsd-sync-skills/- Its stated purpose: "Sync managed GSD skills across runtime roots so multi-runtime users stay aligned after an update"
- Currently uses a combination of manual processes + this skill.
Codex-Style Adaptations Already in Use
- Many
gsd-*skills in~/.agents/skills/contain a<codex_skill_adapter>section at the top. - This adapter translates Claude Code patterns (
AskUserQuestion,Task()) into Codex/Grok-compatible ones (request_user_input,spawn_agent). - This pattern was developed because Grok Build / Codex use a different skill invocation and subagent model than Claude Code.
3. History & Prior Art
Previous Upstream Attempt (May 2026)
- Issue #3603: "Add Grok Build (
--grok) as a first-class runtime" - PR #3604 (by
lordgraysith): Very large, high-quality implementation attempt.
The PR included:
- Full
--grokinstaller support - Conversion functions (
convertClaudeToGrokMarkdown,convertClaudeCommandToGrokSkill,convertClaudeAgentToGrokAgent) - JSON hook manifest generation for Grok
- Model catalog entries for Grok models
GROK_CONFIG_DIRsupport- Extensive tests and documentation
- A complete planning folder:
docs/grok-build-support/containing 7 detailed documents:- 01-runtime-detection-and-config.md
- 02-installer-logic.md
- 03-model-catalog-and-profiles.md
- 04-skills-agents-hooks-conversion.md
- 05-documentation-and-user-experience.md
- 06-testing-strategy.md
- 07-phased-implementation-and-rollout.md
Outcome: Both issue and PR were closed the next day by trek-e as not_planned.
Maintainer’s Position (Critical Context)
From trek-e’s detailed closing comment on #3603:
- Biggest blockers right now:
- Grok Build is extremely new (launched May 14, 2026) and still in early beta. Hook events and config surface are unstable.
- Strong desire to protect GSD’s reputation for stability ("vibe coded piece of junk" reputation risk).
- Recent painful experience with Codex making breaking changes shortly after GSD stabilized something.
- Price was clarified as low priority ("honestly price is probably the lowest of the factors").
- Claude-compat already works, so native support is seen as polish rather than a must-have.
- Process concern: Implementation was done before the issue was properly approved.
- Recommendation: Revisit once Grok Build has stabilized (versioned config surface held for at least one minor release) and is reachable on a more realistic solo-dev price tier.
Important: The 7 planning documents in docs/grok-build-support/ remain excellent reference material even if the code from that PR is not merged.
4. Recommended Work Plan for Future Grok Sessions in This Repo
When a new Grok session is started inside /home/cristian/bum/gsd-core, it should follow something like this phased approach:
Phase 0 — Orientation (Current Session Context)
- Read this document fully.
- Read the 7 files in
docs/grok-build-support/. - Explore the current local multi-runtime setup (see Section 2 above).
- Understand the existing
gsd-sync-skillsskill and any Codex adapters already present.
Phase 1 — Audit Current State
- Map exactly what is installed where across
~/.agents/,~/.claude/,~/.grok/, and Gemini/Codex locations. - Identify duplication, drift, and friction points when using GSD in Grok Build today.
- Run
grok inspectand analyze what it shows for GSD skills. - Document gaps specific to Grok Build (command surface, hooks,
grok inspectcleanliness, agent spawning, etc.).
Phase 2 — Study Prior Art
- Deeply study the conversion specifications in
docs/grok-build-support/04-skills-agents-hooks-conversion.md. - Understand what a proper Grok
SKILL.mdshould look like (frontmatter, description style, runtime hints). - Understand Grok hook JSON manifest requirements.
- Review how the previous PR handled model catalog and runtime homes.
- Look for any existing local experiments or partial adapters in this fork.
Phase 3 — Design Local Grok Adapter (MVP)
Design a practical local solution that works for this user’s four-runtime reality, not necessarily a full upstream --grok installer yet.
Possible components:
- A local Grok conversion layer (or extension of existing Codex adapters).
- Proper
gsd-*skills under~/.grok/skills/with correct Grok frontmatter +codex_skill_adaptersections where needed. - Grok-compatible agent definitions (
.md+ any required TOML/config). - JSON hook manifests in
~/.grok/hooks/. - Updates to the sync mechanism (
gsd-sync-skillsor a newgsd-multi-runtime-synctool) so one source can deploy cleanly to all four targets.
Key principle: Prefer extending/improving the existing sync tooling rather than creating yet another parallel install path.
Phase 4 — Implementation & Testing
- Implement the MVP Grok adapter in this local fork.
- Create or enhance sync logic.
- Test end-to-end inside an actual Grok Build session:
grok inspectcleanliness- Command discovery (
/gsd-*or Grok-native form) - Agent spawning
- Hook firing
- Full
gsd-new-project→gsd-progress→gsd-execute-phaseflow
- Verify no regression in Claude / Gemini / Codex usage.
Phase 5 — Documentation & Future Upstream Path
- Update this discussion note and any relevant docs in the repo.
- Document the local sync architecture clearly.
- Identify which pieces of the local solution would be good candidates for upstream contribution later (when Grok Build is more mature).
5. Key Files & Areas to Study
In this repo:
docs/grok-build-support/(all 7 documents — highest priority)bin/install.js(installer logic, especially runtime handling and conversion functions)gsd-core/bin/lib/runtime-homes.cjsgsd-core/bin/lib/shell-command-projection.cjs(hook projection)sdk/shared/model-catalog.json- Existing
gsd-sync-skillsskill (in~/.agents/skills/gsd-sync-skills/) - Any skills that already contain
<codex_skill_adapter>sections (study the pattern)
External / Prior Art:
- The original PR #3604 (study the actual conversion code if accessible via the author’s fork)
- Grok Build documentation on skill format, agent format, and hook JSON manifests (as of the session date)
6. How to Test Grok Build Compatibility Locally
Useful commands and checks when working on this:
grok inspect(andgrok inspect --json) — check skill discovery, sources, and token counts.grokTUI inside a real project that uses GSD.- Full workflow test:
/gsd-progress,/gsd-discuss-phase,/gsd-plan-phase,/gsd-execute-phase, etc. - Verify hooks fire correctly via Grok’s JSON hook system.
- Check that subagents (the 22 GSD agents in
~/.agents/agents/) can be spawned from Grok.
7. Sync Strategy Principles (for Multi-Runtime)
When designing improvements to sync:
- Single source of truth = this repository (
/home/cristian/bum/gsd-core). - Runtime-specific transformations should be as declarative and maintainable as possible.
- The
<codex_skill_adapter>pattern is already proven for Grok/Codex — extend it rather than reinvent. - Prefer generating the runtime-specific artifacts during sync rather than maintaining four separate copies.
- Make it easy to add a fifth runtime later if needed.
8. Open Questions & Decisions to Make (for Future Sessions)
- Should we aim for a full local
--grokinstaller equivalent, or just excellent skill/agent/hook generation + sync? - How much of the previous PR’s conversion logic can/should be reused locally?
- What is the right balance between “make Grok work great for me now” vs “keep it clean for potential upstream contribution”?
- Should the sync tool become a first-class GSD skill (
gsd-multi-runtime-syncor similar)? - How do we handle model profiles and agent routing differences for Grok models?
9. How to Resume This Work
When starting a new Grok session in this repository, begin by reading:
- This file:
docs/discussions/grok-build-support-2026-05.md - All files in
docs/grok-build-support/ - The existing
gsd-sync-skillsskill
Then follow the phased plan in Section 4.
Last updated: 2026-05-16 (by Grok, in this session)
10. Progress — May 2026 Session (Current)
Audit Findings (Phase 1)
- Version drift confirmed:
~/.agents/gsd-core/(Grok Build primary) was on 1.38.4;~/.claude/on 1.42.2;~/.codex/and~/.gemini/on 1.41.2. ~/.agents/hooks/was empty (no hooks active for Grok Build sessions).grok inspectsuccessfully discovers 80+gsd-*skills via the~/.agents/skills/layout + the existing<codex_skill_adapter>blocks.- No
grokoragentsruntime existed in installer or sync logic. ~/.grok/itself contains only the 7 official bundled skills; GSD lives entirely in the shared~/.agents/layout.
Immediate Actions Taken
- Engine drift fixed ASAP: Backed up old
~/.agents/gsd-core/to.backup-1.38.4/, then rsynced the current sourcegsd-core/tree into~/.agents/gsd-core/. Now running the latest from this repo (v1.50.0-canary.0). New modules (active-workstream-store, adr-parser, etc.) and updated workflows are live for Grok Build sessions. - First-class 'grok' runtime added (pragmatic choice: maps to
~/.agents/):- gsd-core/bin/lib/runtime-homes.cjs: Added
grokcase (honorsGROK_AGENTS_HOMEenv, defaults to~/.agents). - bin/install.js: Added
--grokflag,hasGrok,getDirName('grok') → '.agents',getGlobalDir('grok'),getConfigDirFromHome, inclusion in--alland help text. Reuses existing Codex conversion logic (skill adapters + agent .toml generation) because Grok Build uses the same invocation model. - gsd-core/workflows/sync-skills.md: Added
grokto supported runtimes and the--to alllist.
- gsd-core/bin/lib/runtime-homes.cjs: Added
- Verified:
node bin/install.js --skills-root grokcorrectly returns~/.agents/skills.
Next Steps (for follow-up sessions)
- Full
gsd install --grok --globalend-to-end (hook projection, agent .toml generation with correct sandbox, skill wrapping with adapters, statusline, etc.). Currently the flag is recognized but some codex-specific install branches may need|| runtime === 'grok'. - Run
gsd update --sync --from claude --to grok --apply(or--from grok --to claude) once the runtime is fully wired, to keep the 4 harnesses in sync without manual rsync. - Slim the
<codex_skill_adapter>blocks (currently ~60 lines inlined in every gsd-* SKILL.md). Options: extract detailed mapping to a shared@reference/codex-skill-adapter.mdthat skills include, or make the adapter header shorter/optional for lowergrok inspecttoken cost. - Investigate Grok Build native hook support (JSON manifests under
~/.grok/hooks/vs the shell hooks in~/.agents/hooks/). - Update
grok inspectoutput cleanliness (remove "unknown tool prefix: Skill(gsd:*)" warnings if possible via settings or skill manifest). - Consider whether to also populate a native
~/.grok/skills/gsd-*tree in addition to the working.agentslayout.
This session delivered working grok runtime resolution + immediate version parity for the user's primary Grok Build harness.
Last updated: 2026-05-16 (by Grok, in this session)
This document is intended to be living. Update it as the local Grok Build work progresses.