Skip to content
Back to skills

Weft Live Test

ASecurity

COMMAND, not reference: Walk the user through setting up and running a node's live test. Run this when the user asks for this step by name, optionally naming the node type or package name. The seventeen `weft-` reference skills beside it are things you read; this is a procedure you carry out.

  • 1,992 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added October 4, 2026
toolsgoshellnode

Works with

  • cli

Security analysis

A100/100

Scanned October 4, 2026

npx -y skills add WeaveMindAI/weft --skill weft-live-test --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Weft Live Test?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Weft Live Test
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/weavemindai-weft-live-test/badge)](https://www.skillsdirectory.com/skills/weavemindai-weft-live-test)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: weft-live-test
description: "COMMAND, not reference: Walk the user through setting up and running a node's live test. Run this when the user asks for this step by name, optionally naming the node type or package name. The seventeen `weft-` reference skills beside it are things you read; this is a procedure you carry out."
---

Run the live tier of a node's self-tests, with the user's informed consent. The node type or package is the one the user named when they asked. The local tiers (basic, fake) already passed when the node was built; the live tier calls the real service with a real credential and can spend money, which is why it is run here, by the user's choice, and not by the node specialist.

Walk it in this order:

1. **Say what it costs.** One live test is one short-lived test server on the user's install making a real call on the named service, on the user's own credential or their credits. Get a plain "yes" before anything else.
2. **Find what the tests need.** Read the node's `tests.rs` (`nodes/<snake_name>/tests.rs`, the folder whose `metadata.json` declares that type, or the package's members) for the `NodeTest::live` entries: the service each names, the credential fields, and any fixtures the test cannot self-provision (a chat id to message, a file to touch).
3. **Check the ground.** `weft daemon status`; start it with the user if it is down. The live tier also needs the project registered with the dispatcher: if the run refuses with an unknown-project error, register with an ordinary `weft run` (registration is part of it) or follow the error's own hint.
4. **Set up the credential, never through the chat.** Two ways, the user picks:
   - a key: the user puts `WEFT_NODE_TEST_<SERVICE>_<FIELD>=...` lines in the project's `.env` (auto-loaded) or their shell themselves. Never ask them to paste a secret into the conversation, and never echo one back. Fixtures go in the same file, under their own name: `WEFT_NODE_TEST_<fixture name>=...`, exactly as the test declares it (the missing-fixture error prints the variable it wants).
   - a connection they already made in the editor: `--connection <service>=<grant id>`.
5. **Run it.** `weft test-node <type> --tier live` (add `--parallel` if they want speed and several tests exist). The permission prompt and the CLI's own money confirmation are both expected; the user answers them.
6. **Report.** Each test line, pass or fail, in plain words; a failure carries the service's own error text. On green, note that `weft node-test-hash <type>` prints the hash that lets a scripted sweep skip this package until its sources change, and that the node is now proven end to end.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…