/writing-tests
Use when writing, changing, or deciding whether to keep a test in this repo, especially in the @mcp-use/cli package. Tests assert what callers can observe (exit code, output, error codes, state, requests sent), use literal expected values, and run real code instead of mocks.
Claude Code
$ npx -y skills add mcp-use/mcp-use --skill writing-tests --agent claude-code
Codex
$ npx skills add mcp-use/mcp-use --skill writing-tests -a codex -y
Cursor
$ npx skills add mcp-use/mcp-use --skill writing-tests -a cursor -y
Gemini CLI
$ npx skills add mcp-use/mcp-use --skill writing-tests -a gemini-cli -y
GitHub Copilot
$ npx skills add mcp-use/mcp-use --skill writing-tests -a github-copilot -y
OpenCode
$ npx skills add mcp-use/mcp-use --skill writing-tests -a opencode -y
Windsurf
$ npx skills add mcp-use/mcp-use --skill writing-tests -a windsurf -y
SKILL.md
writing-tests.SKILL.mdname: writing-tests
description: Use when writing, changing, or deciding whether to keep a test in this repo, especially in the @mcp-use/cli package. Tests assert what callers can observe (exit code, output, error codes, state, requests sent), use literal expected values, and run real code instead of mocks. Includes the fake-Cloud harness for CLI cloud commands.
Writing tests
A test is a claim about what the code does for the people and programs that use it. Write it so it fails when that behaviour breaks and keeps passing when only the internals change. If you can't write a test like that, write no test: **no new test beats a bad test.**
Rules
1. **Test what callers can observe.** For the CLI that means the exit code, stdout and stderr, the error `code` that callers branch on, state they can read back (files, config), and effects outside the process, such as the requests Cloud receives. It does not mean private helpers, internal call order, or which module did the work. 2. **Expected values are literals from the requirement.** Write `"12345678\tserver_1\tfailed"`, not `formatRow(item)`. Never compute the expected value with the code under test. 3. **Don't mock what you can run.** Spawn the real CLI, write real files, run real git. Fake only the real outside boundaries (Manufact Cloud, GitHub, the browser). What a fake receives is behaviour, so assert on it. 4. **Pair every "nothing happened" assertion with a case where it happens.** A test that checks "no request was sent" also needs a case proving the test can see a request. 5. **Avoid** snapshots of human prose, exact error _messages_ (assert the `code`), sleeps and timing races, and assertions on data the test built itself.
Workflow
1. Name the observable behaviour the test covers. 2. Drive the built CLI through the real-process runner and fake Cloud. 3. Assert on output, exit status, files, and requests received by the fake. 4. Rebuild after source edits, then run the relevant tests and typecheck.
References
- [references/principles.md](references/principles.md): each rule in more
depth, with good and bad examples from this repo.
- [references/cli-and-cloud.md](references/cli-and-cloud.md): how to test
`@mcp-use/cli` commands with the fake-Cloud harness in `libraries/typescript/packages/cli/tests/helpers/`.
Adapted in our own words from the testing guidance in Cursor's [pstack](https://github.com/cursor/plugins/tree/main/pstack) (MIT, © 2026 Lauren Tan).
Read more
name: writing-tests description: Use when writing, changing, or deciding whether to keep a test in this repo, especially in the @mcp-use/cli package. Tests assert what callers can observe (exit code, output, error codes, state, requests sent), use literal expected values, and run real code instead of mocks. Includes the fake-Cloud harness for CLI cloud commands.
Writing tests
A test is a claim about what the code does for the people and programs that use it. Write it so it fails when that behaviour breaks and keeps passing when only the internals change. If you can't write a test like that, write no test: **no new test beats a bad test.**
Rules
1. **Test what callers can observe.** For the CLI that means the exit code, stdout and stderr, the error `code` that callers branch on, state they can read back (files, config), and effects outside the process, such as the requests Cloud receives. It does not mean private helpers, internal call order, or which module did the work. 2. **Expected values are literals from the requirement.** Write `"12345678\tserver_1\tfailed"`, not `formatRow(item)`. Never compute the expected value with the code under test. 3. **Don't mock what you can run.** Spawn the real CLI, write real files, run real git. Fake only the real outside boundaries (Manufact Cloud, GitHub, the browser). What a fake receives is behaviour, so assert on it. 4. **Pair every "nothing happened" assertion with a case where it happens.** A test that checks "no request was sent" also needs a case proving the test can see a request. 5. **Avoid** snapshots of human prose, exact error _messages_ (assert the `code`), sleeps and timing races, and assertions on data the test built itself.
Workflow
1. Name the observable behaviour the test covers. 2. Drive the built CLI through the real-process runner and fake Cloud. 3. Assert on output, exit status, files, and requests received by the fake. 4. Rebuild after source edits, then run the relevant tests and typecheck.
References
- [references/principles.md](references/principles.md): each rule in more
depth, with good and bad examples from this repo.
- [references/cli-and-cloud.md](references/cli-and-cloud.md): how to test
`@mcp-use/cli` commands with the fake-Cloud harness in `libraries/typescript/packages/cli/tests/helpers/`.
Adapted in our own words from the testing guidance in Cursor's [pstack](https://github.com/cursor/plugins/tree/main/pstack) (MIT, © 2026 Lauren Tan).
The fullstack MCP framework to develop MCP Apps for ChatGPT / Claude & MCP Servers for AI Agents.
Other skills on mcp-use.
More skills from other plugins.
gitnexus-cli
Use when the user needs to run GitNexus CLI commands like analyze/index a repo, check status, clean the index, generate a wiki,…
fastmcp-client-cli
Query and invoke tools on MCP servers using fastmcp list and fastmcp call. Use when you need to discover what tools a server…
n8n-agents
Design n8n AI agents the right way. Use when building or editing any @n8n/n8n-nodes-langchain.* AI node — an AI Agent, LLM chain,…
post-to-xhs
小红书内容发布技能。支持两种发布模式:(1) 上传图文模式 - 图片+短文;(2) 写长文模式 - 长篇文章+排版模板。 支持两种输入方式:用户提供完整内容和图片/图片URL,直接发布;或提供网页URL,自动提取内容和图片。…
Questions about writing-tests.
- Which coding agents can use writing-tests?
- writing-tests installs in Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot, OpenCode and Windsurf with the skills CLI, using each agent's flag shown on this page. Flowy's auto-invocation, which fires a skill when your prompt matches, runs in Claude Code only.

