azcomputerguru/claudetools
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(feature-request): comprehensive specification generation

Browse Source 
Enhanced /feature-request skill to produce full specifications instead
of simple classification messages.

NEW CAPABILITIES:
- Phase 1: Load all project context (roadmap, UI gaps, coding guidelines)
- Phase 2: Ollama-powered classification with similarity analysis
- Phase 3: Codebase search + external research (WebSearch for standards)
- Phase 4: Consult coding guidelines for patterns
- Phase 5: Ollama-generated comprehensive spec (architecture, security, testing)
- Phase 6: Roadmap placement with dependency analysis
- Phase 7: Write formal SPEC-XXX-feature-name.md document
- Phase 8: Update roadmap with links
- Phase 9: Commit to git with proper messages
- Phase 10: Send coord message (if Howard submitted)
- Phase 11: Comprehensive summary to user

SPEC DOCUMENT INCLUDES:
- Overview with use cases and success criteria
- Scope (v1 included + explicitly out of scope)
- Architecture (components, data flow, schema, API endpoints)
- Implementation details (agent/server/dashboard file paths, code patterns)
- Security considerations (auth, validation, audit, threat model)
- Testing strategy (unit, integration, manual scenarios)
- Rollout plan (feature flags, backward compat, migration)
- Effort estimate (Small/Medium/Large/X-Large with breakdown)
- Dependencies (requires/enables)
- Open questions

SUBMODULE UPDATE:
- Created docs/specs/ directory structure
- Added README with naming conventions and status lifecycle

The skill now takes 2-5 minutes but produces sprint-ready specifications
with complete architecture analysis and implementation guidance.

Requested by Mike.
This commit is contained in:
Mike Swanson
2026-05-24 09:58:58 -07:00
parent c594c5cd43
commit 5bc6b04b50
2 changed files with 437 additions and 63 deletions
Download Patch File Download Diff File Expand all files Collapse all files

498
.claude/commands/feature-request.md
View File

