Docs request: Tutorial on extending skills with new customization dimensions

[howardpen9]

What I'm asking for

A tutorial or guide that walks through how to add a new customization axis to an existing gstack skill — not just locale, but any dimension: verbosity level, user role, project type, tone, output format, etc.

Background

Right now gstack skills are mostly fixed-behavior prompts. Issue #481 shows that people are already forking skills to add locale awareness, but there's no shared playbook for how to approach this kind of extension cleanly.

The questions I keep running into:

• Where should the customization value live? (gstack-config, env var, per-project config, frontmatter?)
• How should a skill read it without breaking when it's missing?
• What's the pattern for keeping the default behavior intact while allowing overrides?
• Is there a recommended way to document new config keys so users know what's available?

Why this matters

Once contributors know the approved pattern, multiple customizations (locale, verbosity, persona, etc.) can coexist without stepping on each other. Without a pattern, everyone solves it differently and skills become hard to maintain.

What a good tutorial would cover

1. Pick one concrete example (locale is fine) and walk through it end-to-end
2. Show where config values are stored and how to read them defensively in a skill
3. Show how to keep English / default behavior as the fallback
4. Note any gotchas (e.g. zsh vs bash compatibility, reading config in the preamble block)

Happy to help draft or review if there's interest.

[yasuhirofujii-medley]

Thanks, this is a really helpful reframing.

My original goal started with locale support for slash commands, but I agree the more useful upstream direction is probably a general pattern for adding customization dimensions while preserving default behavior.

What I have been prototyping for locale already touches several of the same questions you listed: where the customization value should live, how to read it safely, how to preserve English/default fallback, and how to keep the structure extensible for future dimensions.

If useful, I can try to reduce my current work into a smaller proof of concept plus some notes on the general pattern, with locale as one concrete example.