test-agent-tools

星标9

分支0

更新时间2026年7月31日 00:08

Probe, test, and document every tool the agent harness has access to (native tools, subagents, connected MCP servers). Use when the user wants to test, audit, or inventory the harness's tool/capability set, or asks "what tools do you have".

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

来源

riipandi

riipandi/elph

打开 GitHub 仓库查看创作者相关仓库

下载

Test Agent Tools

Purpose

Enumerate available tools/capabilities — including connected MCP servers — exercise each one (web search, subagents, MCP calls), and produce a final report with a status table + subagent summary, under a timestamped demo/ run folder.

Workflow

Create folder demo/YYMMDD_hhmm (current date/time).
List available tools/capabilities, including any connected MCP servers/tools.
Test each tool:
- Non-subagent tools (e.g. web search): run directly, write findings flat inside demo/YYMMDD_hhmm/.
- Subagent-based exploration: dispatch one subagent per topic/tool; each writes to its own demo/YYMMDD_hhmm/<subagent_id_or_name>/findings.md.
- MCP tools: if any MCP servers are connected, invoke each connected tool at least once; record request/response/error.
Write demo/YYMMDD_hhmm/REPORT.md:
- Table: | Tool | Type (native/MCP/subagent) | Status (OK/FAIL/SKIPPED) | Notes |
- Summary section aggregating each subagent's report (what it tested, key findings).
Post the full content of REPORT.md directly in the chat reply (not just a file link) — including the tool status table and the subagent summary. If subagents produced findings, include their key results inline too, not just a reference to the file.
- Files (REPORT.md, findings, etc.) stay in English regardless of chat language.
- The chat-transcript presentation of the report (narration, summary, table labels) uses whatever language the user is currently using in the conversation — translate on the fly, don't just paste the English file verbatim if the chat language differs.

Mandatory Rules

Only create files/folders inside demo/.
Never create files/folders at the root directory or outside demo/.
One run = one folder demo/YYMMDD_hhmm (current date/time, no suffix/label).
No subagent: write markdown files flat inside demo/YYMMDD_hhmm/.
With subagent: each subagent writes into its own demo/YYMMDD_hhmm/<subagent_id_or_name>/.
REPORT.md always lives flat at demo/YYMMDD_hhmm/REPORT.md, never inside a subagent folder.

Mode Lock

Never offer, suggest, or ask the user to switch agent mode (Build/Plan/Brave/Ask).
Always operate in the currently active mode, regardless of task complexity/risk.
If the task needs another mode's capability (e.g. execution needed but mode = Plan/Ask):
- Do as much as the active mode allows.
- Report the blocker factually (e.g. "needs write access, current mode is read-only").
- Do NOT frame it as "want me to switch to mode X?" — mode switching is user-initiated only.
This holds even if the user seems unsure or asks "should I switch mode?" — answer factually, but still don't proactively offer/trigger a switch.

Examples

Flat (non-subagent/MCP): demo/260731_1420/mcp-github/findings.md or demo/260731_1420/findings.md
With subagent: demo/260731_1420/web-search-agent/findings.md
Final report: demo/260731_1420/REPORT.md

同仓库更多 Skills

同仓库

update-models

riipandi/elph

Refresh elph-ai chat model catalogs from models.dev (origin) with optional live provider pricing, inject full thinkingLevelMap on every model, regenerate src/models/catalog.rs, and verify registration. Use when the user runs /update-models, asks to sync or regenerate model catalogs, update models.dev data, refresh pricing, or keep provider model lists current.

2026-08-019

create-skill

riipandi/elph

Interactively create a new Elph skill (SKILL.md + optional scripts/references). Use when the user wants to create a skill, scaffold a skill, or runs /create-skill.

2026-08-019

rust-verify-harden

riipandi/elph

Run make check/lint/test (cargo fmt/check/clippy/test) and fix failures, then audit changed/related Rust code for memory/resource leaks, deadlock risk, data races, and structural complexity (spaghetti code, god functions/modules, tangled control flow). Also audits Turso/libSQL/SQLite usage for lock contention (SQLITE_BUSY/"database is locked"), WAL/checkpoint misconfig, connection/pool misuse, embedded-replica sync issues, and corruption risk. Use when user asks to verify build quality gates, prep Rust code for merge/release, audit concurrency/memory safety, clean up messy/spaghetti Rust code, or check a Rust service using Turso/libSQL for locking/corruption/sync problems. Consult current Rust docs (rust-lang.org, docs.rs) and lint guidance, plus Turso/libSQL docs (docs.turso.tech) when relevant, to ensure fixes align with active best practices, not deprecated patterns. Flags backward-compat/legacy code and structural refactors found during cleanup and asks the user before removing/restructuring.

