Files
claudetools/.claude/commands/gc-feature-request.md
2026-05-29 07:33:25 -07:00

4.3 KiB

GuruConnect Feature Request — Analysis & Specification

Produce a researched specification for a GuruConnect feature, place it in the GC roadmap, and commit it. GuruConnect is a standalone remote-support product (separate repo azcomputerguru/guru-connect, tracked as the projects/msp-tools/guru-connect submodule). Do NOT confuse it with GuruRMM — see its ADR-001. Use /feature-request for GuruRMM instead.

$ARGUMENTS = the feature request text.


Phase 1 — Context

Read:

  • projects/msp-tools/guru-connect/docs/FEATURE_ROADMAP.md — sections, priorities, existing items
  • projects/msp-tools/guru-connect/docs/ARCHITECTURE_DECISIONS.md — ADRs (esp. ADR-001 standalone+contract)
  • projects/msp-tools/guru-connect/CLAUDE.md — architecture, design constraints, coding standards
  • projects/msp-tools/guru-connect/docs/specs/ — existing SPEC-NNN files (to pick the next number)

GuruConnect architecture vocabulary: agent (Windows capture/input/viewer), relay-server (Axum), viewer (native + React/TS web viewer), dashboard. Transport: protobuf-over-WSS.

Phase 2 — Classify (Ollama)

Call Ollama qwen3.6:latest (strict JSON). Endpoint from .claude/identity.json (.ollama.endpoint).

Analyze a feature request for GuruConnect, a Rust remote-desktop product (agent + Axum relay +
native/web viewer), protobuf-over-WSS.
Roadmap sections: Core Remote Control, GuruRMM Integration, Server/API, Security & Infrastructure,
Operational Tooling, Future Considerations.
Feature request: $ARGUMENTS
Respond JSON only: {"section","subsection","priority":"P1|P2|P3","brief_summary",
"similar_features":[],"research_needed":[]}

If Ollama is unreachable, classify yourself.

Phase 3 — Research

  • Grep projects/msp-tools/guru-connect/{agent,server,dashboard,proto}/ for related code; cite file:line.
  • Note where the feature lives (agent / relay-server / viewer / dashboard / proto / DB migration).
  • If it touches the GuruRMM integration surface, cross-reference docs/specs/native-remote-control/ and keep the integration contract authoritative (GC owns it).

Phase 4 — Write the spec

Next number = highest existing SPEC-NNN + 1. Write docs/specs/SPEC-NNN-<slug>.md:

# SPEC-NNN: <Feature Name>

**Status:** Proposed
**Priority:** P1|P2|P3
**Requested By:** <Mike|Howard> (<date>)
**Estimated Effort:** Small|Medium|Large|X-Large

## Overview
<2-3 sentences; user-facing benefit; primary use cases; success criteria>

## Scope
### Included in v1
### Explicitly out of scope

## Architecture
- Agent / Relay-server / Viewer / Dashboard responsibilities
- Protobuf changes (`proto/guruconnect.proto`)
- DB schema (migrations)
- API endpoints / WS messages

## Implementation details
- Files to touch (file:line where known), structs/messages, key logic

## Security considerations
- Auth (JWT/agent key/support code), input validation, audit events, threat model

## Testing strategy
- Unit / integration / manual scenarios

## Effort estimate & dependencies
- Size; what must precede it; what it unblocks

## Open questions

Generate the prose via Ollama qwen3:14b if available (fallback: write it yourself). Be specific — real file paths and message/struct names from Phase 3.

Phase 5 — Roadmap

Add/insert the item in the right docs/FEATURE_ROADMAP.md section: - [ ] **<Feature>** — P<n> — <one-liner>. (SPEC-NNN) with a link to the spec.

Phase 6 — Commit (GC submodule, then bump pointer)

cd projects/msp-tools/guru-connect
git add docs/specs/SPEC-NNN-<slug>.md docs/FEATURE_ROADMAP.md
git commit -m "spec: add SPEC-NNN <feature name>"
# push only if the user asks; pushing main triggers GC CI
cd ../../..
git add projects/msp-tools/guru-connect
git commit -m "chore: bump guru-connect submodule (SPEC-NNN <feature name>)"

Phase 7 — Optional coord message

If Howard submitted it (not Mike), POST to the coord API with project_key: "guruconnect", subject "GC Feature Spec: ", summarizing the spec for Mike's review.

Phase 8 — Respond

Summarize: SPEC number, priority, effort, placement, overview, key components, dependencies, files created. Use ASCII markers ([SUCCESS]/[INFO]); no emojis.

Notes

  • Never edit GuruConnect product code as part of "RMM work"; this skill is the GC product's own intake.
  • Spec is a living doc; refine during planning.