sigrok-mcp-server: Skill for Claude Code

GitHub Issue Manager

A skill for creating and updating GitHub Issues. Organizes development plans into a structured format within Issues.

Workflow

1. Gather Information

Understand the following from the user's request. Investigate the codebase to fill in any gaps.

• What needs to be achieved
• Why it is needed (background / motivation)
• Preliminary technical approach
• Completion criteria

2. Codebase Investigation

Investigate related code to accurately describe the implementation approach and impact scope.

• Identify the components and files to be changed
• Review existing implementation patterns
• Enumerate existing features that may be affected

When investigating, refer to the project's package structure:

• cmd/sigrok-mcp-server/ — Entrypoint (thin wiring, no tests needed)
• internal/tools/ — MCP tool handlers; uses Runner interface for mock injection
• internal/sigrok/ — CLI executor and parsers; uses CommandFactory test seam and testdata/ golden files
• internal/serial/ — Serial port communication; uses PortOpener seam
• internal/devices/ — Device profile registry with embedded JSON
• internal/config/ — Env-based configuration

3. Issue Body Structure

Compose the body following the template below. All sections should be included. When updating an existing Issue, maintain the same section structure from the template.

## Summary

<!-- What will be done. 1-2 sentences, concise. -->

## Background & Motivation

<!-- Why this is needed. User-experience issues, technical problems, etc. -->

## Implementation Approach

<!-- Technical approach. Files, components, and steps to change. -->

## Impact Scope

<!-- Scope of changes, effects on existing features, caveats. -->

## Test Strategy

<!-- Describe the testing approach:
  - Which test seams to use (Runner mock, CommandFactory, PortOpener, etc.)
  - Table-driven test cases to cover
  - Corner cases and boundary conditions
  - Error and exception scenarios (invalid input, timeouts, non-zero exit codes)
  - Silent failure scenarios (nil dependencies, empty output, missing fields)
-->

## DoD (Definition of Done)

- [ ] Completion criterion 1
- [ ] Completion criterion 2
- [ ] Tests cover the happy path
- [ ] Tests cover corner cases and error scenarios
- [ ] No silent failures (errors are surfaced, not swallowed)
- [ ] CI passes