Codex CLI Task
LeoYeAI/openclaw-master-skills
Launch OpenAI Codex CLI async in background with automatic delivery to Telegram/WhatsApp.
Verify lemon features against a running (or disposable) instance using the cheapest sufficient tier: DIRECT (attach/RPC + control-plane WS + bus observation, no Telegram), FAKE TELEGRAM (hermetic…
$ npx skills add z80dev/lemon --skill verify-lemon -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install z80dev/lemon verify-lemon --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ git clone --depth 1 https://github.com/z80dev/lemon.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/verify-lemon .claude/skills/verify-lemon && rm -rf skills-srcUse ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.
Claude Code skills documentation · loads skills from .claude/skills/
Install the "verify-lemon" agent skill from https://github.com/z80dev/lemon/tree/main/.claude/skills/verify-lemon into .claude/skills/verify-lemon/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "verify-lemon", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/z80dev/lemon/tree/main/.claude/skills/verify-lemonType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add z80dev/lemon --skill verify-lemon -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install z80dev/lemon verify-lemon --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/z80dev/lemon.git skills-src && mkdir -p .agents/skills && cp -r skills-src/.claude/skills/verify-lemon .agents/skills/verify-lemon && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "verify-lemon" agent skill from https://github.com/z80dev/lemon/tree/main/.claude/skills/verify-lemon into .agents/skills/verify-lemon/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "verify-lemon", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add z80dev/lemon --skill verify-lemon -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install z80dev/lemon verify-lemon --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/z80dev/lemon.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/.claude/skills/verify-lemon .cursor/skills/verify-lemon && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "verify-lemon" agent skill from https://github.com/z80dev/lemon/tree/main/.claude/skills/verify-lemon into .cursor/skills/verify-lemon/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "verify-lemon", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/z80dev/lemon.git --path .claude/skills/verify-lemon--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add z80dev/lemon --skill verify-lemon -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install z80dev/lemon verify-lemon --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/z80dev/lemon.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/.claude/skills/verify-lemon .gemini/skills/verify-lemon && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "verify-lemon" agent skill from https://github.com/z80dev/lemon/tree/main/.claude/skills/verify-lemon into .gemini/skills/verify-lemon/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "verify-lemon", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install z80dev/lemon verify-lemonInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add z80dev/lemon --skill verify-lemon -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/z80dev/lemon.git skills-src && mkdir -p .github/skills && cp -r skills-src/.claude/skills/verify-lemon .github/skills/verify-lemon && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "verify-lemon" agent skill from https://github.com/z80dev/lemon/tree/main/.claude/skills/verify-lemon into .github/skills/verify-lemon/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "verify-lemon", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add z80dev/lemon --skill verify-lemon -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install z80dev/lemon verify-lemon --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/z80dev/lemon.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/.claude/skills/verify-lemon .opencode/skills/verify-lemon && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "verify-lemon" agent skill from https://github.com/z80dev/lemon/tree/main/.claude/skills/verify-lemon into .opencode/skills/verify-lemon/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "verify-lemon", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
verify-lemonVerify lemon features against a running (or disposable) instance using the cheapest sufficient tier: DIRECT (attach/RPC + control-plane WS + bus observation, no Telegram), FAKE TELEGRAM (hermetic…
Verify Lemon is an agent skill from z80dev/lemon. Verify lemon features against a running (or disposable) instance using the cheapest sufficient tier: DIRECT (attach/RPC + control-plane WS + bus observation, no Telegram), FAKE TELEGRAM (hermetic transport via LemonChannels.Telegram.FakeAPI), or LIVE TELEGRAM (scripts/telegramdriver.py against the real bot). Use for feature verification, E2E checks, regression repros, and post-change validation.
Its SKILL.md is about 4k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.
It sits in Testing & QA, covering End-to-end testing. It works with Telegram. The repository describes itself as: BEAM-native platform for LLM agents: OTP-supervised per-run processes, pluggable engines and channels, contract-tested extension points, and a deterministic multi-agent sim arena. The licence is MIT.
Read from SKILL.md and the folder at commit 899e215. It shows what the files ask for, not the result of running them.
Pre-approves these tools, so the agent can use them without asking each time:
ReadGrepBashGlobWriteFrom allowed-tools in the SKILL.md frontmatter.
Shell commands in SKILL.md call:
uvFrom the folder's file list and the shell code blocks in SKILL.md.
No URLs in SKILL.md. Its commands use uv, which can reach the network depending on how they are called.
From URLs in SKILL.md, links to its own repository left out.
Names these keys or tokens, usually read from environment variables:
LEMON_TELEGRAM_BOT_TOKENTELEGRAM_BOT_TOKENFrom names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
Verify Lemon loads about 4k tokens when it runs. Until then it costs about 103 tokens; SKILL.md has 1,175 words of instructions outside code blocks.
Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.
The automated check noted patterns worth knowing about, such as sudo or a known installer.
allowed-tools: Read, Grep, Bash, Glob, WriteAutomated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.
The full file from z80dev/lemon at commit 899e215, republished under its MIT licence (© z80dev). 1,175 words, ~3,961 tokens.
.claude/skills/verify-lemon/SKILL.md (or your agent's skills folder).A runbook for verifying lemon behavior end to end. Work in three tiers and always prefer the lowest tier that can answer the question — most claims about routing, sessions, runs, delivery, and transport plumbing never need real Telegram.
| Tier | What it exercises | When |
|---|---|---|
| 1 DIRECT | Router, sessions, runs, bus events, control plane, delivery funnel | Default. Anything not Telegram-wire-specific |
| 2 FAKE TELEGRAM | The real Telegram transport + outbound, hermetically (no network) | Buttons, approvals, forum topics, markdown chunking, offset/poller semantics |
| 3 LIVE TELEGRAM | Real Bot API + real chat UX | Only for wire-level/UX claims the fake cannot prove |
If $ARGUMENTS is provided, scope the verification session to that feature.
Discover the node name and cookie from the beam process args (or fall back to
bin/lemon defaults: node lemon, cookie lemon_gateway_dev_cookie, control
plane 4040, web 4080, sim UI 4090):
More than one beam can be running (production + a disposable instance you
started, e.g. via scripts/product_smoke_local). NEVER pick one blindly —
list them, check the registered names, and select the node you actually mean:
epmd -names # every distributed node on this machine
ps -eo pid,args | grep beam.smp | grep -v grep | grep -o '\-sname [^ ]*'Then extract the cookie from the args of that specific node's process:
# -sname and -setcookie are adjacent "<flag>\n<value>" pairs in the beam args
NODE=lemon_bot # <- the node you chose above, not just "the first beam"
ARGS=$(ps -eo args | grep beam.smp | grep -v grep | grep -- "-sname[= ]$NODE" | head -1 | tr ' ' '\n')
COOKIE=$(echo "$ARGS" | grep -A1 '^-setcookie$' | tail -1) # NEVER echo/print thisThe read-only-on-production rule below depends on this selection being right:
if two nodes are up and you are about to mutate state, double-check you are
attached to the disposable one (its name will look like product_smoke_<pid>
or whatever --sname you passed).
Non-interactive one-shot eval on the node (the expression runs in a fresh
process on the remote node, so a subscribe + receive in one expression
works):
elixir --sname "probe_$$" --cookie "$COOKIE" \
--rpc-eval "$NODE@$(hostname -s)" \
'LemonCore.RunStore.list_sessions() |> length() |> IO.inspect(label: "sessions")'For interactive introspection use iex --sname attach_$$ --cookie "$COOKIE" --remsh "$NODE@$(hostname -s)".
Read-only by default. Against the user's production node, restrict
yourself to inspection (:sys.get_state/1, store reads, Bus.subscribe).
Anything that starts runs or sends messages belongs on a disposable instance.
An unauthenticated local connect gets the operator role with all scopes
(parse_role(_) -> :operator in LemonControlPlane.Auth.Authorize), so a
plain WS client can drive everything. Frames are
{"type":"req","id":...,"method":...,"params":{...}}; the server answers
hello-ok to connect and {"type":"res","id":...} to requests. Useful
methods (exact names from LemonControlPlane.Methods.Registry):
connect → hello-ok handshake (send {"client":{"id":...,"name":...}})chat.send — params sessionKey (required), prompt, optional agentId, queueModeagent — params prompt (required), session_key, model, idempotency_key; returns run_idagent.wait — params runId, timeoutMs; blocks until the run completesevents.subscribe — params topics (allowed: all, system, cron, nodes, presence, exec_approvals, channels, goals, plus run:<id> / runId)sessions.list — params limit, offset, agentIdlogs.tail — params limit (max 1000), levelMinimal probe with python-websockets (no install needed via uv; websocat works
too if present):
uv run --with websockets python - <<'PY'
import asyncio, json, websockets
async def main():
async with websockets.connect("ws://127.0.0.1:4040/ws") as ws:
async def req(id_, method, params):
await ws.send(json.dumps(
{"type": "req", "id": id_, "method": method, "params": params}))
async def recv_until(pred):
while True:
frame = json.loads(await ws.recv())
if pred(frame):
return frame
await req("c1", "connect", {"client": {"id": "verify", "name": "Verify"}})
await recv_until(lambda f: f.get("type") == "hello-ok")
await req("a1", "agent", {"prompt": "ping",
"session_key": "agent:verify:main"})
run = await recv_until(lambda f: f.get("type") == "res" and f.get("id") == "a1")
run_id = run["payload"]["run_id"]
await req("w1", "agent.wait", {"runId": run_id, "timeoutMs": 10000})
done = await recv_until(lambda f: f.get("type") == "res" and f.get("id") == "w1")
assert isinstance(done["payload"]["answer"], str), done
print("native run ok:", run_id)
asyncio.run(main())
PYFrom an attached node (or --rpc-eval), subscribe to
LemonCore.Bus topics — "run:<run_id>" and "session:<session_key>" carry
typed events (LemonCore.Event structs; catalog in
docs/platform/bus-events.md):
elixir --sname "probe_$$" --cookie "$COOKIE" --rpc-eval "$NODE@$(hostname -s)" '
LemonCore.Bus.subscribe("session:agent:verify:main")
receive do
%LemonCore.Event{} = event -> IO.inspect({event.type, event.ts_ms}, label: "event")
after
30_000 -> IO.puts("no event in 30s")
end
'Every LemonChannels.Dispatcher.dispatch/1 (success and failure) now emits:
[:lemon, :channels, :dispatch] — measurements %{count: 1, duration: native}, metadata %{channel_id, account_id, kind, intent_id, run_id, session_key, ok}LemonCore.Events.ChannelDelivery broadcast as :channel_delivery on the "channels" bus topic (fields: intent_id, run_id, session_key, channel_id, account_id, peer_kind, peer_id, thread_id, kind, text_preview ≤200 chars, ok, error, duration_ms, ts_ms)channel.delivery (camelCase payload), received by clients subscribed via events.subscribe with topics: ["channels"]So "did lemon actually deliver a reply to the channel?" is answerable without touching the channel:
elixir --sname "probe_$$" --cookie "$COOKIE" --rpc-eval "$NODE@$(hostname -s)" '
LemonCore.Bus.subscribe("channels")
receive do
%LemonCore.Event{type: :channel_delivery, payload: p} ->
IO.inspect({p.channel_id, p.kind, p.ok, p.text_preview}, label: "delivery")
after
30_000 -> IO.puts("no delivery in 30s")
end
'To exercise the router pipeline with a channel-shaped message (bypassing any
transport), build a %LemonCore.InboundMessage{} (enforced keys:
channel_id, account_id, peer, message) and hand it to
LemonChannels.Runtime.submit_inbound/1 — on a disposable/test instance
only, since this starts a real run and a real outbound delivery:
LemonChannels.Runtime.submit_inbound(%LemonCore.InboundMessage{
channel_id: "telegram",
account_id: "default",
peer: %{kind: :dm, id: "310001", thread_id: nil},
sender: %{id: "310001", username: "probe", display_name: "Probe"},
message: %{id: "1", text: "hello from probe", timestamp: System.system_time(:second), reply_to_id: nil},
raw: %{},
meta: %{}
})scripts/product_smoke_local boots a disposable
native executor against a deterministic Responses API fixture with no live
provider credentials.LemonPlatformTest.FakeLLM — scripted stream function for LemonAgent loops in ExUnit: FakeLLM.script([{:tool_call, "name", %{...}}, {:text, "answer"}]) yields a conforming provider stream, letting you assert tool-call handling without a network.scripts/product_smoke_local is the reference recipe (dev boot; --release
for CI-parity release boot). It is safe next to the production node: temp
HOME (never the real ~/.lemon), unique --sname product_smoke_$$ +
random cookie, dynamic free ports, isolated store/dotenv, kills only what it
started. Run it as-is for a green/red product check, or copy its isolation
levers for a custom instance:
scripts/product_smoke_local # PASS/FAIL + .lemon/proofs/product-smoke-local-latest.json
PRODUCT_SMOKE_KEEP_WORKDIR=1 scripts/product_smoke_local # keep workdir for debuggingPort-collision env knobs (all honored by config/runtime.exs):
LEMON_CONTROL_PLANE_PORT, LEMON_WEB_PORT, LEMON_SIM_UI_PORT,
LEMON_GATEWAY_HEALTH_PORT=0, LEMON_ROUTER_HEALTH_PORT=0 (0 = ephemeral
bind, avoids the running instance's fixed 4042), plus LEMON_STORE_PATH,
LEMON_DOTENV_DIR, LEMON_GATEWAY_NODE_NAME, LEMON_GATEWAY_NODE_COOKIE.
Prefer this tier for anything Telegram-specific that does not require the real wire: inline buttons/callback queries, approval flows, forum-topic threading, markdown chunking/rendering, poller offset semantics, file transfer — all without real-TG flakiness, rate limits, or credentials.
LemonChannels.Telegram.FakeAPI
(apps/lemon_channels/lib/lemon_channels/telegram/fake_api.ex) mirrors every
api_mod function the real transport calls. Select it exactly like an operator
would:
[gateway.telegram]
bot_token = "fake-token" # accepted, never recorded
api_mod = "LemonChannels.Telegram.FakeAPI"or in ExUnit, pass the module straight to the transport (see
apps/lemon_channels/test/lemon_channels/adapters/telegram/transport_fake_api_test.exs
for the full boot + RouterBridge stub recipe):
LemonChannels.Adapters.Telegram.Transport.start_link(
config: %{bot_token: "fake-token", api_mod: LemonChannels.Telegram.FakeAPI}
)Drive it — fabricate inbound, await captured outbound:
# Inbound: enqueue a realistic message update (auto bot_command entity for "/...")
FakeAPI.simulate_message(4242, "/status")
FakeAPI.simulate_message(-100_320_002, "in a topic", message_thread_id: 777)
FakeAPI.simulate_callback_query(4242, "approve|once", message_id: 1000)
# Outbound: block until the transport calls the API, then inspect
{:ok, %{fun: :send_message, args: [chat_id, text, opts, parse_mode]}} =
FakeAPI.await_send(:send_message, 10_000)
FakeAPI.sent() # all captured calls %{fun, args, at_ms}
FakeAPI.stub(:get_chat_member, {:ok, %{"ok" => true, "result" => %{"status" => "administrator"}}})
FakeAPI.put_file("file-1", "bytes") # get_file/2 + download_file/2 round-trip
FakeAPI.reset() # queue + captures + stubs + files (counters survive, safe mid-poll)Against a test-booted live instance with the fake configured, the same driving
API works over --rpc-eval (the FakeAPI GenServer is name-registered on that
node; the transport lazily boots it):
elixir --sname "probe_$$" --cookie "$COOKIE" --rpc-eval "$TESTNODE@$(hostname -s)" \
'LemonChannels.Telegram.FakeAPI.simulate_message(4242, "/status") |> Map.get("update_id") |> IO.inspect()'
elixir --sname "probe_$$" --cookie "$COOKIE" --rpc-eval "$TESTNODE@$(hostname -s)" \
'LemonChannels.Telegram.FakeAPI.await_send(:send_message, 10_000) |> inspect() |> IO.puts()'The house smoke proves the whole loop (string-config api_mod resolution, inbound round trip, offset advance, callback answer, outbound delivery) and writes a proof artifact:
MIX_ENV=test mix run scripts/live_fake_telegram_smoke.exs
# -> .lemon/proofs/fake-telegram-smoke-latest.json, exit 1 on any failed checkOnly when the claim is about the real wire or real chat UX (Bot API behavior,
actual rendering in clients, live latency). Use scripts/telegram_driver.py
— a Telethon library + CLI sharing the matrix harness's credential loading
(~/.zeebot/api_keys/telegram.txt; Bot API token from
LEMON_TELEGRAM_BOT_TOKEN/TELEGRAM_BOT_TOKEN env, the credentials file, or
the lemon secrets store — never printed).
CLI subcommands (all take --credentials --group --bot --repo-root --json;
chat commands add --chat --topic-id; waiting commands add --timeout --idle-timeout --limit):
uv run scripts/telegram_driver.py topic-create "[verify] my probe" --json
uv run scripts/telegram_driver.py send-and-await "reply with exactly OK" --topic-id "$TOPIC" --json
uv run scripts/telegram_driver.py await --topic-id "$TOPIC" --after-id 1234 --json
uv run scripts/telegram_driver.py send "hello" --chat bot --json # DM to the bot
uv run scripts/telegram_driver.py press-button --message-id 1240 "Approve once" --json
uv run scripts/telegram_driver.py topic-delete "$TOPIC" --json
uv run scripts/telegram_driver.py topic-cleanup "[verify]" --dry-run --jsonExit codes: 0 ok (await/send-and-await require ≥1 reply), 1 ok:false,
2 error (--json prints {"ok":false,"error":...}). Library use:
async with TelegramDriver() as driver: with send / await_replies /
send_and_await / press_button / create_topic / delete_topic /
cleanup_topics (see the module docstring).
Test-group conventions:
-1003842984060, bot zeebot_lemon_bot).[verify] or [adhoc]), do all probing inside them.topic-delete each one, or topic-cleanup "<your-prefix>" (it never touches the General topic, id 1; run --dry-run first).Related tooling: scripts/live_telegram_matrix.py for the fixed live scenario
matrix (DM/topic isolation/cancel/approval/markdown/long-output), the
stress-test-lemon command for the 8-test parallel stress run, and
.claude/skills/telegram-gateway-debug-loop/SKILL.md for deep debugging with
gateway debug logs + remote shell.
~/.zeebot/api_keys/telegram.txt and the lemon secrets store — reference paths, hold values only in shell variables/memory.~/.lemon or the production node. Do not kill lemon_bot@<host>, do not bind its ports (4040/4080/4042), do not start runs or send messages on it. Attach read-only at most; anything mutating runs on a disposable instance (scripts/product_smoke_local isolation levers).topic-cleanup), disposable instances (product_smoke_local cleans up after itself; kill only pids you started), and any transports/fakes you booted in a VM (GenServer.stop, FakeAPI.reset()).© z80dev, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file
Just SKILL.md in .claude/skills/verify-lemon of z80dev/lemon.
Open the folder on GitHubat commit 899e215
Verify Lemon next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Verify Lemon this skillz80dev/lemon | 131 | — | ~4k | Automated safety check: Notes | MIT | |
| Codex CLI TaskLeoYeAI/openclaw-master-skills | 2.2k | — | ~7.1k | Automated safety check: Pass | MIT | |
| Better Notifybetter-notify/better-notify | 313 | — | ~783 | Automated safety check: Pass | MIT | |
| SsrSAP/spartacus | 784 | — | ~229 | Automated safety check: Pass | Apache-2.0 | |
| Tanstack Startasmyshlyaev177/test-proxy-recorder | 112 | — | ~2.9k | Automated safety check: Notes | MIT | |
| Acp Local Runnerrebornix/Agmente | 545 | — | ~804 | Automated safety check: Pass | MIT |
LeoYeAI/openclaw-master-skills
Launch OpenAI Codex CLI async in background with automatic delivery to Telegram/WhatsApp.
better-notify/better-notify
End-to-end typed notification infrastructure for Node.js — typed catalog of email, SMS, push, web push, WhatsApp, Slack, Discord, Telegram, and GitHub notifications with provider-agnostic transports.
SAP/spartacus
A skill your agent uses when working with Spartacus Server-Side Rendering (SSR).
asmyshlyaev177/test-proxy-recorder
Record and replay TanStack Start SSR with test-proxy-recorder.
rebornix/Agmente
Run and debug Agmente ACP end-to-end scenarios from the repo-owned e2e/scenarios/acp specs.
lablup/backend.ai-webui
Post a Korean release risk digest to a Microsoft Teams thread, grouped by risk category.
z80dev/lemon
Debug and stress-test lemon gateway behavior by acting as both sides of Telegram conversations: run lemon-gateway with debug logs, then use Telethon with user credentials to send/reply messages in a…
z80dev/lemon
Pin files and JSON to IPFS via Pinata (JWT auth + helper scripts).
z80dev/lemon
Interact with Discord via a bot: read channels, send messages, list guilds/channels, upload files, manage threads.
z80dev/lemon
Connect to a running Lemon or lemon-gateway BEAM node, run recompile() for hot code reload, and execute Elixir code in that live runtime via IEx remsh or rpc-eval.
z80dev/lemon
Search and analyze your own Lemon session logs (older/parent conversations) using jq.
Works with
Categories
Verify lemon features against a running (or disposable) instance using the cheapest sufficient tier: DIRECT (attach/RPC + control-plane WS + bus observation, no Telegram), FAKE TELEGRAM (hermetic…. Verify Lemon is an agent skill from z80dev/lemon.py against the real bot).
Verify Lemon fits situations like: feature verification; regression repros; post-change validation.
Run `npx skills add z80dev/lemon --skill verify-lemon -a claude-code`. Or copy the skill folder (.claude/skills/verify-lemon in z80dev/lemon) into .claude/skills/verify-lemon in your project. Claude Code loads it when a task matches its description.
Run `npx skills add z80dev/lemon --skill verify-lemon -a codex`. Or copy the skill folder (.claude/skills/verify-lemon in z80dev/lemon) into .agents/skills/verify-lemon in your project. Codex loads it when a task matches its description.
Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add z80dev/lemon --skill verify-lemon -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/verify-lemon, .gemini/skills/verify-lemon, .github/skills/verify-lemon and .opencode/skills/verify-lemon in your project.
Going by SKILL.md and its folder, Verify Lemon needs the command-line tools its instructions call (uv) and credentials named LEMON_TELEGRAM_BOT_TOKEN and TELEGRAM_BOT_TOKEN. Our summary lists: Python 3. Its frontmatter pre-approves these tools: Read, Grep, Bash, Glob, Write.
SKILL.md contains no URLs. Its commands use uv, which can reach the network depending on how they are called. This is read from the text; nothing was executed.
Our automated static check of SKILL.md found notes only (pre-approves every shell command (allowed-tools: bash)), nothing it rates as a warning. It is not a guarantee. Review the folder before installing.
Verify Lemon is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.
About 4k tokens (SKILL.md is roughly 16k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.
Skills that share tags, products or a category with Verify Lemon: Codex CLI Task (LeoYeAI/openclaw-master-skills, 2.2k stars), Better Notify (better-notify/better-notify, 313 stars), Ssr (SAP/spartacus, 784 stars) and Tanstack Start (asmyshlyaev177/test-proxy-recorder, 112 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
z80dev (a GitHub user) maintains it in z80dev/lemon, which has 131 GitHub stars. The repository holds 6 skills in this directory. The repository was last updated on September 16, 2026.
Source: z80dev/lemon on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.