glori-builder 1.0.0

package/.claude/commands/deploy-setup.md

@@ -0,0 +1,158 @@
+---
+description: Set up deployment for this project — interviews about platform and environments, then generates a project-level /deploy skill tailored to this project.
+---
+
+# Deploy Setup
+
+Generates a project-specific `.claude/skills/deploy/SKILL.md` by interviewing you about your deployment setup. Run once per project. After this, /deploy works for this specific project.
+
+## Interview
+
+Ask these questions one at a time, wait for each answer:
+
+**Q1 — Platform:**
+"What platform are you deploying to? (Fly.io, Vercel, Railway, Render, AWS, DigitalOcean, VPS, other?)"
+
+**Q2 — Environments:**
+"What environments do you have? For example: staging at app-staging.fly.dev and production at app.fly.dev. What are the exact names/URLs?"
+
+**Q3 — Rollback:**
+"How do you roll back a bad deploy? (e.g., Fly.io machine rollback, Vercel instant rollback, git tag + redeploy, manual)"
+
+**Q4 — Pre-deploy checks:**
+"Are there any steps that must run before deploying? (database migrations, smoke tests, build verification, etc.)"
+
+**Q5 — Deploy command:**
+"What's the exact command to deploy? If you're not sure, I'll generate a best-guess based on your platform."
+
+## Platform Auth Reference
+
+Use this to generate the correct auth prerequisite for the deploy skill.
+
+Each platform falls into one of two categories:
+
+**CLI-authenticated** — developer logs in once, token stored by the CLI tool:
+
+| Platform | Auth check | Auth command if missing |
+|---|---|---|
+| Fly.io | `fly auth whoami` | `fly auth login` |
+| Vercel | `vercel whoami` | `vercel login` |
+| Railway | `railway whoami` | `railway login` |
+| DigitalOcean | `doctl auth list` | `doctl auth init` |
+| AWS | `aws sts get-caller-identity` | `aws configure` |
+
+**API token required** — no CLI auth flow, token goes in secrets.env:
+
+| Platform | Token var | Where to get it |
+|---|---|---|
+| Render | `RENDER_API_TOKEN` | Render dashboard → Account → API Keys |
+| Netlify | `NETLIFY_AUTH_TOKEN` | Netlify → User settings → Personal access tokens |
+
+For API token platforms: check that the token is set (`echo ${TOKEN_VAR:+set}`) and direct the user to `/secrets add TOKEN_VAR` if missing.
+
+## Generate Deploy Skill
+
+Based on all answers, create `.claude/skills/deploy/SKILL.md`.
+
+The file must include:
+
+1. **Auth prerequisite** — using the platform reference above, the correct check at the very top
+2. **Environments** — staging and production URLs/app names
+3. **Pre-deploy checklist** — from Q4
+4. **Deploy commands** — per environment
+5. **Production confirmation gate** — explicit "Are you sure?" before touching production
+6. **Rollback procedure** — from Q3
+7. **Post-deploy verification** — check URL, confirm key flows work
+
+### Template
+
+```markdown
+---
+name: deploy
+description: Deploy {project-name} to staging or production. Usage: /deploy staging or /deploy production
+argument-hint: staging | production
+---
+
+# Deploy: {project-name}
+
+## Auth Prerequisite
+
+[For CLI-authenticated platforms:]
+```bash
+{auth-check-command} 2>/dev/null || {
+  echo "Not authenticated with {Platform}. Run: {auth-command}"
+  exit 1
+}
+```
+
+[For API token platforms:]
+```bash
+[ -n "${TOKEN_VAR}" ] || {
+  echo "{TOKEN_VAR} is not set. Run: /secrets add {TOKEN_VAR}"
+  exit 1
+}
+```
+
+## Environments
+- Staging:    {staging URL or app name}
+- Production: {production URL or app name}
+
+## Pre-Deploy Checklist
+[Each item from Q4 as a bash check or manual confirmation]
+
+## Deploy
+
+### Staging
+```bash
+[exact staging deploy command(s)]
+```
+
+Verify: [what to check after staging deploy]
+
+### Production
+
+> "Deploying to PRODUCTION. This affects live users. Confirm?"
+
+Wait for explicit confirmation before running:
+
+```bash
+[exact production deploy command(s)]
+```
+
+## Rollback
+```bash
+[exact rollback command(s) from Q3]
+```
+
+## Post-Deploy Verification
+- [ ] {staging/production URL} loads without errors
+- [ ] [key user flow works]
+- [ ] Check logs: [log command for this platform]
+```
+
+## Also: add .envrc if direnv is available
+
+After writing the deploy skill, check if direnv is installed:
+
+```bash
+which direnv 2>/dev/null && echo "installed" || echo "missing"
+```
+
+If installed and `.envrc` doesn't exist in the project:
+
+```bash
+[ -f .envrc ] || echo 'dotenv' > .envrc && direnv allow .
+```
+
+This makes project `.env` vars (database URLs, API tokens, etc.) automatically available to all commands — including deploy — without manual sourcing.
+
+## Commit
+
+```bash
+mkdir -p .claude/skills/deploy
+git add .claude/skills/deploy/SKILL.md
+[ -f .envrc ] && git add .envrc
+git commit -m "chore(deploy): add project-specific deploy skill for {platform}"
+```
+
+Report: "Deploy skill created for {platform}. Auth check, environments, rollback, and verification all included. Use /deploy staging or /deploy production from now on."