2026-08-019

pi-port-gap

riipandi/elph

Analyze pi → elph porting gaps and Elph-specific implementation differences. Compare upstream pi-ai / pi-agent-core CHANGELOGs and source against elph-ai / elph-agent: (1) what upstream has that elph still lacks, (2) how Elph-only features diverge in design and wiring. Porting doctrine: adopt only true gaps (intent/behavior from pi), implement on Elph architecture — catalogs are models.dev via update-models, never pi seed. Prefer reverse-chronological timeline prose over tables. Persisted docs are always English; in-chat reports follow the user's current language. Use for port gap audit, upstream drift, parity check, Elph extension diff, implementation delta, changelog walk, selisih implementasi, or /pi-port-gap.

2026-07-319

tui-design

riipandi/elph

Guide terminal UI development with iocraft (components, flex layout, scroll, a11y) and CLI/slash command UX: anstyle coloring, readable structured output, TTY/NO_COLOR rules, and dialog-safe plain text. Use when building or refactoring a TUI, CLI subcommands, slash commands, colored terminal output, fixing scroll/focus/layout bugs, improving keyboard/contrast ergonomics, or the user mentions iocraft, terminal UI, CLI colors, anstyle, command UX, accessibility, a11y, or runs /tui-design.

2026-07-319

cargo-workspace-hygiene

riipandi/elph

Audit a Rust workspace for dependency hygiene: duplicate crate versions across members, unused/dead dependencies, feature-flag bloat, and un-unified workspace dependency tables. Proposes and safely applies fixes (unify to [workspace.dependencies], drop unused deps, trim feature sets), verifying cargo check/clippy/test stay green. Use when user asks to clean up Cargo.toml(s), dedupe dependency versions, find unused crates, unify workspace deps, or audit workspace dependency structure. Does not cover security advisories or license compliance — see rust-dep-audit for that.

2026-07-279

name	test-agent-tools
description	Probe, test, and document every tool the agent harness has access to (native tools, subagents, connected MCP servers). Use when the user wants to test, audit, or inventory the harness's tool/capability set, or asks "what tools do you have".

Test Agent Tools

Purpose

Workflow

Create folder demo/YYMMDD_hhmm (current date/time).
List available tools/capabilities, including any connected MCP servers/tools.
Test each tool:
- Non-subagent tools (e.g. web search): run directly, write findings flat inside demo/YYMMDD_hhmm/.
- Subagent-based exploration: dispatch one subagent per topic/tool; each writes to its own demo/YYMMDD_hhmm/<subagent_id_or_name>/findings.md.
- MCP tools: if any MCP servers are connected, invoke each connected tool at least once; record request/response/error.
Write demo/YYMMDD_hhmm/REPORT.md:
- Table: | Tool | Type (native/MCP/subagent) | Status (OK/FAIL/SKIPPED) | Notes |
- Summary section aggregating each subagent's report (what it tested, key findings).
Post the full content of REPORT.md directly in the chat reply (not just a file link) — including the tool status table and the subagent summary. If subagents produced findings, include their key results inline too, not just a reference to the file.
- Files (REPORT.md, findings, etc.) stay in English regardless of chat language.
- The chat-transcript presentation of the report (narration, summary, table labels) uses whatever language the user is currently using in the conversation — translate on the fly, don't just paste the English file verbatim if the chat language differs.

Mandatory Rules

Only create files/folders inside demo/.
Never create files/folders at the root directory or outside demo/.
One run = one folder demo/YYMMDD_hhmm (current date/time, no suffix/label).
No subagent: write markdown files flat inside demo/YYMMDD_hhmm/.
With subagent: each subagent writes into its own demo/YYMMDD_hhmm/<subagent_id_or_name>/.
REPORT.md always lives flat at demo/YYMMDD_hhmm/REPORT.md, never inside a subagent folder.

Mode Lock

Never offer, suggest, or ask the user to switch agent mode (Build/Plan/Brave/Ask).
Always operate in the currently active mode, regardless of task complexity/risk.
If the task needs another mode's capability (e.g. execution needed but mode = Plan/Ask):
- Do as much as the active mode allows.
- Report the blocker factually (e.g. "needs write access, current mode is read-only").
- Do NOT frame it as "want me to switch to mode X?" — mode switching is user-initiated only.
This holds even if the user seems unsure or asks "should I switch mode?" — answer factually, but still don't proactively offer/trigger a switch.

Examples

Flat (non-subagent/MCP): demo/260731_1420/mcp-github/findings.md or demo/260731_1420/findings.md
With subagent: demo/260731_1420/web-search-agent/findings.md
Final report: demo/260731_1420/REPORT.md