@@ -1,99 +1,473 @@
Howard is submitting a GuruRMM feature request. Follow these steps exactly.
GuruRMM Feature Request — Comprehensive Analysis & Specification
When Howard (or Mike) submits a feature request, conduct full research and produce a detailed specification with implementation recommendations.
---
## Step 1 — Read context
## Phase 1 — Context Loading
Read `.claude/identity.json` to get the machine hostname (for session ID and Ollama endpoint).
1. **Read identity and machine info:**
- `.claude/identity.json` — hostname, user, Ollama endpoint
Read `projects/msp-tools/guru-rmm/docs/FEATURE_ROADMAP.md`. Extract the top-level section headers
and a representative sample of subsections so you understand the existing structure.
Do NOT print the roadmap to the user.
2. **Read project documentation:**
- `projects/msp-tools/guru-rmm/docs/FEATURE_ROADMAP.md` — existing features, structure, priorities
- `projects/msp-tools/guru-rmm/docs/UI_GAPS.md` — current UI implementation status
- `.claude/CODING_GUIDELINES.md` — code standards, patterns, architecture rules
- `projects/msp-tools/guru-rmm/CONTEXT.md` — current project state, tech stack, architecture
3. **Determine Ollama endpoint:**
- `DESKTOP-0O8A1RL`: `http://localhost:11434`
- All other machines: `http://100.92.127.64:11434`
---
## Step 2 — Classify the feature using Ollama
## Phase 2 — Initial Classification (Ollama)
The feature request is: $ARGUMENTS
Call Ollama with model `qwen3.6:latest` (strict JSON) to perform initial classification:
Determine the Ollama endpoint:
- If hostname is `DESKTOP-0O8A1RL`: use `http://localhost:11434`
- All other machines (including Howard's): use `http://100.92.127.64:11434`
Call Ollama with model `qwen3:14b` to classify the request. Ask it to return:
1. Which top-level roadmap section this belongs in (e.g., "Core Agent Features", "Server/API Features",
"Dashboard & UI", "Platform & Infrastructure", "Integrations", "Future Considerations")
2. Suggested subsection — match an existing one if it fits; propose a new name if it doesn't
3. Suggested priority (P1 = critical/blocking, P2 = important/near-term, P3 = nice-to-have)
4. A 2-3 sentence plain-English summary of what Howard is asking for
Use this prompt structure for the Ollama call:
**Prompt:**
```
You are helping classify a feature request for GuruRMM, a Remote Monitoring & Management tool
for MSPs. The roadmap sections are: Core Agent Features, Server/API Features, Dashboard & UI,
Platform & Infrastructure, Integrations, Future Considerations.
You are analyzing a feature request for GuruRMM, a Rust/Axum/TypeScript RMM tool for MSPs.
Feature request: <$ARGUMENTS>
Roadmap sections: Core Agent Features, Server/API Features, Dashboard & UI, Platform & Infrastructure, Integrations, Security Features, Future Considerations.
Respond with JSON only: {"section": "...", "subsection": "...", "priority": "P1|P2|P3", "summary": "..."}
Feature request: $ARGUMENTS
Respond with JSON only:
{
"section": "...",
"subsection": "...",
"priority": "P1|P2|P3",
"brief_summary": "1-2 sentence plain English summary",
"similar_features": ["list of similar/related features that might already exist"],
"research_needed": ["list of areas requiring investigation before implementation"]
}
```
Parse the JSON response. If Ollama is unreachable, perform the classification yourself directly.
If Ollama unreachable, perform classification yourself.
---
## Step 3 — Send coord message to Mike
## Phase 3 — Research & Investigation
Post a message to the coord API:
Based on the classification and research_needed list:
### 3.1 — Codebase Search
Search for similar/related implementations:
- Use Grep to search for related functionality in `projects/msp-tools/guru-rmm/`
- Check `server/src/` for API patterns
- Check `agent/src/` for agent-side functionality
- Check `dashboard/src/` for UI patterns
- Identify existing code that could be extended vs. new code needed
### 3.2 — External Research (if needed)
If the feature involves:
- Industry standards (e.g., SNMP, Syslog, API protocols): WebSearch for best practices
- Security implications: Research common vulnerabilities and mitigations
- Third-party integrations: Check if APIs/SDKs exist
- Platform-specific behavior: Research OS-level APIs (Windows/Linux/macOS)
### 3.3 — Architecture Analysis
Consider:
- Where does this feature fit in the architecture? (agent, server, dashboard, all three?)
- What database schema changes are needed?
- What API endpoints are needed?
- Are there performance/scalability implications?
- Security considerations?
---
## Phase 4 — Consult Coding Guidelines
Read `.claude/CODING_GUIDELINES.md` and identify relevant patterns:
- Error handling requirements
- API design patterns
- Database conventions
- Frontend patterns
- Security requirements
- Testing requirements
---
## Phase 5 — Specification Generation (Ollama)
Use Ollama with model `qwen3:14b` (prose) to generate comprehensive specification:
**Prompt:**
```
You are writing a detailed implementation specification for a GuruRMM feature.
FEATURE REQUEST: $ARGUMENTS
RESEARCH FINDINGS:
- Classification: <section/subsection/priority>
- Similar existing features: <list>
- Codebase search results: <relevant files/patterns found>
- External research: <standards, best practices, security considerations>
- Architecture fit: <where it belongs in the system>
CODING GUIDELINES REQUIREMENTS:
<relevant excerpts from CODING_GUIDELINES.md>
Write a comprehensive specification with these sections:
1. OVERVIEW
- What the feature does (2-3 sentences)
- User-facing benefit
- Primary use cases
2. SCOPE
- What's included in v1
- What's explicitly out of scope (for future)
- Success criteria
3. ARCHITECTURE
- Components involved (agent/server/dashboard)
- Data flow
- Database schema changes
- API endpoints needed
4. IMPLEMENTATION DETAILS
Agent (if applicable):
- Files to modify/create
- Rust structs/enums needed
- IPC commands (if any)
Server (if applicable):
- API routes
- Database migrations
- Business logic modules
Dashboard (if applicable):
- New pages/components
- State management
- API integration
5. SECURITY CONSIDERATIONS
- Authentication/authorization requirements
- Input validation
- Audit logging
- Potential vulnerabilities and mitigations
6. TESTING STRATEGY
- Unit tests needed
- Integration tests
- Manual test scenarios
7. ROLLOUT PLAN
- Feature flag approach
- Backward compatibility
- Migration path
- Documentation needs
8. EFFORT ESTIMATE
- Small (1-2 days), Medium (3-5 days), Large (1-2 weeks), X-Large (2+ weeks)
- Breakdown by component
Be specific and actionable. Reference actual file paths, struct names, and patterns from the codebase.
```
If Ollama unreachable, write the specification yourself using the research findings.
---
## Phase 6 — Roadmap Placement Analysis
Analyze the FEATURE_ROADMAP.md structure to determine:
1. **Exact placement:** Which existing subsection does this belong in? Or does it need a new subsection?
2. **Build sequencing:** Based on the roadmap structure and existing priorities:
- What features must be built before this one? (dependencies)
- What features does this unblock? (enables)
- Which sprint/milestone does this fit into?
3. **Priority justification:**
- P1: Blocks other critical features, security-critical, or MVP requirement
- P2: Important for competitive parity, customer requests, or usability
- P3: Nice-to-have, future enhancement, or edge case
---
## Phase 7 — Write Specification Document
Create a new file: `projects/msp-tools/guru-rmm/docs/specs/SPEC-XXX-<feature-name>.md`
Where XXX is the next available number (check existing specs directory).
**File format:**
```markdown
# SPEC-XXX: <Feature Name>
**Status:** Proposed
**Priority:** P1/P2/P3
**Requested By:** <Howard|Mike> (<date>)
**Estimated Effort:** <Small|Medium|Large|X-Large>
---
## Overview
<2-3 sentence summary>
**Use Cases:**
- <primary use case>
- <secondary use case>
**Success Criteria:**
- <measurable criteria>
---
## Scope
### Included in v1
- <feature 1>
- <feature 2>
### Explicitly Out of Scope
- <future enhancement>
---
## Architecture
### Components
- **Agent:** <what agent does>
- **Server:** <what server does>
- **Dashboard:** <what dashboard does>
### Data Flow
<step-by-step description or diagram>
### Database Schema
```sql
-- New tables or columns
```
### API Endpoints
- `POST /api/...` — <description>
- `GET /api/...` — <description>
---
## Implementation Details
### Agent (`agent/src/`)
**Files to modify:**
- `agent/src/xyz.rs` — <what changes>
**New structs/enums:**
```rust
// Example code
```
### Server (`server/src/`)
**Files to modify:**
- `server/src/routes/xyz.rs` — <what changes>
**Database migrations:**
- `migrations/YYYYMMDD_feature_name.sql`
### Dashboard (`dashboard/src/`)
**New components:**
- `dashboard/src/components/XyzFeature.tsx` — <description>
**API integration:**
- Use `useQuery` for GET, `useMutation` for POST/PUT
---
## Security Considerations
- **Authentication:** <requirements>
- **Authorization:** <who can access>
- **Input Validation:** <validation rules>
- **Audit Logging:** <what to log>
- **Threat Model:** <potential attacks and mitigations>
---
## Testing Strategy
### Unit Tests
- `agent/tests/xyz_test.rs` — <test scenarios>
- `server/tests/api/xyz_test.rs` — <test scenarios>
### Integration Tests
- <end-to-end test scenarios>
### Manual Testing
1. <test step 1>
2. <test step 2>
---
## Rollout Plan
1. **Feature flag:** `feature.xyz.enabled` (default: false)
2. **Database migration:** Apply schema changes
3. **Agent update:** Deploy agent with feature flag check
4. **Dashboard deploy:** UI available when feature enabled
5. **Documentation:** Update user guide
### Backward Compatibility
<how older agents/servers handle this>
---
## Dependencies
**Must be completed first:**
- <existing feature or infrastructure>
**Enables future features:**
- <what this unblocks>
---
## Open Questions
- <question 1>
- <question 2>
---
## References
- Related roadmap section: <link>
- Similar implementations: <links to code>
- External documentation: <links>
---
**Next Steps:**
1. Review specification with team
2. Refine based on feedback
3. Move to sprint backlog
4. Assign to developer
```
---
## Phase 8 — Update Roadmap
Add or update the feature in `FEATURE_ROADMAP.md`:
- If it fits an existing subsection, add it there
- If it needs a new subsection, create one
- Link to the spec document: `[Feature Name](docs/specs/SPEC-XXX-feature-name.md) - P2`
- Add checkboxes for sub-tasks if applicable
---
## Phase 9 — Commit Changes
```bash
cd projects/msp-tools/guru-rmm
git add docs/specs/SPEC-XXX-feature-name.md docs/FEATURE_ROADMAP.md
git commit -m "spec: add SPEC-XXX <feature name>
Comprehensive specification for <brief description>.
Requested by <Howard|Mike>.
- Full architecture analysis
- Implementation details across agent/server/dashboard
- Security considerations
- Effort estimate: <Small|Medium|Large|X-Large>
- Priority: P1/P2/P3
- Added to roadmap under <section>/<subsection>"
git push origin main
```
Then update submodule pointer in parent repo:
```bash
cd /Users/azcomputerguru/ClaudeTools
git add projects/msp-tools/guru-rmm
git commit -m "chore: update guru-rmm submodule (SPEC-XXX <feature name>)"
git push origin main
```
---
## Phase 10 — Send Coord Message (if requested by Howard)
If Howard submitted this (not Mike), send a coord message:
```bash
curl -s -X POST http://172.16.3.30:8001/api/coord/messages \
-H "Content-Type: application/json" \
-d '{
"from_session": "<HOSTNAME>/claude-main",
"to_session": "DESKTOP-0O8A1RL/claude-main",
"to_session": "ALL_SESSIONS",
"project_key": "gururmm",
"subject": "Feature Request from Howard: <brief title>",
"body": "<full body — see format below>"
"subject": "Feature Spec Complete: <feature name>",
"body": "Howard submitted a feature request. Full specification created.\n\nSPEC: docs/specs/SPEC-XXX-<feature-name>.md\n\nPriority: <P1/P2/P3>\nEffort: <Small|Medium|Large|X-Large>\nPlacement: <section>/<subsection>\n\nSummary:\n<2-3 sentence summary>\n\nReady for review and sprint planning."
}'
```
Where `<HOSTNAME>` comes from identity.json.
**Message body format:**
```
Howard submitted a feature request for GuruRMM.
FEATURE REQUEST
===============
<$ARGUMENTS verbatim>
PROPOSED PLACEMENT
==================
Section: <section from Ollama>
Subsection: <subsection from Ollama>
Priority: <P1/P2/P3>
SUMMARY
=======
<2-3 sentence summary from Ollama>
---
Submitted via /feature-request from <HOSTNAME> at <timestamp>
```
Send to `to_session: "DESKTOP-0O8A1RL/claude-main"` and also to `"Mikes-MacBook-Air/claude-main"`
so Mike sees it regardless of which machine he's on.
## Phase 11 — Response to User
Provide a comprehensive summary:
```
[SUCCESS] Feature specification created
SPEC-XXX: <Feature Name>
Priority: P1/P2/P3
Effort: <Small|Medium|Large|X-Large>
Placement: <section>/<subsection>
OVERVIEW
<2-3 sentence summary>
KEY COMPONENTS
- Agent: <brief>
- Server: <brief>
- Dashboard: <brief>
SECURITY CONSIDERATIONS
- <key security points>
DEPENDENCIES
- Requires: <list>
- Enables: <list>
FILES CREATED
- docs/specs/SPEC-XXX-<feature-name>.md (full specification)
- Updated FEATURE_ROADMAP.md
The specification includes:
✓ Complete architecture analysis
✓ Implementation details for all components
✓ Security threat model and mitigations
✓ Testing strategy
✓ Rollout plan with feature flags
✓ Effort breakdown
<If Howard submitted:>
Coord message sent to Mike for review and sprint planning.
<Next steps based on priority:>
P1: Schedule for immediate sprint
P2: Add to near-term backlog
P3: Track for future consideration
```
---
## Step 4 — Acknowledge to Howard
## Error Handling
Tell Howard:
- If Ollama unreachable: Perform all analysis yourself (no degradation)
- If coord API fails: Warn user but continue (they can manually notify Mike)
- If spec number conflicts: Check existing specs and use next available
- If roadmap section unclear: Create new subsection rather than force-fit
- His request was submitted to Mike
- Where you've suggested it fits in the roadmap (section + subsection)
- Suggested priority
- That Mike will review and decide if/how/when to build it
---
Keep it brief — one short paragraph. Do NOT say "I" did anything — say the request was sent.
## Notes
- This command can take 2-5 minutes due to research and specification generation
- The specification is a living document — can be refined during sprint planning
- Feature flags ensure safe rollout even for partially complete features
- Effort estimates are initial and may be revised during implementation

2
projects/msp-tools/guru-rmm

Submodule projects/msp-tools/guru-rmm updated: afefaaa841...a775f90e96