toga-ai 1.0.0

package/skills/capture/SKILL.md

@@ -0,0 +1,294 @@
+---
+name: capture
+description: End-of-session knowledge writer for TOGA Technology projects. Run this at the END of a coding session to record what you worked on into the team `claude` knowledge base. It figures out what changed this session, matches it against existing knowledge, and proposes create/update/retire changes for one-tap approval — then writes them, keeping registry.json, frontmatter, and INDEX files consistent. Trigger whenever the user says "capture", "wrap up", "save my work to the knowledge base", "I'm done — record this", or finishes a feature and wants it documented.
+---
+
+# Capture — record this session's work into the team knowledge base
+
+You are the **only** editor of the knowledge base; developers never hand-edit it. So you
+must keep everything consistent and **ask whenever a required fact is missing — never
+assume**. Nothing is written until the developer approves your proposal.
+
+### Contribution model
+
+Every `/capture` automatically pushes new knowledge back to the team git repo after
+validate + index succeed:
+
+- Teammates get it on their **next `npx toga-harness`** run, which pulls the git repo
+  before installing — so the two-way loop is:
+  1. `npx toga-harness` seeds knowledge from the npm bundle
+  2. `/capture` grows the knowledge base and pushes it back to git
+  3. Teammates run `npx toga-harness` → git pull delivers the new docs → they get it
+- The push is **non-blocking**: if offline or credentials are missing, capture is still
+  successful and you report a reminder to push manually.
+- Only `knowledge/` files are ever staged — source code is never touched.
+
+## Core data model (same as `knowledge/CONVENTIONS.md` and the `kickoff` skill)
+
+- Knowledge lives in the **`claude` repo** under `knowledge/`, partitioned by framework
+  (`1.0/` = `App_`/`library`, `2.0/` = `_underscore`).
+- `apps/<repo>/architecture.md` + `features/*.md`; `standards/*.md`; top-level
+  `clients/<client>/{profile.md, features/, workflows/}`. App folders keyed by **repo name**.
+- `registry.json` maps **repo ↔ project ↔ framework ↔ role(core|app) ↔ dependsOn**.
+- Doc types: `feature`, `client-feature`, `workflow`, `architecture` (elevated),
+  `standard` (elevated).
+
+## Step 1 — Resolve the team-repo (`claude`) path
+
+Same as kickoff: Claude memory `team-repo-path` → env `CLAUDE_TEAM_REPO` → auto-discover
+(`./claude`, `../claude`, `../../claude`, walk up for `knowledge/INDEX.md`) → ask. Persist a
+`team-repo-path` memory if missing. Call the helper as `node "<TEAM_REPO>/knowledge.js" …`.
+
+## Step 2 — Determine framework / repo / project (ask if unknown)
+
+1. From the **live session context**, identify what was built, changed, debugged, or decided,
+   and which source files were touched.
+2. Identify the **repo** from the working path: match against your remembered `repo-path-<repo>`
+   memories; otherwise use the repo folder under a `C:\WWW\1.0` (→ framework 1.0) or
+   `C:\WWW\2.0` (→ framework 2.0) tree **as a suggestion to confirm, not a fact to assume**.
+3. Look the repo up in `registry.json` to get its `framework` and `project`.
+   - If the repo is **not registered**, run **New-repo onboarding** (below) — ask everything.
+   - If you cannot confidently determine the repo/framework/project/client, **ask**.
+
+## Step 3 — Match against existing knowledge
+
+For each distinct thing worked on, search for a doc that already covers it:
+
+```
+node "<TEAM_REPO>/knowledge.js" search --framework=<fw> --repo=<repo> --file=<touched-path>
+node "<TEAM_REPO>/knowledge.js" search --framework=<fw> --repo=<repo> --q=<keywords>
+```
+
+Classify each item as **CREATE** (no doc yet), **UPDATE** (a doc exists and needs new
+content / a new `files:` entry / a gotcha), or **DEPRECATE/DELETE** (the doc describes
+something now removed or obsolete).
+
+## Step 4 — Build the proposal (one-tap approval)
+
+Show a short, scannable, framework+repo-qualified plan, then the proposed content/diffs.
+Mark any `architecture` or `standard` change as **⚠ ELEVATED** (senior-owned). Example:
+
+```
+CREATE  2.0/apps/worker2/features/clickup-deploy.md          (feature)
+UPDATE  2.0/apps/worker2/features/creating-worker-actions.md (add files: + gotcha)
+⚠ ELEVATED  2.0/standards/backend-php.md                     (new cron-locking rule)
+DELETE  2.0/apps/worker2/features/old-thing.md               (removed this session)
+```
+
+Ask the developer to approve. They may accept all, accept some, or edit. **Write nothing
+until they confirm.** If a needed placement detail is ambiguous (which client? new vs.
+update?), ask before proposing.
+
+## Step 5 — Apply the approved changes
+
+Write/update/remove docs using the templates below. For every doc set/refresh frontmatter:
+`framework`, `repo` (omit for pure client docs), `project`, `client` (`shared` for app docs;
+a real slug for client docs), `type`, `status`, `updated` (today's date), `owners`, `files`,
+`related`. Add `related:` cross-links (a `client-feature` must link back to the shared
+`apps/<repo>/features/<base>.md`). If a new repo was onboarded, append it to `registry.json`.
+
+## Step 6 — Re-index and guard integrity (mandatory)
+
+```
+node "<TEAM_REPO>/knowledge.js" index
+node "<TEAM_REPO>/knowledge.js" validate
+```
+
+`index` rebuilds all `INDEX.md` files from frontmatter (never hand-edit them). If `validate`
+reports any error, **stop and fix it** before telling the developer you're done — do not
+report success on an inconsistent knowledge base.
+
+## Step 7 — Auto-push to share with teammates
+
+After validate + index succeed, stage and push only `knowledge/` changes to a
+**personal branch** so a maintainer can review before merging to main.
+
+```bash
+# Derive branch name from git user — e.g. knowledge/john-smith
+BRANCH="knowledge/$(git -C "<TEAM_REPO>" config user.name | tr ' ' '-' | tr '[:upper:]' '[:lower:]')"
+
+# Stage only knowledge/ — never stages source code
+git -C "<TEAM_REPO>" add knowledge/
+git -C "<TEAM_REPO>" diff --cached --quiet || git -C "<TEAM_REPO>" commit -m "knowledge: <brief description of what was captured>"
+
+# Push to personal branch — does not touch main
+git -C "<TEAM_REPO>" push origin HEAD:"$BRANCH"
+```
+
+Replace `<brief description of what was captured>` with a one-line summary of the docs
+written this capture (e.g. `"knowledge: add clickup-deploy feature doc for worker2"`).
+
+**If push succeeds:** report
+> "✓ Knowledge pushed to branch `knowledge/<your-name>` — a maintainer will review and merge to main"
+
+**If push fails** (offline, no credentials, diverged branch, or any other error): do
+**NOT** error out. Report:
+> "⚠ Could not push — run `git -C <TEAM_REPO> push origin HEAD:knowledge/<your-name>` when ready"
+and still consider the capture session successful.
+
+Never stage anything outside `knowledge/`. If `git diff --cached` would include files
+outside `knowledge/`, abort the commit and warn: "Unexpected staged files outside
+`knowledge/` — push skipped. Review and push manually."
+
+**Devs do not need write access to main.** They only need permission to push to
+`knowledge/*` branches. A maintainer reviews the branch and merges via PR.
+
+## Step 8 — Report
+
+List exactly what changed (clickable relative paths), and note any ⚠ ELEVATED docs the
+developer approved so they remember those touched senior-owned standards/architecture.
+If Step 7 pushed successfully, include the push confirmation in the report.
+
+---
+
+## Doc templates (write inline; no separate template files)
+
+### feature / client-feature
+```markdown
+---
+title: <Title>
+framework: "<1.0|2.0>"
+repo: <repo>            # omit for a pure client doc not tied to one repo
+project: <Project>
+client: <shared|client-slug>
+type: <feature|client-feature>
+status: active
+updated: <YYYY-MM-DD>
+owners: [<who>]
+files:
+  - <on-disk/path/one>
+related: []             # client-feature: link the shared apps/<repo>/features/<base>.md
+---
+
+## Summary
+What it does and why.
+
+## Key files / entry points
+The main files and how control flows.
+
+## How it works
+Step-by-step.
+
+## Data model
+Tables/columns touched (if any).
+
+## Client variations
+How behavior differs per client (or "none — uniform").
+
+## Gotchas / known issues
+The non-obvious things future-you will trip on.
+
+## Related docs
+Links.
+```
+
+### workflow (client business process)
+```markdown
+---
+title: <Workflow Name>
+framework: "<1.0|2.0>"
+project: <Project>
+client: <client-slug>
+type: workflow
+status: active
+updated: <YYYY-MM-DD>
+owners: [<who>]
+files: []
+related: []
+---
+
+## Summary
+The business process and who it serves.
+
+## Steps
+1. …
+
+## Systems involved
+Apps/repos, integrations, data.
+
+## Edge cases & escalation
+What can go wrong and who handles it.
+```
+
+### architecture (one per repo) — ⚠ ELEVATED
+```markdown
+---
+title: <Repo> Architecture
+framework: "<1.0|2.0>"
+repo: <repo>
+project: <Project>
+client: shared
+type: architecture
+status: active
+updated: <YYYY-MM-DD>
+owners: [<who>]
+files: [<key paths>]
+related: []
+---
+
+## Summary
+## <system sections: components, data, flows, key decisions>
+```
+
+### standard (coding standard) — ⚠ ELEVATED
+```markdown
+---
+title: <Backend|Frontend|…> Standards
+framework: "<1.0|2.0>"
+project: <core-project, e.g. _Underscore or Library>
+client: shared
+type: standard
+status: active
+updated: <YYYY-MM-DD>
+owners: [<who>]
+files: []
+related: []
+---
+
+## <topic sections: naming, structure, DB access, errors, testing, security…>
+```
+
+## New-repo onboarding (repo not in `registry.json`)
+
+Ask **all** — assume nothing (a heuristic may seed a default to confirm):
+1. Repo name (exact on-disk name). 2. Framework (1.0/2.0). 3. Project name.
+4. Role (core or app). 5. `dependsOn` repos beyond the framework core (default none).
+6. Local path on this machine (if not remembered → write a `repo-path-<repo>` memory).
+
+Append the entry to `registry.json`, then continue. `validate` will confirm consistency.
+
+---
+
+### After Capture
+
+Once you have completed a capture session and confirmed the changes are committed to
+the knowledge base, suggest the following to the developer:
+
+> "Session captured successfully. If you're done for today or may not finish this
+> thread in one sitting, run `/session-save` to persist your session state. This
+> records exactly what worked, what failed, what's pending, and your exact next step —
+> so you can resume without losing context, even days later."
+
+Provide the suggested command with a name hint:
+```
+/session-save <suggested-slug-based-on-what-was-worked-on>
+```
+
+For example, if the session was about "ClickUp deploy worker actions", suggest:
+```
+/session-save clickup-deploy-worker
+```
+
+### PostToolUse hook auto-validation
+
+The `.claude/settings.json` in this repo includes a `PostToolUse` hook that
+automatically runs `node knowledge.js validate` after any file write to `knowledge/`.
+This means:
+
+- As each doc is written during the capture step, validation runs immediately.
+- You will see inline output with any `ERROR:` or `OK` messages.
+- If validation fails after a write, address the error before writing the next doc —
+  do not proceed to Step 6's explicit `validate` run while errors are outstanding.
+- Step 6's explicit `node knowledge.js validate` call is still required as the final
+  gate — the hook fires per-write, but the explicit call confirms global consistency
+  after all writes are complete.

package/skills/code-review/SKILL.md

@@ -0,0 +1,140 @@
+---
+name: code-review
+description: PHP-focused code review for TOGA Technology projects. Reviews for SQL injection, XSS, framework pattern violations (App_ vs _underscore), N+1 queries, and coding standards. Trigger when the user says "code-review", "review this file", "check my code", or "review [filename]".
+---
+
+# Code Review Skill
+
+PHP-focused code review skill for TOGA Technology projects. Reviews for security vulnerabilities, framework pattern violations, SQL quality, and style issues.
+
+## Usage
+
+```
+/code-review [file-path]
+/code-review src/Controllers/Orders.php
+/code-review                              # reviews most recently modified PHP files
+```
+
+---
+
+## Behavior
+
+### Step 1 — Identify files to review
+
+If a file path is provided: read that file.
+
+If no file path is provided: find the most recently modified PHP files in the session by checking tool-use history for Write/Edit operations on `.php` files. Review up to 3 files.
+
+If no PHP files were modified this session: ask the user which file to review.
+
+### Step 2 — Detect framework
+
+Read the file's class declarations:
+- Class names starting with `App_` → Framework 1.0
+- Class names with leading `_` or file under a `2.0` path → Framework 2.0
+- Check `knowledge/registry.json` if still ambiguous
+
+Load `knowledge/<fw>/standards/backend-php.md` for team-specific rules.
+
+### Step 3 — Security scan (always run first)
+
+Check every finding against a concrete failure mode. Only report issues where a specific exploit or data loss scenario can be described.
+
+**Critical security issues to find:**
+- SQL injection: user input (`$_GET`, `$_POST`, `$_COOKIE`, function params traceable to user input) concatenated/interpolated into SQL strings
+- XSS: user-supplied data echoed or printed without `htmlspecialchars()`
+- `eval()` or `exec()` on user-controlled strings
+- Raw `$_GET`/`$_POST`/`$_COOKIE` used without validation
+- Passwords stored in plaintext or hashed with MD5/SHA1
+- Sensitive data (passwords, tokens, PII) in log statements
+- File path construction from user input without allowlist
+- Missing `WHERE` clause on `UPDATE` or `DELETE`
+
+### Step 4 — Framework pattern scan
+
+**For Framework 1.0 (App_):**
+- Classes missing `App_` prefix
+- Controllers not extending `App_Controller`
+- Models not extending `App_Model`
+- Direct model instantiation with `new` instead of `App_Registry::get()`
+- `snake_case` public method names
+
+**For Framework 2.0 (_underscore):**
+- Workers not extending `_Worker` or missing `run()` method
+- Workers called directly instead of via `_Queue::dispatch()`
+- `api2` action methods not returning the standard `{success, data, errors}` envelope
+- Missing error type distinction (retriable vs non-retriable) in workers
+
+### Step 5 — SQL quality scan
+
+- N+1: query inside a loop where the query uses a loop variable
+- Unbounded `SELECT` without `LIMIT` on non-lookup tables
+- `SELECT *` instead of named columns (INFO level)
+- Deprecated: `mysql_query()`, `mysql_escape_string()`, `addslashes()` for SQL
+
+### Step 6 — Style scan
+
+Only flag style issues with a direct rule citation from `rules/common/coding-style.md`:
+- Bare `catch` or catch-and-ignore
+- Mutable state in catch block without log or rethrow
+- Magic numbers (unexplained literals)
+- Commented-out code
+- Functions with 4+ positional parameters
+- Missing return type declarations on public methods
+
+### Step 7 — Confidence filter
+
+Before including any finding in the output, confirm:
+1. The exact file:line can be cited
+2. The concrete failure mode (exploit, data loss, wrong behavior) can be described
+3. It is not a style preference without a rule backing it
+
+Remove any finding that fails this filter. It is better to report 2 real issues than 8 vague ones.
+
+### Step 8 — Output
+
+Build the findings table. Count by severity. Output the summary.
+
+---
+
+## Output Format
+
+```
+## Code Review — src/Controllers/Orders.php
+Framework: 2.0 (_underscore)
+
+| File:Line | Severity | Issue | Fix |
+|-----------|----------|-------|-----|
+| Orders.php:34 | CRITICAL | SQL injection: `$_POST['status']` interpolated into query string | Use `_Db::select('orders', ['status' => $_POST['status']])` or PDO prepared statement |
+| Orders.php:71 | CRITICAL | Missing WHERE on UPDATE: `_Db::update('orders', $data)` with no condition | Add condition array as third param: `_Db::update('orders', $data, ['id' => $orderId])` |
+| Orders.php:102 | WARNING | Worker called directly: `$w = new _Worker_Notify(); $w->run()` | Dispatch via queue: `_Queue::dispatch('_Worker_Notify', $payload)` |
+| Orders.php:118 | WARNING | N+1 query: `_Db::find('order_items', ['order_id' => $o->id])` inside foreach | Collect IDs, batch with IN clause outside loop |
+| Orders.php:145 | INFO | `SELECT *` — retrieves all columns | Replace with explicit column list to reduce data transfer |
+
+**Summary:** 2 critical, 2 warnings, 1 info
+
+Critical issues must be fixed before merge.
+Warnings should be fixed before merge.
+Info items are optional improvements.
+```
+
+If zero findings across all categories:
+
+```
+## Code Review — src/Controllers/Orders.php
+Framework: 2.0 (_underscore)
+
+No issues found. All checks passed.
+
+Checks run: SQL injection, XSS, eval/exec, input validation, framework patterns,
+worker dispatch, API envelope, SQL quality, error handling, style rules.
+```
+
+---
+
+## Notes
+
+- Never invent findings to appear thorough. "No issues found" is a valid and useful result.
+- If a file is too large to review completely in one pass, state which sections were reviewed and which were not.
+- If the framework cannot be determined, state this and ask before proceeding.
+- For files in the `library` or `_underscore` core repos: flag any change to a base class method signature as a WARNING with a note that dependent repos must be checked.

package/skills/create-elastic-beanstalk/SKILL.md

@@ -0,0 +1,217 @@
+---
+name: create-elastic-beanstalk
+description: Generates a ready-to-paste AWS CloudShell command that creates a new Elastic Beanstalk environment following True/Agilant conventions. Use this skill whenever the user wants to create, spin up, or provision a new Elastic Beanstalk environment, add an EB environment to an existing application, or asks for the CloudShell command to launch a beanstalk. Trigger immediately even if they just say "make me a new beanstalk for X" or "new EB env in the API app".
+---
+
+# Create Elastic Beanstalk Environment
+
+## What this skill does
+
+You interview the user, then output a **single copy-paste CloudShell command** that creates a new
+Elastic Beanstalk *environment* inside an *existing* EB *application*. The command must run as-is
+when pasted into AWS CloudShell — no placeholders left behind, no editing required.
+
+You do **not** run any AWS commands yourself (you are not in CloudShell). You gather the answers,
+fill in the proven values below, and print the final command for the developer to paste.
+
+## The core rule: PRODUCTION vs everything else
+
+The value of the `ENVIRONMENT` variable decides almost everything. If the user's `ENVIRONMENT`
+value is exactly `production`, use the **PRODUCTION profile**. Any other value
+(`client-alpha`, `qa-beta`, `sandbox-dev`, etc.) uses the **NON-PROD profile**.
+
+These two profiles live in **different AWS accounts** with different VPCs, subnets, roles, and
+storage. The developer's CloudShell session must be logged into the matching account — always tell
+them which account to confirm before they paste.
+
+### PRODUCTION profile — AWS account `654654170868`
+
+| Setting | Value |
+|---|---|
+| VPC | `vpc-08030daf1c2dad280` |
+| Instance (private) subnets | `subnet-0e135d4093ab60b2f,subnet-0c6579c05a0f51ac6,subnet-096d9f8f0617949ef` |
+| ELB (public) subnets | `subnet-016ceecffa8c484dd,subnet-0a03a9af3536ab3e2,subnet-0f4272cd10edeee8d` |
+| Instance profile | `ElasticBeanstalk-EC2-Instance-Profile` |
+| Service role | `arn:aws:iam::654654170868:role/service-role/aws-elasticbeanstalk-service-role` |
+| Storage | `gp2` (SSD), 10 GB |
+| Load balancer | **Dedicated** application LB (`LoadBalancerIsShared=false`), public-facing |
+| Default instance type | `t4g.large` |
+| Default instance count | Min = Max = `2` |
+
+### NON-PROD profile — AWS account `975050298201`
+
+| Setting | Value |
+|---|---|
+| VPC | `vpc-0c5319e7df6f736c5` |
+| Instance (private) subnets | `subnet-0d6acbaf19ee03fa9,subnet-0f5085f369274c305,subnet-0133a6098281928c7` (`true-test-private-web-a/b/c`) |
+| Instance profile | `aws-elasticbeanstalk-ec2-role` |
+| Service role | `arn:aws:iam::975050298201:role/aws-elasticbeanstalk-service-role` |
+| Storage | `standard` (magnetic), 10 GB |
+| Load balancer | **Shared** application LB (`LoadBalancerIsShared=true`) — must pick one (see list) |
+| Default instance type | `t4g.micro` |
+| Default instance count | Min = Max = `1` |
+
+> Non-prod uses a **shared** ALB, so do NOT set `ELBScheme`, `ELBSubnets`, or
+> `AssociatePublicIpAddress`. Elastic Beanstalk rejects subnet config on a shared load balancer; it
+> simply attaches a listener rule to the existing ALB.
+
+## Always-true conventions (both profiles)
+
+- **Platform:** PHP on Amazon Linux 2023, Apache proxy, **arm64** (`SupportedArchitectures=arm64`,
+  `t4g` family). Default solution stack: `64bit Amazon Linux 2023 v4.13.1 running PHP 8.5`.
+- **Key pair:** `true-aws-infrastructure-production`.
+- **Deployments:** `AllAtOnce` — **always**, no exceptions.
+- **No real autoscaling:** AWS won't let you disable it, so neuter the trigger — watch
+  `CPUUtilization` with `LowerThreshold=2000000` and `UpperThreshold=6000000` so it never breaches.
+  Always use `Unit=Percent`. Set Min = Max instance count so the group size is pinned.
+- **Instances** always go in the **private** subnets; load balancers in **public** subnets.
+- **On-Demand only** — always default to On-Demand instances (`EnableSpot=false`), never Spot.
+
+## Interview the user (ask before generating anything)
+
+Ask these together in one message. Don't generate the command until you have the answers.
+
+1. **`ENVIRONMENT` value** — what string goes in the `ENVIRONMENT` variable? (e.g. `production`,
+   `client-delta`, `qa-hotfix`). This selects the profile. Treat exactly `production` as PRODUCTION.
+
+2. **EB application** — which existing application? It must already exist (this skill never creates
+   the application). Known applications: `SAML`, `talos-backend`, `TOGA Technology`, `API`,
+   `TOGaCommerce`, `TOGaIQ`, `Worker`. If unsure, have them run:
+   `aws elasticbeanstalk describe-applications --query 'Applications[].ApplicationName' --output table`
+
+3. **Environment name** — the name for the new environment (e.g. `api-client-delta`). Lowercase,
+   hyphenated, ≤ 40 chars.
+
+4. **Shared ALB (NON-PROD only)** — which shared ALB should it attach to? Ask for the ALB **name**;
+   the generated command resolves the ARN at runtime so it can't go stale. Known shared ALBs in
+   account `975050298201` (`describe-load-balancers` to refresh):
+   `true-alb-sandbox-dev`, `true-alb-sandbox-client`, `true-alb-client-alpha`,
+   `true-alb-client-beta`, `true-alb-client-gamma`, `true-alb-qa-alpha`, `true-alb-qa-beta`,
+   `true-alb-qa-gamma`, `true-alb-qa-hotfix`, `true-alb-qa-task`, `true-alb-qc-alpha`,
+   `true-alb-qc-beta`, `true-alb-qc-gamma`, `true-alb-qc-hotfix`, `true-alb-qc-performance`,
+   `true-alb-qc-security`, `true-alb-qc-task`.
+
+5. **Instance type** — confirm or change. Default `t4g.micro` (non-prod) / `t4g.large` (prod). Must
+   be arm64 `t4g` family; `t4g.micro` is the floor.
+
+6. **Instance count** — confirm or change. Default Min = Max = `1` (non-prod) / `2` (prod). It's
+   pinned (no scaling), so Min and Max are set equal.
+
+7. **PHP version** *(optional)* — default `8.5`. Other current AL2023 options: `8.1`, `8.2`, `8.3`,
+   `8.4`. Maps to solution stack `64bit Amazon Linux 2023 v4.13.1 running PHP <ver>`.
+
+8. **CNAME prefix** *(optional)* — defaults to the environment name.
+
+## Generating the command
+
+Substitute every value at generation time so the printed command has no placeholders. Build the
+option settings as a JSON heredoc, then call `create-environment`.
+
+Before the command, print a one-line **account check** banner, e.g.:
+> ⚠️ Confirm your CloudShell is logged into account **975050298201** (non-prod) before pasting.
+
+### NON-PROD template (shared ALB)
+
+```bash
+# Target account: 975050298201  |  App: <APP>  |  Env: <ENV_NAME>  |  ENVIRONMENT=<ENV_VALUE>
+SHARED_ALB_ARN=$(aws elbv2 describe-load-balancers \
+  --names "<SHARED_ALB_NAME>" \
+  --query 'LoadBalancers[0].LoadBalancerArn' --output text)
+
+cat > /tmp/eb-options.json <<EOF
+[
+  {"Namespace":"aws:autoscaling:asg","OptionName":"MinSize","Value":"<COUNT>"},
+  {"Namespace":"aws:autoscaling:asg","OptionName":"MaxSize","Value":"<COUNT>"},
+  {"Namespace":"aws:ec2:instances","OptionName":"InstanceTypes","Value":"<INSTANCE_TYPE>"},
+  {"Namespace":"aws:ec2:instances","OptionName":"SupportedArchitectures","Value":"arm64"},
+  {"Namespace":"aws:ec2:instances","OptionName":"EnableSpot","Value":"false"},
+  {"Namespace":"aws:autoscaling:launchconfiguration","OptionName":"IamInstanceProfile","Value":"aws-elasticbeanstalk-ec2-role"},
+  {"Namespace":"aws:autoscaling:launchconfiguration","OptionName":"EC2KeyName","Value":"true-aws-infrastructure-production"},
+  {"Namespace":"aws:autoscaling:launchconfiguration","OptionName":"RootVolumeType","Value":"standard"},
+  {"Namespace":"aws:autoscaling:launchconfiguration","OptionName":"RootVolumeSize","Value":"10"},
+  {"Namespace":"aws:autoscaling:launchconfiguration","OptionName":"DisableIMDSv1","Value":"true"},
+  {"Namespace":"aws:ec2:vpc","OptionName":"VPCId","Value":"vpc-0c5319e7df6f736c5"},
+  {"Namespace":"aws:ec2:vpc","OptionName":"Subnets","Value":"subnet-0d6acbaf19ee03fa9,subnet-0f5085f369274c305,subnet-0133a6098281928c7"},
+  {"Namespace":"aws:elasticbeanstalk:environment","OptionName":"LoadBalancerType","Value":"application"},
+  {"Namespace":"aws:elasticbeanstalk:environment","OptionName":"LoadBalancerIsShared","Value":"true"},
+  {"Namespace":"aws:elasticbeanstalk:environment","OptionName":"ServiceRole","Value":"arn:aws:iam::975050298201:role/aws-elasticbeanstalk-service-role"},
+  {"Namespace":"aws:elbv2:loadbalancer","OptionName":"SharedLoadBalancer","Value":"${SHARED_ALB_ARN}"},
+  {"Namespace":"aws:elasticbeanstalk:command","OptionName":"DeploymentPolicy","Value":"AllAtOnce"},
+  {"Namespace":"aws:elasticbeanstalk:environment:proxy","OptionName":"ProxyServer","Value":"apache"},
+  {"Namespace":"aws:autoscaling:trigger","OptionName":"MeasureName","Value":"CPUUtilization"},
+  {"Namespace":"aws:autoscaling:trigger","OptionName":"Statistic","Value":"Average"},
+  {"Namespace":"aws:autoscaling:trigger","OptionName":"Unit","Value":"Percent"},
+  {"Namespace":"aws:autoscaling:trigger","OptionName":"LowerThreshold","Value":"2000000"},
+  {"Namespace":"aws:autoscaling:trigger","OptionName":"UpperThreshold","Value":"6000000"},
+  {"Namespace":"aws:autoscaling:trigger","OptionName":"LowerBreachScaleIncrement","Value":"-1"},
+  {"Namespace":"aws:autoscaling:trigger","OptionName":"UpperBreachScaleIncrement","Value":"1"},
+  {"Namespace":"aws:autoscaling:trigger","OptionName":"BreachDuration","Value":"5"},
+  {"Namespace":"aws:autoscaling:trigger","OptionName":"Period","Value":"5"},
+  {"Namespace":"aws:autoscaling:trigger","OptionName":"EvaluationPeriods","Value":"1"},
+  {"Namespace":"aws:elasticbeanstalk:application:environment","OptionName":"ENVIRONMENT","Value":"<ENV_VALUE>"}
+]
+EOF
+
+aws elasticbeanstalk create-environment \
+  --application-name "<APP>" \
+  --environment-name "<ENV_NAME>" \
+  --cname-prefix "<CNAME_PREFIX>" \
+  --solution-stack-name "64bit Amazon Linux 2023 v4.13.1 running PHP <PHP_VER>" \
+  --option-settings file:///tmp/eb-options.json
+```
+
+### PRODUCTION template (dedicated public ALB)
+
+Same shape, but in account `654654170868`, with the dedicated-LB differences:
+
+- Drop the `SHARED_ALB_ARN` lookup and the `aws:elbv2:loadbalancer SharedLoadBalancer` line.
+- `LoadBalancerIsShared` → `false`.
+- `IamInstanceProfile` → `ElasticBeanstalk-EC2-Instance-Profile`.
+- `ServiceRole` → `arn:aws:iam::654654170868:role/service-role/aws-elasticbeanstalk-service-role`.
+- `RootVolumeType` → `gp2`.
+- `VPCId` → `vpc-08030daf1c2dad280`; `Subnets` → the three prod private subnets.
+- Add the public-facing LB lines:
+  ```
+  {"Namespace":"aws:ec2:vpc","OptionName":"ELBScheme","Value":"public"},
+  {"Namespace":"aws:ec2:vpc","OptionName":"ELBSubnets","Value":"subnet-016ceecffa8c484dd,subnet-0a03a9af3536ab3e2,subnet-0f4272cd10edeee8d"},
+  {"Namespace":"aws:ec2:vpc","OptionName":"AssociatePublicIpAddress","Value":"false"},
+  ```
+- Defaults: `InstanceTypes=t4g.large`, count `2`.
+- Everything else identical: AllAtOnce, `Unit=Percent` trigger 2000000–6000000, `EnableSpot=false`,
+  arm64, Apache, key pair, 10 GB root volume.
+
+## After printing the command
+
+Tell the developer, concisely:
+
+1. **Confirm the account** — CloudShell must be in `654654170868` (prod) or `975050298201`
+   (non-prod). Paste fails or misbehaves if they're in the wrong account.
+2. The application must already exist; this only creates the environment.
+3. Watch it come up: `aws elasticbeanstalk describe-environments --environment-names "<ENV_NAME>" --query 'Environments[0].{Status:Status,Health:Health,CNAME:CNAME}' --output table`
+4. If EB complains about a missing listener rule on a shared ALB, the env still creates; the rule is
+   added automatically once the environment is `Ready`.
+
+## Reviewing / cloning an existing environment
+
+To copy settings from a known-good environment, dump its full config (this is how this skill's
+values were sourced):
+
+```bash
+aws elasticbeanstalk describe-configuration-settings \
+  --application-name "<APP>" --environment-name "<EXISTING_ENV>" \
+  --query 'ConfigurationSettings[0].OptionSettings[].{NS:Namespace,Opt:OptionName,Val:Value}' \
+  --output table
+```
+
+If the user is targeting an account other than the two above, ask them to run that command (plus
+`aws ec2 describe-subnets` and `aws elbv2 describe-load-balancers`) and paste the output so you can
+build a matching profile rather than guessing.
+
+## Conventions baked in (don't silently change these)
+
+- All-at-once deploys, arm64/t4g, Apache, private-subnet instances, public-subnet LBs, the
+  2000000–6000000 never-trigger CPU hack (`Unit=Percent`), pinned Min=Max instance count, the
+  `true-aws-infrastructure-production` key pair, 10 GB root volume (SSD `gp2` prod / magnetic
+  `standard` non-prod), On-Demand instances.
+- If the user explicitly asks to deviate (e.g. enable Spot, change storage), honor it but call out
+  that it departs from the standard.