メニュー
Trigger and monitor a LexiQuest deploy to Azure Static Web Apps. Runs after `/local-smoke` passes. Push-to-main auto-deploys via GitHub Actions; this skill watches that run, tails logs, and probes the live URL until green. Never pushes force. Never rotates secrets.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Fast pre-deploy sanity check that boots the real SWA + Functions stack locally against Azurite and exercises the critical-path routes end-to-end. Use before pushing to main (which auto-deploys) and whenever the API composition roots or static-web-app config change. Never touches real storage.
Start the full LexiQuest local development environment (Azurite + Vite + SWA CLI). ALWAYS kills any existing dev processes first, then starts clean — never tries to attach to a running stack. Use when the user wants to run the app locally, test a feature in the browser, or diagnose a runtime error that unit tests cannot catch.
Kill all LexiQuest local dev processes (Azurite + Vite + Functions host + SWA CLI) and free their ports. Idempotent — safe to run when nothing is running. Use when the user wants a clean slate, when orphaned background processes are holding ports, or as a teardown after a debug session.
Update the /docs folder at the end of a coding task. Use immediately after a `/tdd-cycle` completes (or any meaningful workspace change) to refresh the changelog, setup, getting-started, user guide, and PROGRESS as needed. Invoke proactively — documentation staleness is a bug.
Scan the LexiQuest workspace for secrets, credentials, and common security leaks. Runs as a mandatory step in every /tdd-cycle (after COVER, before UPDATE DOCS) and also on-demand when the user asks for a security check. Blocks the cycle if anything is found — never "note and continue".
Run the LexiQuest TDD cycle for a coding task. Use at the start of ANY code change (feature, bug fix, refactor) to write and get approval on a plan, then produce the RED test list, confirm failing tests, scaffold testable seams, implement to GREEN, refactor, and verify tier-appropriate coverage + requirement traceability. Invoke proactively — never write production code without running this first.
| name | deploy-swa |
| description | Trigger and monitor a LexiQuest deploy to Azure Static Web Apps. Runs after `/local-smoke` passes. Push-to-main auto-deploys via GitHub Actions; this skill watches that run, tails logs, and probes the live URL until green. Never pushes force. Never rotates secrets. |
LexiQuest deploys via push-to-main → GitHub Actions → Azure Static Web
Apps. The skill does NOT own the deploy — GitHub Actions does. What this
skill does:
/local-smoke has passed on the current HEAD.main (if not already pushed)./tdd-cycle + /docs-update + /local-smoke all pass and the
user says "deploy" / "ship" / "push".git push --force. If a remote is ahead, stop and ask the user.Confirm all of the following before pushing:
cd /Users/waldo/SourceCode/Community/LexiQuest
git status # clean working tree expected
git branch # must be on main
If not on main, stop. Feature branches get a PR; /deploy-swa is for
main-branch ships only.
Confirm the most recent /local-smoke run was against the commit that's
about to ship — ask the user if uncertain.
git push origin main
Capture the commit SHA that was just pushed:
DEPLOY_SHA="$(git rev-parse HEAD)"
Use gh to locate the workflow run triggered by this commit:
gh run list --commit "$DEPLOY_SHA" --limit 1 --json databaseId,status,conclusion,workflowName,url
Expect one row for the SWA deploy workflow. If none appears within ~30s, the workflow either didn't trigger (check .github/workflows/ exists and is valid) or the push never reached GitHub.
Save the run ID:
RUN_ID="$(gh run list --commit "$DEPLOY_SHA" --limit 1 --json databaseId -q '.[0].databaseId')"
gh run watch "$RUN_ID" --exit-status
gh run watch blocks and tails status until the run completes. --exit-status makes it exit non-zero if the run fails — the skill must then stop and report the failure, not swallow it.
If the run fails:
gh run view "$RUN_ID" --log-failed
Once the run is green, hit the live SWA URL. The URL should be stored in
docs/setup.md after Phase 1; pull it from
there or from Azure (az staticwebapp show) — do not hardcode.
LIVE_URL="<from docs/setup.md>"
curl -sS "$LIVE_URL/api/hello" | tee /tmp/lexiquest-deploy-probe.json
Phase-appropriate probes:
/api/hello returns { "msg": "Hello from LexiQuest" }./api/users/public returns 4 objects with no hashes./api/me round-trips.The probe is deliberately shallow — end-to-end behavior is covered by
/local-smoke against Azurite. Live probes are "did the bundle land and
can Azure reach storage".
Post one short summary in chat:
/deploy-swa PASS
- Commit: <short-sha> — <commit-subject>
- GH Actions run: <url>
- Deploy duration: <Xm Ys>
- Live probe (<Nth phase endpoint>): <200 OK, shape as expected>
- Live URL: <url>
On failure, report:
/deploy-swa FAIL
- Commit: <short-sha>
- GH Actions run: <url>
- Failed job: <job-name>
- Failing step: <step-name>
- Log tail (secrets redacted):
<last ~30 lines>
- Next step: <check env vars | check SWA app settings | fix code | ...>
On success, add a one-liner to docs/changelog.md:
- Deployed <short-sha> to SWA (<phase milestone if applicable>).
On failure, log the attempt too:
- Attempted deploy <short-sha> — failed at <step-name>. Rolled back / held. See <GH run URL>.
A deploy is not done when the push is done. It is done when the live URL serves the expected response. The probe in Step 4 is the gate.