shabaraba/vibing.nvim/.claude/skills/test-design/SKILL.md
test-design
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.
- Source repository stars
- 13
- Declared platforms
- 0
- Static risk flags
- 1
- Last source update
- 2026-08-28
- Source checked
- 2026-08-28
Decision brief
What it does: where it fits
Generate comprehensive E2E test scenarios after implementing new features.
Not for
- Tasks that require unconfirmed production actions or broad system permissions.
- Environments where the pinned source and install steps cannot be inspected.
Compatibility matrix
Platform support, with evidence labels
| Platform | Status | Evidence | What to check |
|---|---|---|---|
| Codex | Not declared | No explicit evidence | Portability before use |
| Claude Code | Not declared | No explicit evidence | Portability before use |
| Cursor | Not declared | No explicit evidence | Portability before use |
| Gemini CLI | Not declared | No explicit evidence | Portability before use |
Installation
Inspect first. Install second.
The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.
npx skills add https://github.com/shabaraba/vibing.nvim --skill ".claude/skills/test-design"Inspect the Agent Skill "test-design" from https://github.com/shabaraba/vibing.nvim/blob/41a3c5fd710ab84d47e49c165d9aaab34afa96e5/.claude/skills/test-design/SKILL.md at commit 41a3c5fd710ab84d47e49c165d9aaab34afa96e5. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.
Workflow
What the source asks the agent to do
- 01
Usage
Provide context when invoking:
Provide context when invoking: - 02
Workflow
1. Gather context - Read changed files, analyze scope, review existing tests 2. Design scenarios - Generate Happy/Error/Edge/Integration cases 3. Prioritize - Rank by Critical/High/Medium/Low 4. Generate code - Create implementation-ready test templates
Gather context - Read changed files, analyze scope, review existing testsDesign scenarios - Generate Happy/Error/Edge/Integration casesPrioritize - Rank by Critical/High/Medium/Low - 03
Output Format
Categorized scenarios with checkboxes:
Happy Path ✅ - Most common use casesError Cases ❌ - Error handling (validation, network, permissions)Edge Cases 🔸 - Boundary conditions, special characters, timeouts - 04
1. Test Scenario Analysis
Categorized scenarios with checkboxes:
Happy Path ✅ - Most common use casesError Cases ❌ - Error handling (validation, network, permissions)Edge Cases 🔸 - Boundary conditions, special characters, timeouts - 05
2. Priority Ranking
Critical: Core functionality - must work for release
Critical: Core functionality - must work for releaseHigh: Error handling - security, data loss preventionMedium: Usability - edge cases, user experience
Permission review
Static risk signals and limitations
Reads files
The documentation asks the agent to read local files, directories, or repositories.
[ ] Permission denied (read-only directory)Evidence record
Why each signal appears
| Signal | Value | Evidence type | Meaning |
|---|---|---|---|
| Quality score | 93/100 | Computed | Documentation, specificity, maintenance, and trust rules |
| Repository stars | 13 | Source | Repository attention, not individual Skill quality |
| Compatibility | 0 platforms | Source | Declared in the catalog source record |
| Usage guide | automated source guide | Editorial | Generated or reviewed according to the visible evidence level |
Pinned source
Provenance and original SKILL.md
- Repository
- shabaraba/vibing.nvim
- Skill path
- .claude/skills/test-design/SKILL.md
- Commit
- 41a3c5fd710ab84d47e49c165d9aaab34afa96e5
- License
- MIT
- Collected
- 2026-08-28
- Default branch
- main
View the original SKILL.md
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
Frequently asked questions
What to verify before installation and use
What does the test-design source document cover?
Generate comprehensive E2E test scenarios after implementing new features.
How do I install test-design?
The source record exposes this install command: npx skills add https://github.com/shabaraba/vibing.nvim --skill ".claude/skills/test-design". Inspect the command and pinned source before running it.
Which permission-related actions were detected?
Static rules flagged read-files in the source; the page lists the matching lines and excerpts.
Alternatives
Compare before choosing
yonatangross/orchestkit
verify
Grade work that already exists and decide whether it can merge. Runs the project's current unit, integration, and E2E suites plus security scanning and type checking, scores every dimension 0-10, and returns a merge verdict with a VERIFIED-vs-CLAIMED evidence manifest. Writes no test files and edits no source. Use when verifying changes are ready to merge. Use /ork:cover instead when the tests still have to be written.
microsoft/Sico
android-tester
Execute Android UI workflows on a sandbox device, review results, and produce a structured execution report.
laurigates/claude-plugins
test-analyze
Analyze test results and create a fix plan with subagents. Use when triaging failing tests, analyzing JUnit XML, planning fixes for accessibility/security, or categorizing flaky/E2E failures.
mgiovani/cc-arsenal
team-review
Multi-agent review team: architecture, security, performance, testing, style, docs/UX, plus an adversary that cross-examines the other 6, for security-sensitive, architectural, or large PRs (15+ files) where a single-agent pass risks missing cross-cutting issues. Use for auth/payments/PII changes, schema/pattern changes, compliance sign-off, or when asked to 'get the review team on this' / 'multi-agent review' / 'thorough review before merge'. For a standard PR or a quick pre-merge check, use /r