feat: add /test skill for standalone test generation

Description

Add a /test skill that writes tests for existing code that lacks coverage. Currently, tests are only written as part of /build (Phase 2, Step 2) and /hotfix (Phase 3, Step 2) — both inline, not reusable, and only triggered alongside new implementation. There is no way to say "add tests to this existing code."

Standalone use cases:

• Improving coverage on legacy or inherited code
• Writing tests for code that was merged without adequate coverage
• Adding regression tests after a bug is found (without a full /hotfix cycle)
• Pre-refactor test harness — locking behavior before restructuring

Reuse by other skills:
/build Phase 2 Step 2 and /hotfix Phase 3 Step 2 both contain inline test-writing instructions. These could delegate to /test instead, creating a single source of truth for how Wingspan writes tests. This keeps test-writing conventions consistent across all workflows.

Proposed behavior

1. Scope detection — Accept files, directories, or patterns as arguments. If none provided, detect scope from branch diff (like /review does). If on the default branch with no arguments, ask what to test.

2. Convention discovery — Before writing anything, analyze the project's existing test files to learn:

   • Test framework and runner
   • File naming conventions (e.g., foo_test.dart, foo.test.ts, test_foo.py)
   • Directory structure (co-located vs. mirrored test/ directory)
   • Common patterns (setup/teardown, mocking library, assertion style)

3. Coverage gap analysis — For each file in scope, check whether a corresponding test file exists. Prioritize untested files, then under-tested files (files with tests that have low coverage or missing edge cases).

4. Test generation — Write tests following discovered conventions. For each file:

   • Match the project's test style exactly
   • Cover success paths, failure paths, and edge cases
   • Use meaningful, descriptive test names
   • Avoid anti-patterns (tautological assertions, implementation mirroring, mock-everything)

5. Validation — Run the project's test suite to confirm all new tests pass. Run @test-quality-review-agent on the generated tests.

6. Handoff — Offer to commit via /create-commit.

Reuse contract

When invoked by another skill (e.g., /build), /test should:

• Accept a narrowed scope (specific files to test)
• Skip the handoff/commit step (caller handles that)
• Return a summary of what was tested and any issues found

This mirrors how /create-pr accepts skip-checks when called from /build.

Key constraints

• Tech-agnostic — discovers the test framework from the project, never assumes one
• Never modifies production code — only creates/updates test files
• Follows the same quality bar as /build: every testable unit gets tests, no tautological assertions, behavior over implementation

Additional context

Related agents: @test-quality-review-agent already exists and should be used for validation.

Related skills that would benefit from reuse:

• /build Phase 2 Step 2 (test writing alongside implementation)
• /hotfix Phase 3 Step 2 (regression tests for bug fixes)

Start by reading the inline test-writing instructions in /build Phase 2 Step 2 and /hotfix Phase 3 Step 2, then compare /review's branch-diff scope detection. Define the reusable /test skill around the listed scope, convention-discovery, validation, and handoff behavior, including its reuse contract. Done means the standalone workflow and delegation paths are specified consistently and use @test-quality-review-agent for validation.