Source profileQuality 93/100

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.

Best for

    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

    PlatformStatusEvidenceWhat to check
    CodexNot declaredNo explicit evidencePortability before use
    Claude CodeNot declaredNo explicit evidencePortability before use
    CursorNot declaredNo explicit evidencePortability before use
    Gemini CLINot declaredNo explicit evidencePortability before use
    Open the compatibility checker

    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.

    Source-detected install commandSource
    npx skills add https://github.com/shabaraba/vibing.nvim --skill ".claude/skills/test-design"
    Safe inspection promptEditorial

    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

    1. 01

      Usage

      Provide context when invoking:

      Provide context when invoking:
    2. 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
    3. 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
    4. 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
    5. 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

    low · line 99

    The documentation asks the agent to read local files, directories, or repositories.

    [ ] Permission denied (read-only directory)

    Evidence record

    Why each signal appears

    EvidenceSourceComputedTestedEditorial
    SignalValueEvidence typeMeaning
    Quality score93/100ComputedDocumentation, specificity, maintenance, and trust rules
    Repository stars13SourceRepository attention, not individual Skill quality
    Compatibility0 platformsSourceDeclared in the catalog source record
    Usage guideautomated source guideEditorialGenerated 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

    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

    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

    1. Export basic chat successfully
    2. Handle permission errors gracefully

    High

    1. Validate file path (security)
    2. Handle empty chat

    Medium

    1. 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:

    1. Review generated test scenarios
    2. Approve Critical and High priority tests
    3. Implement approved tests in tests/e2e/
    4. Run npm run test:e2e
    5. Apply 3-try auto-fix rule if failures occur (see .claude/rules/self-testing.md)

    References

    • .claude/rules/self-testing.md - Complete self-testing procedures
    • lua/vibing/testing/e2e_helper.lua - E2E helper API reference
    • tests/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