Bashly Skill
Use this workflow to produce or update Bashly CLIs.
Follow Workflow
- Confirm project mode.
- Detect whether the user has an existing Bashly project or needs a new one. - For existing projects, inspect current Bashly settings and source folder layout before editing. - Use references/bashly-workflow.md to locate the effective bashly.yml when defaults are overridden. - When users need non-default paths, add or update settings with bashly add settings.
- Define CLI contract before editing files.
- Capture command groups, subcommands, required args, optional args, and flags. - Confirm naming and UX details (short flags, long flags, help text, defaults, required constraints).
- Author or update
bashly.yml.
- For new projects, initialize with bashly init or bashly init --minimal based on requested scope. - Prefer incremental edits to preserve compatibility in existing projects. - Keep descriptions concise and user-facing. - Keep command trees predictable and avoid unnecessary nesting.
- Implement command behavior in Bashly partials.
- Resolve the active source folder first (default src, or overridden in settings/env). - Create or update command and shared partial files in that source folder. - Keep business logic in partials so regeneration remains safe and repeatable.
- Generate CLI files with Bashly.
- Run the Bashly generation command from the project root. - If generation is unavailable in the environment, still produce valid bashly.yml and list the exact generation command for the user.
- Validate behavior.
- Check shell syntax for generated scripts when possible. - Exercise representative command paths (--help, one success path, one argument/flag error path).
- Document what changed.
- Summarize command tree changes and any backward-incompatible flag/argument changes. - Summarize which partial files were added/updated in the source folder. - Provide quick usage examples for the most important commands.
Use Bundled Resources
- Read
references/bashly-workflow.mdfor command design heuristics, common Bashly operations, and troubleshooting. - Use the icon asset in
assets/for skill metadata/UI integration when relevant.
Use Online Sources
- When internet access is available, verify syntax and options against official Bashly docs before finalizing changes.
- Prioritize sources in this order: Bashly docs (
bashly.dev), official examples, thenbashly-framework/bashlyrepository. - Use online sources especially for settings behavior, advanced features (
bashly add...), and version-sensitive commands. - If internet access is unavailable, continue using local project files and
references/bashly-workflow.md, then state that online verification could not be performed.
Output Expectations
- Produce only files needed for the requested CLI behavior.
- Ensure required source partials are present so generated scripts implement the requested behavior.
- Keep generated UX consistent: clear descriptions, stable command names, and practical defaults.
- Prefer explicit examples in final responses (
tool command --flag value) for each major command.