org/product/HEARTBEAT.md

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.