diff --git a/collab/questions/00-bootstrap.md b/collab/questions/00-bootstrap.md index 971cbd1..aa368d2 100644 --- a/collab/questions/00-bootstrap.md +++ b/collab/questions/00-bootstrap.md @@ -94,33 +94,102 @@ Lets say Ubuntu 22.04/Debian 12 or later. ### Wrapper naming & install 1. Wrapper name: prefer `codex-helper` or `CodexHelper`? Install path (e.g., `~/bin`)? + +CodexHelper please +This will not be "installed". It will be cloned , the CodexHelper shell script added to the users path. The CodexHelper is only an entrypoint and wrapper around codex-cli (CodexHelper should have a bootstrap function to ensure codex-cli is actually installed of course). The CodexHelper script will be called from within a project directory somewhere else on the filesystem. It may or may not be a git repository working directory. + 2. Binary discovery: try `which codex` first, then `codex-cli`? Allow override via `CODEX_BIN` env var? +Sure. + ### Modes and templates 3. Repo layout: store modes under `modes//` with `system.md`, `mode.md`, `defaults.yaml`? OK? + +Yes. However the system prompt is shared across all modes. It will be about a dozen rules or so that I want applied to all of my projects. + +Perhaps we should allow a mode specific system prompt as well? I don't know enough about how prompts are chained or stacked to fully +understand the implications. + +Basically I want a base set of global rules, a mode set of rules and then a project prompt (which won't be rules per se (well maybe coding styles or something)) but more of a narrative/descriptive set of material telling codex WHAT to do (not so much how to do it) + + 4. Project scaffolding: create templates under `templates/project//...` and generate into user-specified target path? OK? + +I am not sure what this means? Give me some examples? + 5. Example project: include only one example (resume rewriter). Where should we place the example template in this repo? +Actually forget all about the example project. I'm going to do that in a different repository. I want this project/repo to be purely code/prompts. + ### Project structure & config 6. Config format: YAML vs JSON vs TOML? Preference? (YAML easier for markdown-heavy prompts.) 7. Single file vs split: prefer `project.yaml` in project root, or split into `prompts/` + `codex.yaml`? 8. Precedence confirm: CLI > env > project > mode > global defaults — confirm this exact order? 9. Entrypoint script: generate `codex.sh` in project root that resolves config and runs `codex`? Name OK? +I think that all looks good. I'll leave it to your discretion. I need to get a "feel" for the usage and tweak as we go. + ### CLI UX 10. Subcommands: propose `new-project`, `new-mode`, and `run`. Example: - `codex-helper new-project --mode SAASApp --name my-app --path ~/dev/my-app` - `codex-helper new-mode --name SAASApp` - `codex-helper run` (inside a project dir) Approve? + + 11. Flags: always accept `--mode`, `--prompt-file`, `--config`, `--sandbox`, `--full-auto` to pass through to codex. Anything else? 12. Non-interactive default: default non-interactive; add `--interactive` to prompt for missing values. Approve? +Yes I think that all looks good. + ### Outputs, safety, and licensing 13. Runs directory: write transcripts/logs to `/runs//...`. Approve? + +Well remember, we don't allow the script to run from inside the repo checkout directory except to create new modes. + 14. Safety: default to no destructive actions; require `--force` to overwrite existing files; never run `git push` for user projects. Approve and add anything else? + +User projects will never be created in this repo. + 15. Dependencies: are `bash`, `git`, and one of `jq` (JSON) or `yq` (YAML) acceptable? Preference? + +Sure. I suppose we should settle on either json or yaml? Supporting both seems like more work? + 16. Licensing in generated projects: include no default LICENSE, or include a template with TODO? Preference? +The user will pick a license. We won't be invovled. + ### Roadmap 17. We will add `docs/ROADMAP.md` and defer MCP integration. Any additional roadmap items you want listed now? + +No + +## Followup 2025-17-09-14:33 + +### CLI UX and workflow +1. Subcommands vs flags-only: prefer simple flags (e.g., `CodexHelper --mode SAASApp --new-project`) or explicit subcommands (`CodexHelper new-project --mode SAASApp`)? Please pick one. +2. Project creation flow: confirm that `CodexHelper` runs from any project dir outside this repo to scaffold project files for a chosen mode; this repo is only for modes and the wrapper. Correct? + +### Templates and scaffolding +3. Examples for project scaffolding (pick what you want generated initially): + - prompts/: `project.md` (narrative), optional `style.md` + - config: `codex.yaml` (mode selection, settings, MCP placeholders) + - helper: `codex.sh` entrypoint that resolves config and runs `codex` + - runs/: created on first run, ignored by VCS + Keep/delete/adjust which of these? + +### Prompts composition +4. Confirm stacking order: Global system rules → Mode rules → Project narrative prompt. OK? +5. Locations proposal: `prompts/global/system.md` (repo-wide), `modes//system.md` (optional overlay), `modes//mode.md` (mode rules), project `prompts/project.md`. Approve? + +### Config and tooling +6. Format/tooling: choose YAML + `yq` as the single supported format/tool. Approve? +7. Precedence final confirm: CLI > env > project > mode > global defaults. Approve? +8. Binary detection: detect `codex` then `codex-cli`, override with `CODEX_BIN`. On missing, print instructions; no auto-install. Approve? + +### Outputs and safety +9. Runs location: always `/runs//...` (never in this repo unless creating modes). Approve? +10. Safety: never overwrite without `--force`; never run `git push` in user projects. Anything else to lock down? + +### Install convenience +11. Provide optional `bin/install.sh` to symlink `CodexHelper` into `~/bin` (no sudo). Include or skip?