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.
The payload layout follows the canonical IFTTT contract (convention C2) owned by /dev-ci-ifttt-notify — see that skill for the full rationale. Every skill posting to IFTTT_PROD_NOTIFY must use the same value1/value2/value3 layout.
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}} — already the full <project>: <emoji> <status> string, self-explanatory on its own. {{Value2}} carries the run URL (use it if the action has a link field); {{Value3}} is unusedhttps://maker.ifttt.com/trigger/{EVENT_NAME}/with/key/{KEY}If an applet already exists with the old
{{Value1}}: {{Value2}}template, its IFTTT-side notification template must be updated to match — the applet lives in IFTTT, not in this repo, so this is a manual user action.
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. This follows the canonical contract owned by /dev-ci-ifttt-notify:
| 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.
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
RUN_URL="${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}"
# Send webhook — value1 = "<project>: <emoji> <status>", value2 = run URL, value3 unused
jq -n \
--arg v1 "<project-name>: $STATUS" \
--arg v2 "$RUN_URL" \
'{value1: $v1, value2: $v2, value3: ""}' | \
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 dynamic values)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
# value1 = "<project-name>: $STATUS"
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": "my-app: ✅ succeeded", "value2": "https://github.com/owner/repo/actions/runs/123", "value3": ""}'
tools
Acceptance gate for a branch produced by an OpenAI Codex CLI run — usually Codex implementing a /big-plan epic that was handed off to it. Codex reports the work 'done' (or the user flags it WIP with corrections); this skill confirms the branch actually fulfils the original spec, fixes what falls short, and routes larger discoveries into GitHub issues. Use when: (1) User says '/finalize-codex-work', 'finalize codex work', 'confirm the codex work', 'check the codex branch', or 'codex said it's done', (2) A branch is the result of a Codex CLI session and needs verification against its spec issue/PR, (3) After assigning a /big-plan epic to Codex CLI. Pass -m/--merge to run /pr-complete -c at the end.
tools
Read a Figma design node directly from a share URL via the Figma REST API — no Dev Mode subscription, no MCP, no desktop app. Renders the node to PNG and dumps its full style/layout JSON so the design can be described, compared, or implemented. Use whenever the user gives a Figma design URL (figma.com/design/... or /file/...) and wants to see, read, inspect, reference, or implement that node — including `/fig-url-refer <url>`. This is the URL-based counterpart to `/figrefer` (which needs a Dev-plan desktop MCP); prefer this one when the input is a URL rather than a live desktop selection.
tools
Sync the user's Claude Code workflow skills into the OpenAI Codex CLI settings repo ($HOME/.codex) as Codex-native ports, fix the Codex .gitignore for new local state, then commit and push. Use when: (1) user says '/dev-codex-sync-settings-from-claude', 'sync codex settings', 'sync claude skills to codex', 'port skills to codex', or 'update codex from claude'; (2) after updating ~/.claude workflow skills (big-plan, x, x-as-pr, x-wt-teams) and Codex should catch up; (3) the $HOME/.codex repo has drifted behind $HOME/.claude. The ports are condensed Codex-native REWRITES, never file copies.
development
Analyze a video file (mov, mp4, webm, etc.) or a YouTube video by extracting still frames with ffmpeg and reading them chronologically with vision — Claude cannot ingest video files directly. Use whenever the user provides a video file path or YouTube URL and wants to know what happens in it: "read this video", "watch this video", "check this recording", "what happens in this .mov/.mp4", analyzing a screen recording of a UI bug, or verifying UI behavior captured in a video, even if they don't name this skill.