Knowledge Vault

Custom GSD to GAS Implementation Strategy

2 min read

Custom GSD to GAS Implementation Strategy

Overview

  • Project: Aloysius Productions
  • Status: Active
  • Result: Framework established, ongoing implementation

Context

Evaluation of porting features from the Get-Shit-Done (GSD) workflow system into the custom GAS (Gloriously Awesome System) fork. Previous attempts at cherry-picking features resulted in silent failures due to dependency drift and state machine incompatibilities.

Key Findings

The “Clean Room” Approach

Porting features from a complex modular system requires understanding the feature’s full dependency graph before copying code:

  1. Ghost Repo Audit — Clone fresh GSD, use grep -r to trace every mention of the target feature across commands, agents, templates, and registration files
  2. Isolation Test — Verify the feature works in native GSD with a dummy project before porting
  3. Structural Alignment — The most critical step; check STATE.md key compatibility, dependency injection for sub-agents, and hook synchronization
  4. Dry Run — Hardcode missing variables to force success, then incrementally replace with GAS equivalents

Root Cause of Past Failures

  • STATE.md key mismatches — GSD expects specific keys (e.g., milestone_version) that GAS may use different names for
  • Missing sub-agent dependencies — Features often call other GSD agents (planner, executor) that must be ported or aliased
  • Hook synchronization gaps — Post-v1.5.23, GSD features use hooks for status lines that need settings.json updates

GSD Architecture (for porting reference)

ComponentLocationPurpose
Entry pointscommands/gsd/Command registration
Logic/promptingagents/Agent definitions
Output structurestemplates/Template files
Registrationbin/install.jsPackage manifest

Shielding Against Future Drift

  • Version-stamp ported files: // Ported from GSD v1.9.4 - [Feature Name]
  • Update GAS manifest to include new files
  • Create validation command to verify all required files exist

Actionable Takeaways

  1. Never copy code directly — always trace the dependency graph first
  2. State machine compatibility is the silent killer of feature ports
  3. Test in isolation before integration
  4. Version-lock ported components to prevent drift

Graph View

Backlinks