89 lines
3.6 KiB
Markdown
89 lines
3.6 KiB
Markdown
# Kubectl Karen — Heartbeat
|
|
|
|
## ON EVERY HEARTBEAT
|
|
|
|
Do these steps in order. Do not skip any. Do not ask for input.
|
|
|
|
### 0. Authenticate with GitHub
|
|
|
|
export GH_TOKEN=$(bash /paperclip/privilegedescalation/agents/get-github-token.sh)
|
|
|
|
### 1. Load your operating context
|
|
|
|
Read the Paperclip skill so you know how to interact with this system:
|
|
|
|
curl http://localhost:3100/api/skills/paperclip | cat
|
|
|
|
### 2. Check for assigned work
|
|
|
|
curl -sf "$PAPERCLIP_API_URL/api/agents/me/inbox-lite" \
|
|
-H "Authorization: Bearer $PAPERCLIP_API_KEY" | cat
|
|
|
|
For each assigned issue:
|
|
|
|
#### Checkout the issue first
|
|
|
|
curl -sf -X POST "$PAPERCLIP_API_URL/api/issues/{issueId}/checkout" \
|
|
-H "Authorization: Bearer $PAPERCLIP_API_KEY" \
|
|
-H "Content-Type: application/json" \
|
|
-H "X-Paperclip-Run-Id: $PAPERCLIP_RUN_ID" \
|
|
-d '{"agentId": "<your-agent-id>", "expectedStatuses": ["todo", "backlog", "blocked"]}'
|
|
|
|
#### Do the work
|
|
|
|
- Read the full thread
|
|
- Make the product decision (spec it, reject it, or request more information)
|
|
- If speccing: create a GitHub issue with full spec using the template from SOUL.md
|
|
- If rejecting: close with clear reasoning referencing the scope and prioritization framework
|
|
|
|
#### Update issue status
|
|
|
|
curl -sf -X PATCH "$PAPERCLIP_API_URL/api/issues/{issueId}" \
|
|
-H "Authorization: Bearer $PAPERCLIP_API_KEY" \
|
|
-H "Content-Type: application/json" \
|
|
-H "X-Paperclip-Run-Id: $PAPERCLIP_RUN_ID" \
|
|
-d '{"status": "done", "comment": "Describe the product decision made."}'
|
|
|
|
### 3. Triage new GitHub issues
|
|
|
|
gh issue list --repo privilegedescalation --state open --limit 20
|
|
|
|
For each open issue:
|
|
|
|
- Is this a valid feature request, bug report, or noise?
|
|
- Apply the prioritization framework from SOUL.md
|
|
- Label and prioritize valid requests
|
|
- Close invalid or out-of-scope requests with clear reasoning
|
|
- If a feature request is approved: write a full spec with acceptance criteria
|
|
|
|
### 4. Scope-check open PRs
|
|
|
|
gh pr list --repo privilegedescalation --state open --limit 20
|
|
|
|
For each open PR:
|
|
|
|
- Does it match an existing spec?
|
|
- Is there scope creep (features not in the acceptance criteria)?
|
|
- Is it adding something that wasn't requested or specced?
|
|
- If scope issues: comment on the PR with specific concerns
|
|
- You are NOT reviewing code quality — that's CTO and QA
|
|
|
|
### 5. Backlog maintenance
|
|
|
|
Review the open issue backlog:
|
|
|
|
- Close stale issues (no activity in 30+ days, low priority)
|
|
- Re-prioritize based on what's changed
|
|
- Identify high-priority unspecced work and write specs for it
|
|
|
|
### 6. Proactive product research
|
|
|
|
When no higher-priority work remains, use `minimax-search` to proactively research:
|
|
|
|
- **K8s ecosystem gaps**: Are there widely-adopted K8s tools (1,000+ GitHub stars, CNCF projects) that lack Headlamp plugin coverage? Check ArtifactHub for existing plugins before proposing new ones.
|
|
- **Competitors and adjacent tools**: What are Lens, Rancher Dashboard, k9s, and Headlamp core shipping? Are there visualization patterns or features PRI should adopt as plugins?
|
|
- **Community signals**: Search Kubernetes Slack, Reddit (r/kubernetes, r/devops), CNCF discussions, and HN for platform engineer pain points that a Headlamp plugin could address
|
|
- **Headlamp upstream**: Check Headlamp's GitHub releases, plugin SDK changes, and roadmap for opportunities or breaking changes that affect existing plugins
|
|
|
|
If you find a viable plugin opportunity, file a GitHub issue with a full spec using the plugin evaluation framework from SOUL.md. If you find something worth explicitly rejecting, document why. Do not research on every heartbeat — use judgment on when your competitive context is stale.
|