Merge pull request #61 from privilegedescalation/feat/product-context-skill
Add product-context skill
This commit was merged in pull request #61.
This commit is contained in:
privilegedescalation-ceo[bot]
@@ -12,6 +12,7 @@ This is the **Privileged Escalation org-level repository**. It contains company-
|
||||
- `skills/safety/SKILL.md` — Non-negotiable safety rules (secret handling, destructive action restrictions, sealed-secrets workflow, escalation protocol)
|
||||
- `skills/sdlc/SKILL.md` — Software development lifecycle rules (GitHub auth, issue approval gates, branch strategy, PR review policy, handoff protocol, CI/CD)
|
||||
- `skills/coding-standards/SKILL.md` — Headlamp plugin development conventions (stack, commands, registration API, shared libraries)
|
||||
- `skills/product-context/SKILL.md` — Product context (plugin portfolio, target users, competitive landscape, evaluation framework, feature spec template)
|
||||
|
||||
## Skill File Format
|
||||
|
||||
@@ -31,4 +32,4 @@ Content...
|
||||
|
||||
## Skill Loading Order
|
||||
|
||||
Skills are loaded by Paperclip in this order: `safety` → `sdlc` → `coding-standards`. Later skills can assume earlier ones are already loaded and should not duplicate their content.
|
||||
Skills are loaded by Paperclip in this order: `safety` → `sdlc` → `coding-standards` → `product-context`. Later skills can assume earlier ones are already loaded and should not duplicate their content.
|
||||
|
||||
@@ -0,0 +1,118 @@
|
||||
---
|
||||
name: product-context
|
||||
description: >
|
||||
Product context for Privileged Escalation. Covers current plugin portfolio,
|
||||
target users, competitive landscape, plugin evaluation framework, and feature
|
||||
spec template.
|
||||
---
|
||||
|
||||
# Product Context
|
||||
|
||||
Load this section when triaging feature requests, evaluating new plugin proposals, or writing specs.
|
||||
|
||||
## Current plugin portfolio
|
||||
|
||||
| Plugin | Repo | What it does | Status |
|
||||
| ------------------ | -------------------------------- | ----------------------------------------------- | ------ |
|
||||
| **Polaris** | `headlamp-polaris-plugin` | Kubernetes best practice validation and scoring | Active |
|
||||
| **Kube-VIP** | `headlamp-kube-vip-plugin` | Kube-VIP load balancer management | Active |
|
||||
| **Rook/Ceph** | `headlamp-rook-plugin` | Rook-Ceph storage cluster monitoring | Active |
|
||||
| **Sealed Secrets** | `headlamp-sealed-secrets-plugin` | Bitnami Sealed Secrets management | Active |
|
||||
| **Intel GPU** | `headlamp-intel-gpu-plugin` | Intel GPU device plugin monitoring | Active |
|
||||
| **TrueNAS CSI** | `headlamp-tns-csi-plugin` | TrueNAS SCALE CSI driver monitoring | Active |
|
||||
|
||||
All plugins distributed via **ArtifactHub**, installed through Headlamp's native plugin installer only.
|
||||
|
||||
## Target users
|
||||
|
||||
**Primary: The Platform Engineer**
|
||||
|
||||
* Manages 1-50 Kubernetes clusters, mid-size company (100-2000 employees)
|
||||
* Pain point: "I have 15 tools open to monitor my clusters. I want one dashboard that shows me everything."
|
||||
* Very high tech comfort. Knows Kubernetes deeply. Will read your source code.
|
||||
* Will adopt a plugin in 5 minutes if it solves a real problem. Will drop it in 5 seconds if it's buggy or doesn't add value over `kubectl`.
|
||||
|
||||
**Secondary: The DevOps Lead / SRE Manager**
|
||||
|
||||
* Manages a platform team, responsible for cluster health and reliability.
|
||||
* Wants plugins that visualize what matters and surface problems proactively — NOT another monitoring tool.
|
||||
|
||||
**Anti-persona: The Application Developer**
|
||||
|
||||
App developers care about their deployments, not the cluster. Features like "show me my pod logs" are already in Headlamp core. Don't build for them.
|
||||
|
||||
## Scope
|
||||
|
||||
**In scope**
|
||||
|
||||
* Headlamp plugins that visualize and manage specific Kubernetes ecosystem tools
|
||||
* Plugins that surface operational insights not available in Headlamp core
|
||||
* Plugins for CNCF projects and widely-adopted K8s ecosystem tools
|
||||
* ArtifactHub packaging and distribution
|
||||
|
||||
**Explicitly out of scope**
|
||||
|
||||
* Plugins that duplicate Headlamp core functionality
|
||||
* Non-Kubernetes tools
|
||||
* Hosted/SaaS versions of plugins
|
||||
* Helm-based or sidecar-based plugin installation
|
||||
* Custom Headlamp forks
|
||||
* Monitoring/alerting backends (we visualize, we don't collect metrics)
|
||||
* Multi-cluster management
|
||||
* CLI tools
|
||||
|
||||
## Competitive landscape
|
||||
|
||||
| Competitor | Where PRI differs |
|
||||
| -------------------------------- | ----------------------------------------------------------------------------------- |
|
||||
| **Headlamp core** | We extend it, not compete. If a feature belongs in core, contribute upstream. |
|
||||
| **Lens** | Heavy, desktop-only, commercial. We make web-based, open source Headlamp better. |
|
||||
| **k9s** | Different modality (TUI vs web). Not competitive. |
|
||||
| **Komodor / Kubecost / Robusta** | Standalone products. Our plugins bring their insights INTO Headlamp. Complementary. |
|
||||
|
||||
PRI's moat: leading third-party Headlamp plugin developer. Plugins are free, open source, on ArtifactHub.
|
||||
|
||||
## Plugin evaluation framework
|
||||
|
||||
1. **Is there a widely-adopted K8s ecosystem tool that lacks Headlamp visibility?**
|
||||
* Fewer than 1,000 GitHub stars or in alpha → too early. Close with "revisit when more mature."
|
||||
* Already has a Headlamp plugin → duplicate. Close.
|
||||
2. **Does the plugin add value over `kubectl` + the tool's own CLI/UI?**
|
||||
* "It shows the same thing but in Headlamp" → weak value prop. Good plugins correlate data, surface problems proactively, simplify complex operations.
|
||||
3. **Can Gandalf build and maintain it?**
|
||||
* One engineer can maintain ~6-8 plugins at current complexity. We're at 6 now. New plugins mean either dropping an existing one or hiring.
|
||||
4. **Is it installable via ArtifactHub without extras?**
|
||||
* Plugin requires CRDs/RBAC/cluster resources installed separately → degraded experience.
|
||||
* Unacceptable: plugin requires its own operator or sidecar.
|
||||
|
||||
**Priority tiers**
|
||||
|
||||
* **P0**: Bugs in existing plugins that break functionality or produce incorrect data
|
||||
* **P1**: Enhancements to existing plugins users are requesting
|
||||
* **P2**: New plugins for high-value K8s tools with clear user demand
|
||||
* **P3**: Speculative plugins, cross-plugin features, UX experiments
|
||||
|
||||
## Feature spec template
|
||||
|
||||
```markdown
|
||||
## Problem
|
||||
What operational visibility or capability is missing? Who needs it? What do they do today instead?
|
||||
|
||||
## Proposed Solution
|
||||
What should the plugin show or enable that isn't available today?
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] Plugin displays...
|
||||
- [ ] User can...
|
||||
- [ ] Data is accurate when compared to `kubectl` / native CLI output
|
||||
- [ ] Works with [tool name] version X.Y+
|
||||
- [ ] Installable via ArtifactHub without additional cluster-level setup
|
||||
- [ ] Has unit tests covering core display logic
|
||||
|
||||
## Out of Scope for This Issue
|
||||
## Dependencies
|
||||
What must exist in the cluster for this plugin to work? (CRDs, operators, RBAC)
|
||||
|
||||
## Priority
|
||||
P0/P1/P2/P3 with one-sentence justification.
|
||||
```
|
||||
Reference in New Issue
Block a user