dev-gha-ifttt-notify
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'.
Best use case
dev-gha-ifttt-notify is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
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'.
Teams using dev-gha-ifttt-notify should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/dev-gha-ifttt-notify/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How dev-gha-ifttt-notify Compares
| Feature / Agent | dev-gha-ifttt-notify | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
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'.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# IFTTT Deploy Notification for GitHub Actions
Add an IFTTT Webhooks notification job to a GitHub Actions workflow. Sends mobile push notifications on deploy success/failure.
## Architecture
```
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.
## Setup Steps
### 1. IFTTT Applet
1. Go to https://ifttt.com/maker_webhooks
2. Create a new applet:
- **Trigger**: Webhooks -> "Receive a web request"
- **Event name**: Choose a name (e.g., `deploy_notify`, project name, etc.)
- **Action**: Notifications -> "Send a notification from the IFTTT app" (or any other action)
- **Notification template**: `{{Value1}}: {{Value2}}` (status + commit info). `{{Value3}}` contains the workflow run URL
3. Copy the webhook URL: `https://maker.ifttt.com/trigger/{EVENT_NAME}/with/key/{KEY}`
### 2. GitHub Repository Secret
Add the webhook URL as a repository secret:
```bash
gh secret set IFTTT_PROD_NOTIFY
# Paste: https://maker.ifttt.com/trigger/{EVENT_NAME}/with/key/{KEY}
```
### 3. Workflow Job
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.
#### Payload
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 |
#### Implementation Pattern
```yaml
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 @-
```
### Key Details
- **`if: always()`** on the job ensures it runs even when prior jobs fail or are cancelled
- **`if: env.IFTTT_PROD_NOTIFY != ''`** on the step silently skips when the secret is not configured
- **`jq -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 indefinitely
- **`needs` list** must include all jobs whose results you want to report on
### Adapting to Your Workflow
Adjust the `needs` list and status detection logic to match your workflow's job names. The pattern works with any number of jobs:
```yaml
# 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
```
### .env.example Entry
Add a commented reference in `.env.example` for documentation:
```bash
# 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
```
### Testing the Webhook
```bash
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/..."}'
```Related Skills
dev-ci-ifttt-notify
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.
zudoesa-articlify
Convert conversation context into an esa article via the zudoesa-writer subagent. ONLY invoke when the user explicitly asks — NEVER proactively propose. Triggers: 'write esa article', 'esa記事', 'esaに書いて', 'articlify for esa', or /zudoesa-articlify. Gathers context, creates a writing brief, delegates to the writer subagent.
zudoesa-apply-voice
Apply Takazudo's esa writing voice and vocabulary rules to text. Use when: (1) User wants to write/rewrite text in Takazudo's esa style, (2) User says 'apply voice', 'esa voice', 'esa文体で', 'esa風に書いて', '文体を適用', (3) User provides text to transform to esa style. Reads writing-style.md and vocabulary-rule.md from takazudo-esa-writing repo and applies the rules.
zudocg-articlify
Convert conversation context into a CodeGrid article via the zudocg-writer subagent. ONLY invoke when the user explicitly asks — NEVER proactively propose. Triggers: 'write codegrid article', 'CodeGrid記事', 'codegridに書いて', 'articlify for codegrid', or /zudocg-articlify. Gathers context, creates a writing brief, delegates to the writer subagent.
zudocg-apply-voice
Apply Takazudo's CodeGrid writing voice and vocabulary rules to text. Use when: (1) User wants to write/rewrite text in Takazudo's CodeGrid style, (2) User says 'apply voice', 'codegrid voice', 'codegrid文体で', 'codegrid風に書いて', '文体を適用', (3) User provides text to transform to CodeGrid style. Reads writing-style.md and vocabulary-rule.md from takazudo-codegrid-writing repo and applies the rules.
zpaper-articlify
Convert conversation context into a zpaper blog article via the zpaper-writer subagent. ONLY invoke when the user explicitly asks — NEVER proactively propose. Triggers: 'write zpaper article', 'zpaper記事', 'zpaperに書いて', 'articlify for zpaper', or /zpaper-articlify. Gathers context, creates a writing brief, delegates to the writer subagent.
zpaper-apply-voice
Apply Takazudo's zpaper blog writing voice and vocabulary rules to text. Use when: (1) User wants to write/rewrite text in Takazudo's zpaper style, (2) User says 'apply voice', 'zpaper voice', 'zpaper文体で', 'zpaper風に書いて', 'ブログ文体を適用', (3) User provides text to transform to zpaper style. Reads writing-style.md and vocabulary-rule.md from the zpaper repo and applies the rules.
xlsx
Spreadsheet creation, editing, and analysis. Use when working with .xlsx, .xlsm, .csv, .tsv files for: (1) Creating spreadsheets with formulas and formatting, (2) Reading or analyzing data, (3) Modifying existing spreadsheets while preserving formulas, (4) Data analysis and visualization, (5) Recalculating formulas.
x
Facade for development workflows. Routes on two axes: plan-first vs implement-now (escalates to /big-plan -a when the request needs research / decomposition / has unclear scope — the appended -a makes the plan chain into implementation in-session), then single vs multi on the ready-to-build fast paths (/x-as-pr single-topic, /x-wt-teams multi-topic parallel). Use when: (1) User says '/x' followed by dev instructions, (2) User wants to start development without choosing the workflow skill, (3) User says 'dev', 'implement', or 'build' with a task. Default option: -v (verify-ui). Review-loop (-l) is opt-in — without -l the downstream skill runs a single /deep-review pass. Forwards -a (autonomy/auto-chain) and -m (merge at the end + cleanup + CI watch) through every route; auto-fix of raised findings (-f) and issue-raising (-ri) are downstream defaults, with -nf/--no-fix and -nori/--no-raise-issues as the forwarded opt-outs. -a and -m are orthogonal — full hands-off end-to-end is -a -m.
x-wt-teams
Parallel multi-topic development using git worktrees, base branches, and Claude Code agent teams. Use when: (1) User wants to work on multiple related features in parallel, (2) User mentions 'worktree', 'base branch', 'parallel development', 'split into topics', or 'multi-topic'. FULLY AUTONOMOUS — creates worktrees, spawns teams, coordinates everything. Also supports Super-Epic child mode for [Epic] issues from /big-plan with '**Super-epic:** #N' markers (targets the super-epic base branch instead of main).
x-as-pr
Start a development workflow as a draft PR. Creates a NEW branch from the current branch, empty start commit, draft PR targeting the current branch, then implements. ALWAYS creates a new branch by default — produces a nested PR-on-PR when the current branch already has one. Use when: (1) User says 'dev as pr', (2) User wants a PR-first workflow before coding, (3) User passes -s/--stay to reuse the current branch instead of nesting, (4) User passes a GitHub issue URL to implement, (5) User passes --make-issue/--issue to create an issue first. Logs progress via issue comments when an issue is linked.
watch-ci
Watch GitHub PR CI checks in the background and notify on completion. Use when: (1) User wants to monitor CI/CD status, (2) User says 'watch CI', 'check CI', 'monitor checks', or 'wait for CI', (3) User wants to know when checks pass or fail. Runs a background gh polling shell loop (NOT a subagent — near-zero token cost), sends macOS notification on completion. Also handles merged PRs by watching the target branch CI.