package/.claude/commands/execute.md

@@ -0,0 +1,101 @@
+---
+description: Execute an implementation plan
+argument-hint: [path-to-plan]
+---
+
+# Execute: Implement from Plan
+
+## Plan to Execute
+
+Read plan file: `$ARGUMENTS`
+
+## Execution Instructions
+
+### 1. Read and Understand
+
+- Read the ENTIRE plan carefully
+- Understand all tasks and their dependencies
+- Note the validation commands to run
+- Review the testing strategy
+
+### 2. Execute Tasks in Order
+
+For EACH task in "Step by Step Tasks":
+
+#### a. Navigate to the task
+- Identify the file and action required
+- Read existing related files if modifying
+
+#### b. Implement the task
+- Follow the detailed specifications exactly
+- Maintain consistency with existing code patterns
+- Include proper type hints and documentation
+- Add structured logging where appropriate
+
+#### c. Verify as you go
+- After each file change, check syntax
+- Ensure imports are correct
+- Verify types are properly defined
+
+### 3. Implement Testing Strategy
+
+After completing implementation tasks:
+
+- Create all test files specified in the plan
+- Implement all test cases mentioned
+- Follow the testing approach outlined
+- Ensure tests cover edge cases
+
+### 4. Run Validation Commands
+
+Execute ALL validation commands from the plan in order:
+
+```bash
+# Run each command exactly as specified in plan
+```
+
+If any command fails:
+- Fix the issue
+- Re-run the command
+- Continue only when it passes
+
+### 5. Final Verification
+
+Before completing:
+
+- ✅ All tasks from plan completed
+- ✅ All tests created and passing
+- ✅ All validation commands pass
+- ✅ Code follows project conventions
+- ✅ Documentation added/updated as needed
+
+## Output Report
+
+Provide summary:
+
+### Completed Tasks
+- List of all tasks completed
+- Files created (with paths)
+- Files modified (with paths)
+
+### Tests Added
+- Test files created
+- Test cases implemented
+- Test results
+
+### Validation Results
+```bash
+# Output from each validation command
+```
+
+### Ready for Commit
+- Confirm all changes are complete
+- Confirm all validations pass
+- Ready for `/commit` command
+
+## Notes
+
+- If you encounter issues not addressed in the plan, document them
+- If you need to deviate from the plan, explain why
+- If tests fail, fix implementation until they pass
+- Don't skip validation steps

package/.claude/commands/issue-prd.md

