whendone-plus

$npx mdskill add EliasOulkadi/shokunin/whendone-plus

Notify users when long-running terminal commands finish.

  • Solves the need to wait idly for slow commands like builds or tests.
  • Depends on terminal command execution and desktop notification system.
  • Monitors command duration and triggers notification if it exceeds 10 seconds.
  • Sends a desktop notification with the command's exit code on completion.

SKILL.md

.github/skills/whendone-plusView on GitHub ↗
---
name: whendone-plus
description: Automatically notify the user when long-running terminal commands finish (npm test, docker build, git push, etc.). The agent monitors command execution and sends a desktop notification on completion if the command ran longer than threshold (default 10s). Use when user asks to "notify me when done", "desktop notification when command finishes", "alert when done", or "tell me when this completes". Do NOT use for interactive commands (vim, nano, less, htop), commands that always complete in <5s, or streaming commands (tail -f).
triggers:
  - "notify me when done"
  - "desktop notification"
  - "alert when done"
  - "tell me when this completes"
  - "notify when finished"
  - "ping me when"
  - "remind me when"
  - "notification on completion"
  - "when done"
negatives:
  - "interactive commands"
  - "vim"
  - "nano"
  - "less"
  - "htop"
  - "streaming commands"
  - "tail -f"
  - "short commands"
license: MIT
compatibility: opencode
metadata:
  workflow: automation
  audience: developers
  version: "3.0.0"
---


# WhenDone Plus

Automatically notify when long-running commands complete.

## How It Works

1. User runs a long command (e.g. `npm test`, `docker build`, `git push`)
2. The agent monitors the command execution time
3. If the command runs longer than the threshold (default 10s), the agent notifies the user on completion
4. Exit code is passed through

## Workflow

### Step 1: Detect long-running command

Identify commands likely to exceed threshold:
- `npm test`, `npm run test`, `npx playwright test`
- `docker build`, `docker compose up`, `docker compose down`
- `git push`, `git pull`, `git clone`
- `pip install`, `npm install`, `pnpm install`, `yarn install`
- `cargo build`, `cargo test`, `go build`, `dotnet build`
- Custom scripts, database migrations, data processing pipelines
- `ffmpeg`, `rsync`, `scp`, large file transfers

### Step 2: Monitor execution

Start a background timer when the command begins. Track:
- Elapsed wall-clock time
- Peak memory usage (if available)
- Child process tree (for pipeline awareness)

### Step 3: Notify on completion

Basic notification format:
```
✅ "Command finished: npm test completed in 142s (exit 0)"
❌ "Command finished: docker build failed in 89s (exit 1)"
```

Include:
- Command name (first word + key args)
- Execution time (rounded to seconds)
- Exit code (success/failure)
- Optional: memory peak, output file path if redirected

### Step 4: Handle edge cases

- Commands completing under 10s: no notification (too fast to matter)
- Interactive/TUI commands (vim, nano, htop): skip (user is watching)
- Piped commands (e.g. `npm test | grep error`): monitor the pipeline, not the first process
- Backgrounded commands (`&`): notify on background process completion
- Chained commands (`;`): notify per-segment or in aggregate
- Commands killed by signal: notify with signal name (e.g. "killed by SIGTERM")

## Notification Mechanisms

### Windows Toast Notification (PowerShell)

```powershell
Add-Type -AssemblyName System.Windows.Forms
$balloon = New-Object System.Windows.Forms.NotifyIcon
$balloon.Icon = [System.Drawing.SystemIcons]::Information
$balloon.BalloonTipTitle = "Command Complete"
$balloon.BalloonTipText = "npm test finished in 142s (exit 0)"
$balloon.Visible = $true
$balloon.ShowBalloonTip(5000)
Start-Sleep -Seconds 5
$balloon.Dispose()
```

### Terminal Bell (cross-platform)

```bash
echo -e "\a"                         # ASCII bell character
printf '\a'                          # POSIX
```

### BurntToast Module (Windows 10/11)

```powershell
Import-Module BurntToast
New-BurntToastNotification -Text "Command Complete", "npm test finished in 142s (exit 0)"
```

### macOS Notification

```bash
osascript -e 'display notification "npm test finished in 142s" with title "Command Complete"'
terminal-notifier -title "Command Complete" -message "npm test finished in 142s"
```

### Linux Notification (notify-send)

```bash
notify-send "Command Complete" "npm test finished in 142s"
```

## Error Handling

| Error | Cause | Fix |
|-------|-------|-----|
| Notification never fires | Command completed under threshold | Expected. Threshold is 10s by default. |
| Wrong exit code reported | Shell pipeline masking failures | Use `$PIPESTATUS` in bash, `$LASTEXITCODE` in PowerShell |
| Notification module missing | BurntToast/notify-send not installed | Fallback to terminal bell or `Write-Host` |
| Silent failure on background job | Job detached from monitor process | Use `Wait-Job` in PowerShell, `wait` in bash |
| Double notification | Parent and child process both fire | Track PID tree, notify only on root process |
| Desktop notification blocked | System focus assist or DnD mode | Fallback to terminal output with colored exit code |
| Command output lost | Notification intercepts stdout/stderr | Always tee or capture output before monitoring |

