菜单
Builds Lark monthly attendance approval/reminder payloads and, when asked, runs the full attendance flow through a NyxID service instead of direct Lark credentials.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Aevatar scheduling & workflow automation: scheduled_agent_creator (cron/one-shot), the long-running task automation playbook, workflow creation semantics (Scope Workflow vs Ornn publish), agent_builder lifecycle, and scheduled-run credential lifetimes (5-minute broker token at fire) with a token_expired triage protocol.
Aevatar channel & delivery how-to: capability tools (code_execute, nyxid_proxy, GitHub PAT fallback, channel bots), token_expired/401 credential triage for capability tools, LLM route selection slash commands, channel_registrations (staged Lark provisioning), and agent_delivery_targets binding.
Configure and prove Aevatar codex_exec for one NyxID account, choosing either operator-managed OpenSandbox or a private NyxID node-backed SSH service. Use for managed allowlist/binding readiness, node registration, forced-command hardening, service binding, Codex authentication/workspace configuration, mandatory public-sample verification, or diagnosing managed sandbox and private SSH failures.
Mount and run harmless Aevatar workflows that prove codex_exec works through either the operator-managed OpenSandbox target or a private NyxID node-backed SSH target. Use after configuring managed access or a personal node, before real tasks, and when diagnosing identity, allowlist, binding, sandbox, service, principal, or Codex runner failures.
Decide — honestly — whether a thing the user wants to build on Aevatar is possible, what its prerequisites are, or why it cannot be done, BEFORE anyone starts building. Use this first whenever a user describes a goal rather than a concrete artifact — "can aevatar do X", "I want a bot that…", "build me something that posts to Twitter / reads my GitHub / replies on Telegram", "is it possible to…", "automate … every day", "let Lark Base trigger a workflow". It teaches the one hard premise (every third-party capability is brokered by NyxID), the two distinct surfaces (outbound connector vs inbound channel), external HTTP trigger options such as Lark Base automation, how to check what is actually connectable, the prerequisite for each capability class, what is host-gated (and so not self-serve), and what is genuinely impossible without new NyxID/Aevatar platform work — so you can negotiate scope and give the user a straight answer plus next steps instead of over-promising. It scopes; it does not build (hand off to
Entry point, panorama, and router for the entire Aevatar skill family — load this FIRST whenever someone wants to build, run, publish, schedule, externally trigger, or operate anything on Aevatar ("create an agent team", "make a workflow / member", "publish or bind a service", "register it with NyxID", "set up a recurring / cron run", "invoke my service", "let Lark Base trigger my workflow"), wants to know whether something is even possible ("can Aevatar do X?", "能不能用 aevatar 实现"), or just wants to know what Aevatar can do. It teaches the object model (scope → team → member[workflow|script|gagent] → service → schedule/external trigger), how to authenticate as a NyxID-bearer REST client, how to resolve your scope, and the two caller modes (client REST vs in-session server-side tools). It does not do the work itself — it routes you to the right companion skill (feasibility-advisor, workflow-authoring, team-builder, service-publisher, scheduler, plus diagnostics probes and the safety-net fallback), held together
| name | monthly-attendance-approval-payload-builder |
| version | 1.1 |
| description | Builds Lark monthly attendance approval/reminder payloads and, when asked, runs the full attendance flow through a NyxID service instead of direct Lark credentials. |
| metadata | {"category":"plain","tag":["aevatar","s-capability","attendance","lark-approval","nyxid-service-runner","payload-builder"],"clawdbot":{"emoji":"calendar","files":["references/*","scripts/*"]}} |
Use this skill for monthly attendance approval and reminder flows. It supports two modes:
Do not ask the user for raw Lark tokens, app secrets, tenant access tokens, or OAuth credentials. Use NyxID service/proxy access for all Lark I/O.
Use this mode after the caller has fetched monthly attendance records from Lark Bitable through NyxID or another trusted connector.
Required for approval mode:
recordsyearmonthdocUrlsubmitterIdapprovalCodeOptional fields include widget ids and notification user id. Defaults are defined in references/monthly-attendance-contract.md.
For reminder mode, pass:
{
"mode": "reminder",
"year": 2026,
"month": 5,
"notifyUserId": "user_id"
}
Use this mode when the caller provides a NyxID service slug, for example:
{
"serviceSlug": "monthly-attendance-cn",
"mode": "approval"
}
The NyxID service is the configuration and credential boundary. It must hold the Lark credential and attendance configuration. The runner must call Lark only through NyxID proxy for that service.
Expected NyxID service default headers are defined in references/nyxid-service-runner-contract.md.
Runner behavior:
mode: "approval" or omitted: read Bitable attendance records, build the approval payload, submit POST /open-apis/approval/v4/instances, then optionally send a DM notification if x-attendance-notify-user-id is configured.mode: "reminder": build and send the reminder card to x-attendance-notify-user-id.dryRun: true: read/build only and do not submit approval or send messages.Never call Lark directly. Never send or log downstream credentials. Never ask the user to paste Lark secrets.
Payload-builder mode returns JSON with:
statsdescriptionlark.approvalBodylark.notificationBodylark.reminderBodyRunner mode returns JSON with:
serviceSlugmodedryRunsubmittednotifiedinstanceCode when approval submission returns oneapprovalResponse / notificationResponse when calls are madepayloadFollow references/monthly-attendance-contract.md. If executing code is allowed, use scripts/build_monthly_attendance_payload.js as the payload reference implementation and scripts/run_monthly_attendance_nyxid_service.js for the full NyxID-backed runner.
Do not invent attendance records, submitter ids, approval definitions, Lark credentials, receiver ids, or service slugs.