@@ -0,0 +1,108 @@
+---
+description: Fetch a Linear issue, evaluate it, and kick off the implementation pipeline
+argument-hint: <ISSUE-ID e.g. QUE-40>
+---
+
+# Issue PRD: Pipeline Intake
+
+## Issue: $ARGUMENTS
+
+### Session Rename
+/rename $ARGUMENTS-{M}-{D}
+
+### Step 1: Fetch the Issue
+
+Linear's top-level `issues` query and `issueVcSearch` are unreliable with personal API keys. Always use team-scoped queries.
+
+Parse the team key and issue number from `$ARGUMENTS` (e.g., "QUE-40" → team key "QUE", number 40).
+
+If $LINEAR_API_KEY is not set, stop and tell the user: "Set the LINEAR_API_KEY environment variable to your Linear API token and try again."
+
+**Step 1a** — Get the team ID:
+
+```bash
+curl -s -X POST https://api.linear.app/graphql \
+  -H "Authorization: $LINEAR_API_KEY" \
+  -H "Content-Type: application/json" \
+  -d '{"query": "{ teams(filter: { key: { eq: \"TEAM_KEY\" } }) { nodes { id key name } } }"}'
+```
+
+Replace `TEAM_KEY` with the parsed team key (e.g., "QUE").
+
+**Step 1b** — Fetch the issue using the team ID:
+
+```bash
+curl -s -X POST https://api.linear.app/graphql \
+  -H "Authorization: $LINEAR_API_KEY" \
+  -H "Content-Type: application/json" \
+  -d '{"query": "{ team(id: \"TEAM_UUID\") { issues(filter: { number: { eq: ISSUE_NUMBER } }) { nodes { id identifier title description priority state { name } labels { nodes { name } } project { name } } } }"}'
+```
+
+Replace `TEAM_UUID` with the id from Step 1a and `ISSUE_NUMBER` with the parsed number (e.g., 40).
+
+Display clearly:
+- **ID**: {identifier}
+- **Title**: {title}
+- **State**: {state.name}
+- **Priority**: {priority}
+- **Labels**: {labels}
+- **Project**: {project.name}
+- **Description**:
+  {description}
+
+If the issue state is "In Progress" or "Done", warn the user: "This issue is already {state.name}. Stopping to avoid duplicate work." Then stop.
+
+### Step 2: Evaluate and Clarify
+
+Read the issue carefully. Ask yourself: could an architect start work on this without asking follow-up questions?
+
+The architect needs to know:
+- What to build (goal is clear)
+- What's in scope and out of scope
+- Any technical constraints or decisions only the user can make
+
+If the issue is clear — ask NOTHING. Proceed to Step 3.
+
+If there are genuine gaps — ask ONLY about those specific gaps. One or two sharp questions. Not a template. Not a checklist. If the issue says "add dark mode" with no other context, ask what components need it and whether there's a design system to follow. If the issue says "fix the auth bug where users get logged out after 5 minutes" that is clear enough — ask nothing.
+
+Wait for answers before proceeding.
+
+### Step 3: Branch Setup
+
+Create the feature branch:
+
+```bash
+git checkout main
+git pull origin main
+git checkout -b feature/$ARGUMENTS-$(echo "{title}" | tr '[:upper:]' '[:lower:]' | sed 's/[^a-z0-9]/-/g' | sed 's/--*/-/g' | cut -c1-50)
+git branch --show-current
+```
+
+Confirm you are on the feature branch before continuing.
+
+### Step 4: Comment on Linear Issue
+
+Add a comment to the Linear issue to mark it as in progress:
+
+```bash
+curl -s -X POST https://api.linear.app/graphql \
+  -H "Authorization: $LINEAR_API_KEY" \
+  -H "Content-Type: application/json" \
+  -d '{"query": "mutation { commentCreate(input: { issueId: \"ISSUE_UUID\", body: \"Pipeline started — architect building implementation plan.\" }) { success } }"}'
+```
+
+Replace `ISSUE_UUID` with the `id` field (UUID) from the Step 1b response.
+
+### Step 5: Hand Off
+
+Tell the orchestrator:
+
+> "Issue $ARGUMENTS is ready. Branch: {branch-name}. Starting pipeline: architect → developer(s) → QA → reviewer → git-workflow."
+
+Then invoke the architect agent to create the implementation plan for this issue, passing it the issue title, description, and any clarifications from Step 2.
+
+## Notes
+- LINEAR_API_KEY must be set as an environment variable
+- The architect creates the implementation PRD — this skill does not
+- If the issue is already In Progress or Done, warn the user and stop
+- Never set the issue to "Queued" — that was the old runner pattern

package/.claude/commands/issue-rework.md

