菜单
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.