// Run prek, run tests, resolve issues, commit, push, then monitor the deploy workflow and resolve any deploy failures. Use when user says "ship it", "commit and deploy", "push and deploy", or "land this".
| name | ship-it |
| description | Run prek, run tests, resolve issues, commit, push, then monitor the deploy workflow and resolve any deploy failures. Use when user says "ship it", "commit and deploy", "push and deploy", or "land this". |
End-to-end workflow: run prek checks, run tests, fix failures, commit, push, and monitor the GitHub Actions deploy pipeline through to a healthy production readiness check.
This skill orchestrates the full ship cycle. Do NOT skip steps.
gh CLI authenticated (gh auth status)git configured with push access to the remoteprek installed (brew install j178/tap/prek)Reply with "LFG 🚀 I'll ship it" to acknowledge the user's intent.
cd <workspace> && prek run --all-files
Prek hooks may auto-fix issues (ruff lint --fix, ruff format, trailing whitespace, end-of-file).
If prek fails:
Check if hooks auto-fixed files — many hooks modify files in place. Re-run prek:
prek run --all-files
If the second run passes — the auto-fixes resolved everything. Proceed to Step 2.
If the second run still fails — manual intervention needed:
.gitignore the large fileKeep re-running prek until all hooks pass.
Do NOT proceed to Step 2 until prek passes cleanly.
Run the full test suite locally. This catches runtime errors (template rendering, import issues, dependency upgrades) that static checks cannot detect.
cd <workspace>/api && uv run pytest tests/ -x --tb=short
cd <workspace>/packages/learn-to-cloud-shared && uv run pytest tests/ -x --tb=short
cd <workspace>/apps/verification-functions && uv run python -c "import function_app"
If tests fail:
Do NOT proceed to commit until all tests pass. No exceptions.
git status
git diff --stat
Always stage ALL changes. Never cherry-pick files. ship it means ship everything.
git add -A
git diff --cached --stat
If the user provided a commit message, use it directly.
If no commit message was provided, generate one based on the changes:
git commit -m "<type>: <concise description>"
Conventional commit types: feat:, fix:, refactor:, docs:, style:, test:, chore:
Ask the user for a commit message if the intent is ambiguous.
git push
If rejected (behind remote):
git pull --rebase && git push
Note: The deploy workflow triggers on pushes to main. If on a different branch, inform the user that deployment won't trigger automatically.
After pushing to main, the deploy.yml workflow triggers automatically.
sleep 5
run_id=$(gh run list --workflow=deploy.yml --limit 1 --json databaseId --jq '.[0].databaseId')
gh run view "$run_id" --json status,conclusion,url,displayTitle
while true; do
gh run view "$run_id" \
--json status,conclusion,url,displayTitle \
--jq '{title: .displayTitle, status: .status, conclusion: .conclusion, url: .url}'
status=$(gh run view "$run_id" --json status --jq .status)
if [ "$status" = "completed" ]; then
break
fi
sleep 15
done
conclusion=$(gh run view "$run_id" --json conclusion --jq .conclusion)
test "$conclusion" = "success"
This keeps deploy monitoring output compact. Exit code 0 = success, non-zero = failure. Use full logs only when the run fails.
If the workflow succeeds — report success and the deploy URL. Done!
If the workflow fails:
run_id=$(gh run list --workflow=deploy.yml --limit 1 --json databaseId --jq '.[0].databaseId')
gh run view $run_id --log-failed
| Pattern | Fix |
|---|---|
ruff lint errors | (cd api && uv run ruff check --fix . ../packages/learn-to-cloud-shared), commit & push |
ruff-format | (cd api && uv run ruff format . ../packages/learn-to-cloud-shared), commit & push |
ty type errors | Fix type errors, commit & push |
pytest / FAILED | (cd api && uv run pytest tests/ -x) and (cd packages/learn-to-cloud-shared && uv run pytest tests/ -x), fix, commit & push |
| Pattern | Fix |
|---|---|
Error acquiring the state lock | Extract Lock ID, cd infra && terraform force-unlock -force <lock-id>, re-run |
AuthorizationFailed | Check OIDC deployment secrets/variables and Azure RBAC — not fixable locally |
ResourceNotFound | terraform refresh or re-import |
| Pattern | Fix |
|---|---|
docker build fails | Fix Dockerfile or pyproject.toml, commit & push |
Smoke test curl -f fails | Check docker logs, fix startup issue, commit & push |
| API readiness timeout | Check app logs: az containerapp logs show ... |
After fixing:
git add -A && git commit -m "fix: resolve deploy failure"git pushIf no code changes needed (e.g., state lock):
gh run rerun $run_id
gh run watch --exit-status
After a successful deploy:
curl -s https://<api-url>/health
curl -s https://<api-url>/ready
## Ship It: <branch-name>
### 1. Pre-commit
✅ All hooks passed / ❌ Failed → fixed → ✅ Passed on re-run
### 2. Stage
✅ X files staged
### 3. Commit
✅ `<commit-hash>` — `<commit-message>`
### 4. Push
✅ Pushed to `<branch>` on `origin`
### 5. Deploy Workflow
✅ Run #<id> — succeeded in X min / ❌ Failed (see step 6)
### 6. Deploy Fix (if needed)
❌ <failure reason> → fixed → ✅ Re-deployed successfully
### 7. Production Health
✅ /health — healthy | /ready — ready
Attach relevant Copilot session lessons, mistakes, decisions, model details, token usage, MCP servers, and skills to a GitHub issue comment. Use when the user asks to add session notes, lessons learned, Copilot notes, mistakes, or implementation details to an issue.
Run ruff lint, ruff format, ty type-check, shared/API tests, start the API, smoke test endpoints, then kill the API. Use after editing Python files to catch errors before commit.
Map concepts, issues, and code changes in this repo to specific chapters and pages of Fluent Python, 2nd edition (Luciano Ramalho). Use when the user wants to ground a task in the underlying Python concept, e.g. "where is this in fluent python?", "what should I read for
Undo local submissions for DevOps and Verify Journal API Implementation so you can re-test verification flows. Also supports custom requirement IDs and user scoping.
Reset verification submissions for a user in production. Use when user says "reset prod submissions", "reset phase X in prod", "undo prod verification", or "reset prod for <username>".
Debug GitHub Actions workflow failures and Terraform errors. Use when deployment failed, Terraform state lock, CI/CD pipeline errors, or troubleshooting deploy.yml.