agent operations skill risk: low
Feishu Lark Notification Sender
Defines a skill that sends push or interactive notifications to Feishu/Lark based on ~/.codex/feishu.json config, supporting webhook cards and bidirectional replies via a bridge UR…
- External action: medium
SKILL 1 file
SKILL.md
---
name: feishu-notify
description: "Send notifications to Feishu/Lark. Internal utility used by other skills, or manually via /feishu-notify. Supports push-only (webhook) and interactive (bidirectional) modes. Use when user says ///\"/u53d1/u98de/u4e66///\", ///\"notify feishu///\", or other skills need to send status updates."
---
# Feishu/Lark Notification
Send a notification: **$ARGUMENTS**
## Overview
This skill provides Feishu/Lark integration for ARIS. It is designed as an **internal utility** — other skills call it at key events (experiment done, review scored, checkpoint waiting). It can also be invoked manually.
**Zero-impact guarantee**: If no `feishu.json` config exists, this skill does nothing and returns silently. All existing workflows are completely unaffected.
## Configuration
The skill reads `~/.codex/feishu.json`. If this file does not exist, **all Feishu functionality is disabled** — skills behave exactly as before.
### Config Format
```json
{
"mode": "push",
"webhook_url": "https://open.feishu.cn/open-apis/bot/v2/hook/YOUR_WEBHOOK_ID",
"interactive": {
"bridge_url": "http://localhost:5000",
"timeout_seconds": 300
}
}
```
### Modes
| Mode | `"mode"` value | What it does | Requires |
|------|----------------|--------------|----------|
| **Off** | `"off"` or file absent | Nothing. Pure CLI as-is | Nothing |
| **Push only** | `"push"` | Send webhook notifications at key events. Mobile push, no reply | Feishu bot webhook URL |
| **Interactive** | `"interactive"` | Full bidirectional. Approve/reject from Feishu, reply to checkpoints | [feishu-claude-code](https://github.com/joewongjc/feishu-claude-code) running |
## Workflow
### Step 1: Read Config
```bash
cat ~/.codex/feishu.json 2>/dev/null
```
- **File not found** → return silently, do nothing
- **`"mode": "off"`** → return silently, do nothing
- **`"mode": "push"`** → proceed to Step 2 (push)
- **`"mode": "interactive"`** → proceed to Step 3 (interactive)
### Step 2: Push Notification (webhook)
Send a rich card to the Feishu webhook:
```bash
curl -s -X POST "$WEBHOOK_URL" \
-H "Content-Type: application/json" \
-d '{
"msg_type": "interactive",
"card": {
"header": {
"title": {"tag": "plain_text", "content": "TITLE"},
"template": "COLOR"
},
"elements": [
{"tag": "markdown", "content": "BODY"}
]
}
}'
```
**Card templates by event type:**
| Event | Title | Color | Body |
|-------|-------|-------|------|
| `experiment_done` | Experiment Complete | `green` | Results table, delta vs baseline |
| `review_scored` | Review Round N: X/10 | `blue` (≥6) / `orange` (<6) | Score, verdict, top 3 weaknesses |
| `checkpoint` | Checkpoint: Waiting for Input | `yellow` | Question, options, context |
| `error` | Error: [type] | `red` | Error message, what failed |
| `pipeline_done` | Pipeline Complete | `purple` | Final summary, deliverables |
| `custom` | Custom | `blue` | Free-form message from $ARGUMENTS |
**Return immediately after curl** — push mode never waits for a response.
### Step 3: Interactive Notification (bidirectional)
Interactive mode uses [feishu-claude-code](https://github.com/joewongjc/feishu-claude-code) as a bridge:
1. **Send message** to the bridge:
```bash
curl -s -X POST "$BRIDGE_URL/send" \
-H "Content-Type: application/json" \
-d '{"type": "EVENT_TYPE", "title": "TITLE", "body": "BODY", "options": ["approve", "reject", "custom"]}'
```
2. **Wait for reply** (with timeout):
```bash
curl -s "$BRIDGE_URL/poll?timeout=$TIMEOUT_SECONDS"
```
Returns: `{"reply": "approve"}` or `{"reply": "reject"}` or `{"reply": "user typed message"}` or `{"timeout": true}`
3. **On timeout**: Fall back to `AUTO_PROCEED` behavior (proceed with default option).
4. **Return the user's reply** to the calling skill so it can act on it.
### Step 4: Verify Delivery
- **Push mode**: Check curl exit code. If non-zero, log warning but do NOT block the workflow.
- **Interactive mode**: If bridge is unreachable, fall back to push mode (if webhook configured) or skip silently.
## Helper Function (for other skills)
Other skills should use this pattern to send notifications:
```markdown
### Feishu Notification (if configured)
Check if `~/.codex/feishu.json` exists and mode is not "off":
- If **push** mode: send webhook notification with event summary
- If **interactive** mode: send notification and wait for user reply
- If **off** or file absent: skip entirely (no-op)
```
**This check is always guarded.** If the config file doesn't exist, the skill skips the notification block entirely — zero overhead, zero side effects.
## Event Catalog
Skills send these events at these moments:
| Skill | Event | When |
|-------|-------|------|
| `/auto-review-loop` | `review_scored` | After each round's review score |
| `/auto-review-loop` | `pipeline_done` | Loop complete (positive or max rounds) |
| `/auto-paper-improvement-loop` | `review_scored` | After each round's review score |
| `/auto-paper-improvement-loop` | `pipeline_done` | All rounds complete |
| `/run-experiment` | `experiment_done` | Screen session finishes |
| `/idea-discovery` | `checkpoint` | Between phases (if interactive) |
| `/idea-discovery` | `pipeline_done` | Final report ready |
| `/monitor-experiment` | `experiment_done` | Results collected |
| `/research-pipeline` | `checkpoint` | Between workflow stages |
| `/research-pipeline` | `pipeline_done` | Full pipeline complete |
## Key Rules
- **NEVER block a workflow** because Feishu is unreachable. Always fail open.
- **NEVER require Feishu config** — all skills must work without it.
- **Config file absent = mode off.** No error, no warning, no log.
- **Push mode is fire-and-forget.** Send curl, check exit code, move on.
- **Interactive timeout = auto-proceed.** Don't hang forever waiting for a reply.
- **Respect `AUTO_PROCEED`**: In interactive mode, if the user doesn't reply within timeout, use the same auto-proceed logic as the calling skill.
- **No secrets in notifications.** Never include API keys, tokens, or passwords in Feishu messages.
INPUTS
- $ARGUMENTS REQUIRED
notification message or event payload
e.g. experiment complete
REQUIRED CONTEXT
- $ARGUMENTS for message content
- ~/.codex/feishu.json config
OPTIONAL CONTEXT
- event type for card template
ROLES & RULES
- NEVER block a workflow because Feishu is unreachable. Always fail open.
- NEVER require Feishu config — all skills must work without it.
- Config file absent = mode off. No error, no warning, no log.
- Push mode is fire-and-forget. Send curl, check exit code, move on.
- Interactive timeout = auto-proceed. Don't hang forever waiting for a reply.
- Respect AUTO_PROCEED: In interactive mode, if the user doesn't reply within timeout, use the same auto-proceed logic as the calling skill.
- No secrets in notifications. Never include API keys, tokens, or passwords in Feishu messages.
EXPECTED OUTPUT
- Format
- plain_text
- Constraints
- return silently if config absent or mode off
- fire-and-forget for push mode
- return user reply or timeout for interactive mode
SUCCESS CRITERIA
- Send notifications correctly according to mode
- Handle missing or off config by doing nothing silently
- Never block workflows
- Fall back gracefully on errors or timeouts
FAILURE MODES
- May block workflow if fail-open rule is ignored
- May hang on interactive mode without proper timeout handling
- May leak secrets if rule is violated
EXAMPLES
Includes config JSON example, multiple curl command examples, event tables, card templates table, and helper function pattern.
CAVEATS
- Dependencies
- Requires ~/.codex/feishu.json config file
- Requires feishu-claude-code bridge for interactive mode
- Missing context
- Target runtime environment or shell assumptions (bash vs others)
- Exact version or schema of feishu.json expected
- Ambiguities
- Does not specify exact logging format or destination when curl fails in push mode.
- Unclear how AUTO_PROCEED default option is determined or passed from calling skill.
QUALITY
- OVERALL
- 0.65
- CLARITY
- 0.90
- SPECIFICITY
- 0.85
- REUSABILITY
- 0.35
- COMPLETENESS
- 0.80
IMPROVEMENT SUGGESTIONS
- Add explicit placeholders such as {{EVENT_TYPE}} and {{BODY}} in the helper function section to improve reusability as a template.
- Include a minimal success criteria checklist at the end (e.g., 'returns silently when config absent').
USAGE
Copy the prompt above and paste it into your AI of choice — Claude, ChatGPT, Gemini, or anywhere else you're working. Replace any placeholder sections with your own context, then ask for the output.
MORE FOR AGENT
- Local Documentation Online Sync Automatoragentoperations
- HashiCorp Packer Golden Image Expertagentoperations
- ML Experiment GPU Deployment Workflowagentoperations
- Codex Training Metrics Monitoragentoperations
- Context Optimization Techniques Guideagentoperations
- Issue Triage State Machineagentoperations
- ML Experiment Results Monitoragentoperations
- DOCX Document Creation Editing Guideagentoperations
- Repo Agent Skills Configuration Setupagentoperations
- Git Worktree Isolated Workspace Setupagentoperations
- Agent Context Compression Strategiesagentoperations
- Parallel Agent Dispatcher for Independent Tasksagentoperations
- Scientific Computing Resource Detectoragentoperations
- PPTX File Handling Skill Guideagentoperations
- Interactive QA GitHub Issue Fileragentoperations
- Sprint Retrospective Facilitatoragentoperations
- Agent Skill Writing Guideagentoperations
- Brilliant Directories Rube MCP Automation Guideagentoperations
- Istio Linkerd Service Mesh Expertagentoperations
- Machine Learning Experiment Monitoragentoperations
- Benchling Python SDK Integrationagentoperations
- Blackbaud Automation via Rube MCPagentoperations
- DigitalOcean Automation via Rube MCPagentoperations
- Service Mesh Architecture Expertagentoperations
- WandB Training Metrics Health Checkeragentoperations