From claude-resources
Adds IFTTT webhook notification job to GitHub Actions CI/CD workflows for deploy status alerts including success, failure reasons, and run links. Useful for mobile push notifications on builds/deploys.
npx claudepluginhub takazudo/claude-resources<IFTTT_WEBHOOK_URL>This skill uses the workspace's default tool permissions.
Add an IFTTT webhook notification job to a GitHub Actions workflow. The notification reports deploy status (succeeded, failed with reason, cancelled) along with a link to the workflow run.
Guides Next.js Cache Components and Partial Prerendering (PPR): 'use cache' directives, cacheLife(), cacheTag(), revalidateTag() for caching, invalidation, static/dynamic optimization. Auto-activates on cacheComponents: true.
Guides building MCP servers enabling LLMs to interact with external services via tools. Covers best practices, TypeScript/Node (MCP SDK), Python (FastMCP).
Share bugs, ideas, or general feedback.
Add an IFTTT webhook notification job to a GitHub Actions workflow. The notification reports deploy status (succeeded, failed with reason, cancelled) along with a link to the workflow run.
https://maker.ifttt.com/trigger/<event>/with/key/<key>)gh CLI must be available for setting the repo secretIFTTT notifications (especially mobile push) typically only show value1 prominently. Put all critical info in value1 so the notification is self-explanatory at a glance:
| Field | Content | Example |
|---|---|---|
value1 | <project>: <emoji> <status> | my-app: ✅ Deploy succeeded |
value2 | Run URL for tapping through | https://github.com/.../runs/123 |
value3 | (unused / empty) | "" |
Do NOT split project name and status across value1/value2 — the user should see the full picture from the notification title alone.
Read .github/workflows/ to find the target workflow (typically the production deploy workflow). Identify all job names and their dependency chain.
Add a notify job at the end of the workflow with this pattern:
notify:
name: Notify
needs: [<all-prior-jobs>]
runs-on: ubuntu-latest
timeout-minutes: 2
if: always()
steps:
- name: Send IFTTT notification
env:
IFTTT_PROD_NOTIFY: ${{ secrets.IFTTT_PROD_NOTIFY }}
run: |
if [ -z "$IFTTT_PROD_NOTIFY" ]; then
echo "IFTTT_PROD_NOTIFY not set, skipping notification"
exit 0
fi
JOB1_RESULT="${{ needs.<job1>.result }}"
JOB2_RESULT="${{ needs.<job2>.result }}"
DEPLOY_RESULT="${{ needs.<deploy-job>.result }}"
# ... one variable per job in needs
# Determine status — check deploy success first, then failures in pipeline order
if [ "$DEPLOY_RESULT" = "success" ]; then
STATUS="✅ Deploy succeeded"
elif [ "$JOB1_RESULT" = "failure" ]; then
STATUS="❌ <Job1 description> failed"
elif [ "$JOB2_RESULT" = "failure" ]; then
STATUS="❌ <Job2 description> failed"
elif [ "$DEPLOY_RESULT" = "failure" ]; then
STATUS="❌ Deploy failed"
else
STATUS="⚠️ Deploy result: job1=$JOB1_RESULT job2=$JOB2_RESULT deploy=$DEPLOY_RESULT"
fi
curl -s -o /dev/null \
-H "Content-Type: application/json" \
-d "{\"value1\":\"<project-name>: $STATUS\",\"value2\":\"https://github.com/${{ github.repository }}/actions/runs/${{ github.run_id }}\",\"value3\":\"\"}" \
"$IFTTT_PROD_NOTIFY"
Key design points:
value1 contains project name + status — notification is readable without opening it✅, ❌, ⚠️) for instant visual scanning on mobileneeds lists ALL prior jobs so status of each can be checkedif: always() ensures notification runs regardless of success/failureIFTTT_PROD_NOTIFY allows silent skip if secret not configuredcurl -s -o /dev/null to suppress output noise in CI logsgh secret set IFTTT_PROD_NOTIFY --body "<webhook-url>"
Verify with gh secret list.
Add a line to the workflow's header comment describing the notification step.