Files
TSYSDevStack/ToolboxStack/output/PROMPT
ReachableCEO 27948346b4 feat(toolbox): update toolbox configuration and scripts
- Update collab/TSYSDevStack-toolbox-prompt.md with latest guidelines
- Update output/PROMPT with improved instructions for AI collaboration
- Update output/toolbox-base/PROMPT with enhanced development guidelines
- Update output/toolbox-base/README.md with current documentation
- Update output/toolbox-base/build.sh with improved build process
- Update output/toolbox-base/docker-compose.yml with refined service definitions
- Update output/toolbox-base/run.sh with enhanced runtime configuration
- Add output/toolbox-base/release.sh for release management processes

These changes improve the developer workspace experience and ensure
consistent tooling across the TSYSDevStack project.
2025-10-29 08:26:35 -05:00

20 lines
1.7 KiB
Plaintext

You are Codex helping with TSYSDevStack ToolboxStack deliverables.
Global toolbox guidance:
- Directory layout: each toolbox-* directory carries its own Dockerfile/README/PROMPT; shared scaffolds live in toolbox-template/.devcontainer and docker-compose.yml.
- Use ./NewToolbox.sh <name> to scaffold a new toolbox-* directory from toolbox-template.
- Keep aqua/mise usage consistent across the family; prefer aqua-managed CLIs and mise-managed runtimes.
- Reference toolbox-template when bootstrapping a new toolbox. Copy the directory, rename it, and replace {{toolbox_name}} placeholders in compose/devcontainer.
- Each toolbox maintains a `SEED` file to seed the initial goals—edit it once before kicking off work, then rely on the toolbox PROMPT for ongoing updates (which begins by reading SEED).
- Default build workflow: `./build.sh` produces a `:dev` tag; `./release.sh <semver>` (clean git tree required) rebuilds and pushes `:dev`, `:release-current`, and `v<semver>` (use `--dry-run`/`--allow-dirty` to rehearse).
- Downstream Dockerfiles should inherit from `:release-current` by default; pin to version tags when reproducibility matters.
Commit discipline:
- Craft atomic commits with clear intent; do not mix unrelated changes.
- Follow Conventional Commits (`type(scope): summary`) with concise, descriptive language.
- Commit frequently as features evolve, keeping diffs reviewable.
- After documentation/tooling changes, run ./build.sh to ensure the image builds, then push once the build succeeds.
- Use git best practices: clean history, no force pushes without coordination, and resolve conflicts promptly.
Per-toolbox prompts are responsible for fine-grained inventories and verification steps.