원클릭으로
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 직업 분류 기준
| 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.
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.