skills/dev-gha-ifttt-notify/SKILL.md
Add IFTTT webhook notification to a GitHub Actions workflow for mobile push notifications on deploy success/failure. Use when: (1) Adding deploy notifications to CI/CD, (2) Setting up IFTTT webhook in GitHub Actions, (3) User mentions 'IFTTT notify', 'deploy notification', 'push notification for CI'.
npx skillsauth add takazudo/claude-resources dev-gha-ifttt-notifyInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Add an IFTTT Webhooks notification job to a GitHub Actions workflow. Sends mobile push notifications on deploy success/failure.
GitHub Actions workflow completes
-> notify job (if: always())
-> Collect job results from prior jobs
-> Determine status string
-> POST JSON to IFTTT Webhooks URL
-> IFTTT triggers mobile push notification
The notification is silently skipped when the secret is not set, making it safe to add without requiring all contributors to configure IFTTT.
deploy_notify, project name, etc.){{Value1}}: {{Value2}} (status + commit info). {{Value3}} contains the workflow run URLhttps://maker.ifttt.com/trigger/{EVENT_NAME}/with/key/{KEY}Add the webhook URL as a repository secret:
gh secret set IFTTT_PROD_NOTIFY
# Paste: https://maker.ifttt.com/trigger/{EVENT_NAME}/with/key/{KEY}
Add a notify job at the end of the workflow. It must needs all prior jobs and use if: always() to run regardless of success/failure.
IFTTT Webhooks accepts value1, value2, value3:
| Field | Content |
| -------- | ---------------------------------------------------- |
| value1 | Status string (e.g., "succeeded", "failed (build)") |
| value2 | Short commit info ({7-char SHA} {message}) |
| value3 | GitHub Actions workflow run URL |
notify:
name: Deploy Notification
needs: [quality, build, e2e-full, deploy] # adjust to your job names
if: always()
runs-on: ubuntu-latest
timeout-minutes: 5
steps:
- name: Notify via IFTTT
if: env.IFTTT_PROD_NOTIFY != ''
env:
IFTTT_PROD_NOTIFY: ${{ secrets.IFTTT_PROD_NOTIFY }}
run: |
# Collect results from prior jobs
QUALITY="${{ needs.quality.result }}"
BUILD="${{ needs.build.result }}"
E2E="${{ needs.e2e-full.result }}"
DEPLOY="${{ needs.deploy.result }}"
# Determine status (check deploy success first, then failures in order)
if [ "$DEPLOY" = "success" ]; then
STATUS="succeeded"
elif [ "$QUALITY" = "failure" ]; then
STATUS="failed (quality checks)"
elif [ "$BUILD" = "failure" ]; then
STATUS="failed (build)"
elif [ "$E2E" = "failure" ]; then
STATUS="failed (E2E tests)"
elif [ "$DEPLOY" = "failure" ]; then
STATUS="failed (deploy)"
else
STATUS="cancelled"
fi
# Build commit info
COMMIT_MSG=$(git log -1 --format='%s' "${{ github.sha }}" 2>/dev/null || echo "Deploy")
SHORT_SHA=$(echo "${{ github.sha }}" | cut -c1-7)
RUN_URL="${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}"
# Send webhook
jq -n \
--arg v1 "$STATUS" \
--arg v2 "$SHORT_SHA $COMMIT_MSG" \
--arg v3 "$RUN_URL" \
'{value1: $v1, value2: $v2, value3: $v3}' | \
curl -sf -X POST "$IFTTT_PROD_NOTIFY" \
-H 'Content-Type: application/json' \
-d @-
if: always() on the job ensures it runs even when prior jobs fail or are cancelledif: env.IFTTT_PROD_NOTIFY != '' on the step silently skips when the secret is not configuredjq -n builds the JSON payload safely (no shell injection from commit messages)curl -sf fails silently (-s) and returns non-zero on HTTP errors (-f)timeout-minutes: 5 prevents the notification job from hanging indefinitelyneeds list must include all jobs whose results you want to report onAdjust the needs list and status detection logic to match your workflow's job names. The pattern works with any number of jobs:
# Simple workflow with just build + deploy
needs: [build, deploy]
# ...
if [ "$DEPLOY" = "success" ]; then
STATUS="succeeded"
elif [ "$BUILD" = "failure" ]; then
STATUS="failed (build)"
elif [ "$DEPLOY" = "failure" ]; then
STATUS="failed (deploy)"
else
STATUS="cancelled"
fi
Add a commented reference in .env.example for documentation:
# IFTTT webhook for production deploy notifications (GitHub Actions)
# Create at: https://ifttt.com/maker_webhooks
# IFTTT_PROD_NOTIFY=https://maker.ifttt.com/trigger/{event}/with/key/xxxxxx
curl -sf -X POST "https://maker.ifttt.com/trigger/{EVENT}/with/key/{KEY}" \
-H 'Content-Type: application/json' \
-d '{"value1": "succeeded", "value2": "abc1234 test commit", "value3": "https://github.com/..."}'
development
Link Claude Code skill names mentioned in a CodeGrid article (data/{series}/{n}.md) to the author's public claude-resources repo, pinned to the latest commit hash so links don't rot. Use when: (1) user says 'linkify cc resources', 'link the skills', 'link skill names', or invokes /dev-linkify-cc-resources; (2) editing a CodeGrid article that mentions `/commits`, `/pr-complete`, `/skill-creator` or other Claude Code skills and they should point to claude-resources. Only links skills that actually exist in the public repo; skips hypothetical examples and code blocks.
development
Second opinion from Claude Opus on a plan or approach. Use when: (1) Planning phase of /big-plan needs a higher-quality review than /codex-2nd / /gco-2nd / /gcoc-2nd, (2) User says 'opus 2nd' or 'opus opinion', (3) Wanting Anthropic's larger model to critique a plan. Spawns a general-purpose Agent with model: opus that reads the plan file and returns structured feedback. Anthropic quota — not free.
tools
AI-based testing via subagent + a per-task test-flow skill. Use when the user wants to verify something that mechanical assertions can't fully capture — image recognition, visual size/position comparison, animation smoothness, multi-step manual flows that need AI judgment. Triggers: 'AI-based test', 'AI test', 'visual verify', 'image recognition test', 'manual operation test', 'human-eye check', 'verify visually', 'compare screenshots', 'looks the same', 'looks correct'. The skill's job is to (1) author a focused test-flow skill that captures the exact procedure + verdict criteria, then (2) dispatch a verification subagent via the Agent tool that loads BOTH the test-flow skill AND a browser-driving skill (/verify-ui primary, /headless-browser fallback) so the subagent has clear context and consistent verdicts. NEVER uses `claude -p` — subagent dispatch goes through the Agent tool exclusively.
development
End-of-workflow audit of touched GitHub issues, PRs, and branches via a Sonnet subagent. Use when: (1) /big-plan, /x-as-pr, or /x-wt-teams finishes its main work and needs to verify every touched resource is in the right state (closed when done, kept when ongoing, deleted when dead), (2) User says 'cleanup resources', 'audit cleanup', or 'check what should be closed', (3) A long workflow ends and the manager wants a structured paper trail of what it closed/kept/deleted. Auto-execute by default — the Sonnet agent proposes, the manager (you) executes safe actions and prints a final report.