一键导入
writing-tests
Write and edit test files that model real user flows. Use when creating, modifying, or reviewing test files.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Write and edit test files that model real user flows. Use when creating, modifying, or reviewing test files.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Read-only Libretto workflow for diagnosing live browser state without clicks, typing, navigation, or mutation requests.
Browser automation CLI for building, maintaining, and running browser automation workflows by inspecting live pages and prototyping interactions.
Find deepening opportunities in a codebase, informed by the domain language in CONTEXT.md and the decisions in docs/adr/. Use when the user wants to improve architecture, find refactoring opportunities, consolidate tightly-coupled modules, or make a codebase more testable and AI-navigable.
Automate user-installed Electron desktop apps (Slack, Discord, VS Code, Notion, Figma, Spotify, etc.) via CDP using this repo's Libretto CLI. Use when the task is to control a local desktop app on the user's machine, not this repo's own Electron app. Triggers: "desktop Slack app", "connect to Electron app", "remote-debugging-port", "CDP desktop app", "automate VS Code desktop app".
Create a spec sheet for the given feature/fix request in specs/ directory. Use when planning a significant new feature or complex fix.
Stage ALL changes in the repository (not just session changes), commit, and push. Use when you need to commit all pending changes.
| name | writing-tests |
| description | Write and edit test files that model real user flows. Use when creating, modifying, or reviewing test files. |
Each test should represent a single, concrete flow that a real user would follow when interacting with the system. Write tests at the same abstraction level as the user experiences the system.
The test should call the system the same way a user would. If the system is a CLI, the test should invoke the CLI with argument strings. If it's a library, the test should call the public API. Don't wrap the interface in test-specific helpers that hide what's actually happening.
Good — the test reads like what a user would do:
const result = await librettoCli("setup --skip-browsers");
expect(result.exitCode).toBe(0);
const result2 = await librettoCli("--help");
expect(result2.stdout).toContain("Usage:");
Bad — extra abstraction obscures the actual interaction:
const result = await setupWithDefaults(); // hides the real CLI invocation
assertSuccess(result); // hides what "success" means
Don't introduce helpers for brevity. The value of a test is that you can read it top-to-bottom and understand exactly what's happening. Repetition across tests is fine — each test should be self-contained and readable on its own.
Each test should exercise one coherent user scenario from setup through assertion. Don't combine unrelated flows into a single test, and don't split one logical flow across multiple tests.
The full set of tests for a system should cover the sufficiently complete set of flows a user might follow. Think about:
When adding a new feature, add tests that cover the new user flows it introduces. When fixing a bug, add a test that reproduces the flow where the bug occurred.