test-design
Skill13 starsChanged 11 months agoMITView on GitHub
Automatically design comprehensive E2E test cases for newly implemented vibing.nvim features. Use immediately after completing feature implementation (Phase 5.4) and before running E2E tests. Generates test scenarios covering Happy paths, Error cases, Edge cases, and Integration points with priority ranking (Critical/High/Medium/Low) and ready-to-use test code templates using e2e_helper.lua.
We split this skill into the rules it gives an agent
3 rules. 0 are common, 3 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 10 edited versions we read keep these.
3
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 84
Gather context: - Read changed files, analyze scope, review existing tests
- Distinctive: line 87
Generate code: - Create implementation-ready test templates
- Distinctive: line 186
Use vague descriptions ("Added some features")
“Common” is measured: kept by at least 6 in 10 of the 10 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Test Design for vibing.nvim
Generate comprehensive E2E test scenarios after implementing new features.
Usage
Provide context when invoking:
/test-design
I implemented [feature description].
Changed files:
- [list of new/modified files]
Existing tests:
- [list of existing test files]Example:
/test-design
I implemented a new slash command `/export` that exports chat history to Markdown.
Changed files:
- lua/vibing/application/chat/slash_commands.lua (added export_command)
- lua/vibing/utils/markdown_exporter.lua (new file)
Existing tests:
- tests/e2e/chat_basic_flow_spec.lua (basic chat operations)Output Format
1. Test Scenario Analysis
Categorized scenarios with checkboxes:
- Happy Path ✅ - Most common use cases
- Error Cases ❌ - Error handling (validation, network, permissions)
- Edge Cases 🔸 - Boundary conditions, special characters, timeouts
- Integration Points 🔗 - Interactions with other features
2. Priority Ranking
- Critical: Core functionality - must work for release
- High: Error handling - security, data loss prevention
- Medium: Usability - edge cases, user experience
- Low: Performance - optimization, rare scenarios
3. Test Code Templates
Ready-to-implement code using e2e_helper.lua:
describe("E2E: [Feature Name]", function()
local nvim_instance
before_each(function()
nvim_instance = helper.spawn_nvim_instance({
headless = true,
init_script = "tests/minimal_init.lua",
})
end)
after_each(function()
helper.cleanup_instance(nvim_instance)
end)
-- Test cases with appropriate TIMEOUTS constants
end)Workflow
- Gather context - Read changed files, analyze scope, review existing tests
- Design scenarios - Generate Happy/Error/Edge/Integration cases
- Prioritize - Rank by Critical/High/Medium/Low
- Generate code - Create implementation-ready test templates
Example Output
For a /export command that exports chat to Markdown:
Test Scenarios
Happy Path ✅
- Export chat with single message
- Export chat with multiple messages
- Export with frontmatter preserved
Error Cases ❌
- Permission denied (read-only directory)
- Invalid file path (path traversal attack)
- Empty chat (no messages)
Edge Cases 🔸
- Very long chat (1000+ messages)
- Special characters in messages
Integration Points 🔗
- Export from worktree chat
- Export during active Assistant response
Priority Ranking
Critical
- Export basic chat successfully
- Handle permission errors gracefully
High
- Validate file path (security)
- Handle empty chat
Medium
- Export with special characters
Test Code
-- tests/e2e/export_command_spec.lua
local helper = require("vibing.testing.e2e_helper")
local TIMEOUTS = {
CHAT_CREATION = 2000,
COMMAND_EXECUTION = 3000,
}
describe("E2E: /export command", function()
local nvim_instance
before_each(function()
nvim_instance = helper.spawn_nvim_instance({
headless = true,
init_script = "tests/minimal_init.lua",
})
end)
after_each(function()
helper.cleanup_instance(nvim_instance)
end)
it("should export chat to markdown file", function()
helper.send_keys(nvim_instance, ":VibingChat<CR>")
vim.wait(TIMEOUTS.CHAT_CREATION)
helper.send_keys(nvim_instance, "GiTest message<Esc><CR>")
local ok = helper.wait_for_buffer_content(
nvim_instance,
"## .* Assistant",
30000
)
assert.is_true(ok, "Assistant should respond")
-- Execute /export and verify...
end)
end)Best Practices
Do:
- Provide detailed feature description with expected behavior
- List all changed files (
git diff --name-only) - Review generated scenarios - don't blindly accept
- Implement Critical/High tests first
Don't:
- Use vague descriptions ("Added some features")
- Skip review - templates need customization
- Implement all tests at once - prioritize
Next Steps
After running /test-design:
- Review generated test scenarios
- Approve Critical and High priority tests
- Implement approved tests in
tests/e2e/ - Run
npm run test:e2e - Apply 3-try auto-fix rule if failures occur (see
.claude/rules/self-testing.md)
References
.claude/rules/self-testing.md- Complete self-testing procedureslua/vibing/testing/e2e_helper.lua- E2E helper API referencetests/e2e/chat_basic_flow_spec.lua- Example test suite
Other versions15 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 15
- adamentwistle/fable-skills★ 98same name
- nahid-sparktales/agent-dispatcher★ 59same name
- tlzmw001/aitest-kit★ 13same name
- yasunori0418/skills★ 9same name
- Lixiuxiu559/AgentForge★ 4same name
- umararshad4/honey-stack★ 4same name
- Gusen1453/creed★ 3same name
- adolfoaranaes12/BMAD-ENHANCED★ 2same name
- fang2hou/skills★ 2same name
- mattstruble/skills★ 2same name
5 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
Used alongsideProjects with it also use diff-review.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
zhangzheng-debugSkilldiff-review
Use after Codex or a developer changes files in AgentOps Workbench. Trigger for review, diff check, scope check, or before merge. Do not trigger before any changes exist.
Also in 3 projects that use this
In this repository6 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- ci-gatesSkill
- github-flow-for-claude-on-webSkill
- remote-screenshotSkill
- self-testingSkill
- stacked-pr-mergeSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

