You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been experimenting with an alternative encoding format for GSD-style skill definitions and wanted to share some measurements.
The question: Can the behavioral rules in GSD phase commands be expressed in a more compact structured format while preserving equivalent constraints?
What I tested:
I took three GSD phase command files (discuss-phase.md, plan-phase.md, execute-phase.md) and rewrote the behavioral rules using a compact structured syntax:
Important caveat: GSD commands are thin wrappers that load workflow files at runtime. These numbers only measure the command file layer, not the full workflow prompt. The compact versions are behavioral subsets, not equivalent rewrites of the complete GSD command contract.
Where it helps and where it doesn't:
The savings come from skills with heavy XML structure, YAML frontmatter, and runtime notes. For thin wrapper skills (like ship.md at 170 tokens), the compact format is actually larger because it encodes behavioral constraints that the original delegates to the workflow file.
This is not a replacement for GSD. GSD handles workflow orchestration (discuss, plan, execute, verify, ship). This is about whether the behavioral rule encoding inside skills could be denser.
I have a repo with the comparison fixtures and a reproducible benchmark script if anyone's interested in looking at the data.
Curious if others have experimented with skill prompt compression approaches, or if the GSD team has considered alternative formats for the behavioral layer.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
I've been experimenting with an alternative encoding format for GSD-style skill definitions and wanted to share some measurements.
The question: Can the behavioral rules in GSD phase commands be expressed in a more compact structured format while preserving equivalent constraints?
What I tested:
I took three GSD phase command files (discuss-phase.md, plan-phase.md, execute-phase.md) and rewrote the behavioral rules using a compact structured syntax:
T:= positive rule (always do this)A:= anti-pattern (never do this)Token measurements (cl100k_base estimation):
Important caveat: GSD commands are thin wrappers that load workflow files at runtime. These numbers only measure the command file layer, not the full workflow prompt. The compact versions are behavioral subsets, not equivalent rewrites of the complete GSD command contract.
Where it helps and where it doesn't:
The savings come from skills with heavy XML structure, YAML frontmatter, and runtime notes. For thin wrapper skills (like ship.md at 170 tokens), the compact format is actually larger because it encodes behavioral constraints that the original delegates to the workflow file.
This is not a replacement for GSD. GSD handles workflow orchestration (discuss, plan, execute, verify, ship). This is about whether the behavioral rule encoding inside skills could be denser.
I have a repo with the comparison fixtures and a reproducible benchmark script if anyone's interested in looking at the data.
Curious if others have experimented with skill prompt compression approaches, or if the GSD team has considered alternative formats for the behavioral layer.
Beta Was this translation helpful? Give feedback.
All reactions