Repository navigation
Conversation
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
There was a problem hiding this comment.
🟡 Changes recommended
Unresolved deployment correctness issues can prevent successful setup or push code to the wrong app.
5 open issues
What changed in this PR
Moves the deploy-app skill’s manual Heroku setup into a user-run script, keeping the master key outside the agent’s context.
Changes:
- Automates Heroku provisioning, deployment, health checks, and GitHub environment variables.
- Supports configurable production tiers and Sentry DSN.
- Updates setup instructions and warns against deploying before variables exist.
| File | Description |
|---|---|
| lib/generators/rolemodel/heroku/templates/deploy-app/SKILL.md | Delegates setup to the script and updates deployment guidance. |
| lib/generators/rolemodel/heroku/templates/deploy-app/heroku_setup | Adds provisioning and deployment automation. |
| lib/generators/rolemodel/heroku/README.md | Documents the user-run setup script. |
Review effort: Balanced
| Never let the deploy workflow run before they exist: with an empty `HEROKU_APP_NAME` | ||
| the deploy action creates a randomly named Heroku app instead of failing. |
| [[ $BUILDPACKS == *heroku/nodejs* ]] || heroku buildpacks:add --index 1 heroku/nodejs -a "$APP" | ||
| [[ $BUILDPACKS == *heroku/ruby* ]] || heroku buildpacks:add heroku/ruby -a "$APP" |
| KEY_FILE=config/credentials/$STAGE.key | ||
| [[ -f $KEY_FILE ]] || KEY_FILE=config/master.key |
| heroku labs:enable runtime-dyno-metadata -a "$APP" | ||
|
|
||
| step "Deploy $(git branch --show-current)" | ||
| git remote get-url "heroku-$STAGE" >/dev/null 2>&1 || heroku git:remote -a "$APP" -r "heroku-$STAGE" |
| step "Health check" | ||
| URL=$(heroku apps:info -a "$APP" --json | jq -r '.app.web_url' | sed 's:/*$::') | ||
| for _ in {1..12}; do | ||
| STATUS=$(curl -s -o /dev/null -w '%{http_code}' "$URL/up") |
There was a problem hiding this comment.
I left the technical details to Copilot, so do please evaluate whether any of its suggestions are valid.
I know it was already here, but have you considered whether the deploy skill belongs in rolemodel-rails, or if it should be moved to RoleModel/skills now that there is a built-in install_skill command? Also acceptable to merge this now and come back later, if you decide it makes sense to move.
More pressing question:
Is there anything in the setup script that should not be open-source, relative to our monitoring and health check services?

Why?
The deploy-app skill's Heroku phase was a dozen hand-run commands, and the user had to run the master key step themselves partway through. This moves that phase into one script the user runs, so the key never reaches the agent and a failed run can simply be run again.
With an empty
HEROKU_APP_NAME, the deploy action creates a randomly named Heroku app instead of failing. That happened on boundaryless_circ_planner, so the skill now warns against running the workflow before the variables exist.What Changed
heroku_setupbeside the deploy-app skill, covering Phase 4 and the GitHub variablesPre-merge checklist
Notes
Please don't commit version changes within your PR. Versioning is managed through the GitHub Workflow.
I used the script to deploy boundaryless_circ_planner staging, and that app's deploy workflow ran green. I also checked each
herokuflag and JSON field against the CLI 10.11.0 manifest and source, and ran staging and production end to end against stub CLIs.Screenshots
N/A — no UI changes
🤖 Generated with Claude Code