## Anti-Patterns

| Mistake | Fix |
|---------|-----|
| Notify for every command | Only if >10s threshold |
| Breaking pipes | Ensure stdout/stderr passthrough |
| Breaking exit codes | Pass through original exit code |
| Notifications for interactive commands | Skip if TUI detected |
| Notify and then continue working | Wait for notification confirmation or user acknowledgment |
| Assuming notification system is available | Always have a text-only fallback (Write-Host) |
| Monitoring subprocess instead of pipeline | Track the entire pipeline PID group |

## Customization

| Setting | Default | Description |
|---------|---------|-------------|
| Threshold | 10s | Minimum command duration to trigger notification |
| Notification style | Toast | toast, bell, or both |
| Include exit code | Yes | Show pass/fail in notification |
| Show elapsed time | Yes | Include duration in notification text |
| Fallback on failure | Bell | What to do if toast notification fails |

## Checklist

- [ ] Notification method matches platform (BurntToast on Windows, terminal-notifier on macOS, notify-send on Linux)
- [ ] Threshold duration set appropriately (default 10s — not too short, not too long)
- [ ] Not used for interactive commands (vim, nano, htop, less)
- [ ] Custom message includes the command name and result (success/fail)
- [ ] Fallback: terminal bell or Write-Host if notification fails

## Sources

- Windows Toast API (docs.microsoft.com/en-us/windows/apps/design/shell/tiles-and-notifications)
- BurntToast PowerShell module (github.com/Windos/BurntToast)
- notify-send (Linux Desktop Notifications Specification)
- terminal-notifier (github.com/julienXX/terminal-notifier)
- macOS osascript display notification (developer.apple.com)
- POSIX terminal bell (ASCII 0x07)
- Shell job control (bash manual, PowerShell about_Jobs)

More from EliasOulkadi/shokunin

SkillDescription
Aesthetic Web Design>
agent-toolsRun 150+ AI apps via inference.sh CLI - image generation, video creation, LLMs, search, 3D, Twitter automation. Models: FLUX, Veo, Gemini, Grok, Claude, Seedance, OmniHuman, Tavily, Exa, OpenRouter, and many more. Use when running AI apps, generating images/videos, calling LLMs, web search, or automating Twitter. Triggers: inference.sh, infsh, ai model, run ai, serverless ai, ai api, flux, veo, claude api, image generation, video generation, openrouter, tavily, exa search, twitter api, grok
api-forgeDesign REST/GraphQL APIs with OpenAPI 3.1, error handling, pagination, rate limiting, webhooks, and idempotency. Use when user asks to design an API, create endpoints, define REST/GraphQL schema, or generate OpenAPI spec. Do NOT use for database schema design, frontend API integration, or non-HTTP protocols (gRPC, WebSocket, MQTT).
auth-architectImplement authentication and authorization with OWASP Top 10 standards, OAuth 2.0 + OIDC, WebAuthn/Passkeys, session management, and RBAC/ABAC. Use when user asks to implement login, signup, authentication, authorization, JWT, OAuth, SSO, passkeys, MFA, or role-based access. Do NOT use for API key management (use api-forge), encryption at rest, or network-level security (firewalls, WAF).
business-proposalsGenerate sales outreach sequences, proposals, SOWs, investor pitch decks, and RFP responses. Covers cold email sequences, proposal structure, pricing tiers (Good-Better-Best), scope of work with exclusions, and 10-slide pitch deck.
ci-cdDesign CI/CD pipelines for GitHub Actions, GitLab CI, and CircleCI with matrix builds, test sharding, caching, Docker layer caching, OIDC auth, deployment strategies (rolling, blue-green, canary), auto-rollback, self-hosted runners, and environment protection with manual approvals. Use when user asks to set up CI/CD, write a pipeline, configure GitHub Actions/GitLab CI/CircleCI, automate deployments, or set up build/test/deploy workflows. Do NOT use for Dockerfile authoring (use docker), K8s manifests (use kubernetes), or Terraform config (use terraform).
communication>
component-forgeBuild production-grade components for React, Vue 3, and Svelte 5 with all states (loading, empty, error, success, idle), TypeScript strict, WCAG 2.2 accessibility, server components (RSC), and compound component patterns. Includes scaffold script, reference patterns, and template files for React and Vue. Use when user asks to create a UI component, frontend module, or design system component. Do NOT use for page layouts (use landing-craft), routing, or state management architecture (global stores).
comprehensive-reviewComprehensive code review using parallel specialized subagents. If a PR URL is provided, fetches PR details and can post comments. If no PR is provided, reviews the diff between the current branch and its base branch plus any uncommitted changes. CRITICAL: this skill is costly, don't use it unless user explicitly requested to use it.
cross-reviewDelegate code review to a subagent running a specific model. Use ONLY when user explicitly names a model to review changes ("review with opus", "use sonnet to review", "review with gemini"). The root agent reconstructs changes from conversation history and spawns a subagent with the code-review skill using the specified model. Do NOT use for general code review (use code-review skill instead), for reviewing PRs from git history, or when no model is specified by the user.