From 5c6ff8fb52eb98f49aa7d381e3a0d7764cdc16f9 Mon Sep 17 00:00:00 2001 From: Mike Swanson Date: Fri, 29 May 2026 07:19:47 -0700 Subject: [PATCH] feat: add /gc-feature-request skill; register guruconnect coord key Co-Authored-By: Claude Opus 4.8 (1M context) --- .claude/CLAUDE.md | 1 + .claude/commands/gc-feature-request.md | 117 +++++++++++++++++++++++++ 2 files changed, 118 insertions(+) create mode 100644 .claude/commands/gc-feature-request.md diff --git a/.claude/CLAUDE.md b/.claude/CLAUDE.md index 86ce71a..a3bf01b 100644 --- a/.claude/CLAUDE.md +++ b/.claude/CLAUDE.md @@ -192,6 +192,7 @@ curl -s -X PUT "http://172.16.3.30:8001/api/coord/components/gururmm/server" \ | project_key | Components | States | |-------------|------------|--------| | `gururmm` | `server`, `agents`, `dashboard`, `db_migrations` | `building`, `built`, `deploying`, `deployed`, `degraded` | +| `guruconnect` | `server`, `agent`, `dashboard` | `building`, `built`, `deploying`, `deployed`, `degraded` | | `claudetools` | `api`, `db_migrations`, `coord_api` | `deploying`, `deployed`, `degraded` | | `dataforth-dos` | `app`, `db` | `active`, `idle`, `degraded` | | `clients/` | `(free-form)` | `(free-form)` | diff --git a/.claude/commands/gc-feature-request.md b/.claude/commands/gc-feature-request.md new file mode 100644 index 0000000..c8cae7c --- /dev/null +++ b/.claude/commands/gc-feature-request.md @@ -0,0 +1,117 @@ +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-.md`: + +```markdown +# SPEC-NNN: + +**Status:** Proposed +**Priority:** P1|P2|P3 +**Requested By:** () +**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: +`- [ ] **** — P — . (SPEC-NNN)` with a link to the spec. + +## Phase 6 — Commit (GC submodule, then bump pointer) + +```bash +cd projects/msp-tools/guru-connect +git add docs/specs/SPEC-NNN-.md docs/FEATURE_ROADMAP.md +git commit -m "spec: add SPEC-NNN " +# 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 )" +``` + +## 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.