@@ -0,0 +1,272 @@
+---
+description: Create a rework document from tester feedback on a previously completed issue
+argument-hint: <ISSUE-ID e.g. SMA-62>
+---
+
+# Rework Issue from Tester Feedback
+
+## Issue to Rework
+
+Rework the Linear issue: `$ARGUMENTS`
+
+### Rename Session
+
+Before doing anything else, rename this Claude Code session:
+
+```
+/rename rework-$ARGUMENTS-{M}-{D}
+```
+
+For example, if the issue is SMA-62 and today is March 16: `/rename rework-SMA-62-3-16`
+
+### Step 0: Branch Setup (MANDATORY — DO THIS FIRST)
+
+**CRITICAL: You MUST create a feature branch before doing ANY other work. The project enforces feature branches — committing or pushing on `main` will be BLOCKED by hooks, wasting API calls. Do NOT skip this step.**
+
+1. If not already on `main`, switch to it:
+
+```bash
+git checkout main
+```
+
+2. Pull the latest changes:
+
+```bash
+git pull origin main
+```
+
+3. Create a feature branch for the rework doc:
+
+```bash
+git checkout -b docs/rework-$ARGUMENTS
+```
+
+4. Verify you are on the new branch (NOT `main`):
+
+```bash
+git branch --show-current
+```
+
+The output MUST show `docs/rework-$ARGUMENTS`. Do NOT proceed until confirmed.
+
+If `git checkout main` fails because of uncommitted changes on another branch, run `git stash` first, then `git checkout main`. Do NOT force-checkout or discard work.
+
+### Step 1: Fetch the Issue + Tester Comments
+
+Linear's top-level `issues` query and `issueVcSearch` are unreliable with personal API keys. Always use team-scoped queries.
+
+Parse the team key and issue number from `$ARGUMENTS` (e.g., "SMA-62" -> team key "SMA", number 62).
+
+**Step 1a** — Get the team ID:
+
+```bash
+curl -s -X POST https://api.linear.app/graphql \
+  -H "Authorization: $LINEAR_API_KEY" \
+  -H "Content-Type: application/json" \
+  -d '{"query": "{ teams(filter: { key: { eq: \"TEAM_KEY\" } }) { nodes { id key name } } }"}'
+```
+
+Replace `TEAM_KEY` with the parsed team key (e.g., "SMA").
+
+**Step 1b** — Fetch the issue with ALL comments:
+
+```bash
+curl -s -X POST https://api.linear.app/graphql \
+  -H "Authorization: $LINEAR_API_KEY" \
+  -H "Content-Type: application/json" \
+  -d '{"query": "{ team(id: \"TEAM_UUID\") { issues(filter: { number: { eq: ISSUE_NUMBER } }) { nodes { id identifier title description priority estimate state { name } labels { nodes { name } } project { name } team { name key } comments { nodes { body createdAt user { name } } } } } }"}'
+```
+
+Display the issue summary:
+- **ID**: {identifier}
+- **Title**: {title}
+- **State**: {state.name} (should be "Human: Changes Needed")
+- **Labels**: {labels}
+
+**Step 1c** — Extract tester feedback:
+
+From the comments, identify the **tester's feedback comments** — these are comments that came AFTER any "PRD ready" or CI-related system comments, from non-system users (not "Glen Barnhardt" system comments about CI or PRD). Display them clearly:
+
+> **Tester Feedback:**
+> {each tester comment with date and author}
+
+If there are no tester comments, STOP and tell the user: "No tester feedback found on $ARGUMENTS. Is the feedback in a different location?"
+
+If $LINEAR_API_KEY is not set, stop and tell the user: "Set the LINEAR_API_KEY environment variable to your Linear API token and try again."
+
+### Step 2: Load Context
+
+Read the following to understand what was already built:
+
+1. **Original PRD** — `.claude/prds/$ARGUMENTS.md` (if it exists)
+2. **CLAUDE.md** — project root, for architecture context
+3. **Git history** — find commits and PRs related to this issue:
+
+```bash
+git log --oneline --all --grep="$ARGUMENTS" | head -20
+```
+
+Also check for merged PRs:
+
+```bash
+gh pr list --state merged --search "$ARGUMENTS" --json number,title,mergedAt --limit 5
+```
+
+This tells the rework agent what code already exists on main.
+
+### Step 3: Quick Dialog
+
+This is NOT the full 5-question PRD dialog. The tester's comment IS the spec. Ask only what's needed:
+
+**Question 1 — Scope Confirmation:**
+Present a summary to the user:
+
+> Based on tester feedback, here's what needs to change:
+> {bullet list of each issue from tester comments}
+>
+> The original PRD specified: {relevant section from original PRD}
+>
+> Is this the complete scope, or is there additional context?
+
+**Question 2 (only if needed) — Ambiguity:**
+If any tester comment is unclear or could be interpreted multiple ways, ask ONE targeted follow-up. Otherwise, skip this.
+
+Do NOT ask about architecture, testing philosophy, or acceptance criteria — derive those from the original PRD and codebase patterns.
+
+### Step 4: Generate Rework Document
+
+Determine the rework filename:
+- If `.claude/prds/$ARGUMENTS-rework.md` does NOT exist: use `$ARGUMENTS-rework.md`
+- If it exists, find the highest existing number and increment: `$ARGUMENTS-rework-2.md`, `$ARGUMENTS-rework-3.md`, etc.
+
+Create the rework document at `.claude/prds/{filename}`:
+
+```markdown
+# $ARGUMENTS Rework: {Title}
+
+## Tester Feedback
+
+{Verbatim tester comments with dates — this is the source of truth for what to fix}
+
+## What Was Already Implemented
+
+- PR #{number}: {title} (merged {date})
+- Key files modified: {list from PR}
+
+## What Needs to Change
+
+{For each piece of tester feedback, specify:}
+
+### {Feedback item 1 summary}
+
+**Problem**: {what the tester reported}
+**Root cause**: {your analysis of why this happened — reference specific files/lines if possible}
+**Fix**: {what needs to change, with specific file paths}
+
+### {Feedback item 2 summary}
+
+{same structure}
+
+## Files to Modify
+
+{List each file with its absolute path and what changes are needed}
+
+## Testing Requirements
+
+- [ ] {specific test derived from tester feedback — e.g., "Verify audit log menu item appears for admin role"}
+- [ ] {regression test — ensure original functionality still works}
+- [ ] All CI checks pass: type-check, lint, test, build
+
+## Acceptance Criteria
+
+- [ ] {directly maps to each piece of tester feedback}
+- [ ] {e.g., "Lead Form Event field saves selected value and persists on form submission"}
+- [ ] No TypeScript errors, no lint warnings
+- [ ] Code follows existing project patterns
+```
+
+### Step 5: Commit, Push, and Update Linear
+
+1. Stage and commit the rework doc:
+
+```bash
+git add .claude/prds/$ARGUMENTS-rework*.md
+git commit -m "docs: add rework document for $ARGUMENTS"
+```
+
+2. Push the branch:
+
+```bash
+git push -u origin docs/rework-$ARGUMENTS
+```
+
+3. Add a comment to the Linear issue:
+
+```bash
+curl -s -X POST https://api.linear.app/graphql \
+  -H "Authorization: $LINEAR_API_KEY" \
+  -H "Content-Type: application/json" \
+  -d '{"query": "mutation { commentCreate(input: { issueId: \"ISSUE_UUID\", body: \"Rework document ready: .claude/prds/{REWORK_FILENAME}\" }) { success } }"}'
+```
+
+Replace `ISSUE_UUID` with the UUID from Step 1, and `{REWORK_FILENAME}` with the actual filename used.
+
+### Step 6: Set Linear Status to Todo
+
+Get the "Todo" state ID:
+
+```bash
+curl -s -X POST https://api.linear.app/graphql \
+  -H "Authorization: $LINEAR_API_KEY" \
+  -H "Content-Type: application/json" \
+  -d '{"query": "{ team(id: \"TEAM_UUID\") { states(filter: { name: { eq: \"Todo\" } }) { nodes { id name } } } }"}'
+```
+
+Update the issue status:
+
+```bash
+curl -s -X POST https://api.linear.app/graphql \
+  -H "Authorization: $LINEAR_API_KEY" \
+  -H "Content-Type: application/json" \
+  -d '{"query": "mutation { issueUpdate(id: \"ISSUE_UUID\", input: { stateId: \"TODO_STATE_ID\" }) { success issue { id state { name } } } }"}'
+```
+
+### Step 7: Cleanup (MANDATORY — DO THIS LAST)
+
+1. Switch back to `main`:
+
+```bash
+git checkout main
+```
+
+2. Delete the local rework doc branch:
+
+```bash
+git branch -D docs/rework-$ARGUMENTS
+```
+
+3. Verify you are on `main`:
+
+```bash
+git branch --show-current
+```
+
+## HARD STOP
+
+After Step 7 completes and you have verified you are on `main`, say EXACTLY:
+
+> "Rework document created for $ARGUMENTS. Run /issue-prd $ARGUMENTS to kick off the implementation pipeline."
+
+Then STOP. Do not:
+- Summarize the rework document contents
+- Offer to implement the fix
+- Suggest next steps for this issue
+- Ask if the user wants to proceed with implementation
+
+## Notes
+
+- Step 0 and Step 7 are non-negotiable — skipping them wastes API calls and leaves dirty state
+- The dialog in Step 3 should be FAST — the tester's comment is the spec, not a starting point for a new PRD
+- The rework document must be self-contained enough that an agent can implement without asking questions
+- Always reference the original PRD for context but do NOT copy its full content into the rework doc
+- If the issue has been reworked before, reference previous rework docs so the agent knows the history