# 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.