skills/dev-ci-ifttt-notify/SKILL.md
Add IFTTT webhook notification to a GitHub Actions CI/CD workflow. Use when: (1) User wants CI deploy notifications via IFTTT, (2) User says 'add IFTTT notify', 'CI notification', or 'deploy notification', (3) User wants webhook notifications for build/deploy status.
npx skillsauth add takazudo/claude-resources dev-ci-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 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.
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.