kova-pr-maintainer

Review, label, and land Kova GitHub pull requests with evidence-first triage.

Updated Aug 23, 2026
One-click install
npx skills add https://github.com/chiragborse1/KovaLab --skill kova-pr-maintainer
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: kova-pr-maintainer
Source: https://github.com/chiragborse1/KovaLab/tree/main/.agents/skills/kova-pr-maintainer
Command: npx skills add https://github.com/chiragborse1/KovaLab --skill kova-pr-maintainer

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It helps maintainers review Kova pull requests and issues with consistent evidence checks, safer GitHub actions, and correct labeling so low-signal or risky changes are not landed blindly.

Core Features & Use Cases

  • PR and issue triage workflow: Prioritize local gitcrawl thread data for clustering, duplicate attempts, and already-landed fixes before making GitHub decisions.
  • Correct label and auto-response handling: Apply the right r:* labels for issues and PRs and rely on the repo workflow for comment/close/lock behavior when appropriate.
  • Evidence-bar enforcement for bug fixes: Require repro/logs, verified root cause with code file/line, implicated code-path coverage, and regression testing or explicit justification.
  • Safe GitHub commenting and landing hygiene: Use newline-safe comment bodies (e.g., heredocs) and follow landing conventions like commit link inclusion and the global /landpr process.

Quick Start

Use the kova-pr-maintainer skill to triage PR #<number> and advise whether to label, request changes, or land based on evidence and repo workflow guidance.

Frequently Asked Questions about kova-pr-maintainer

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I triage GitHub pull requests with an evidence-first workflow?

To triage GitHub pull requests with an evidence-first workflow, prioritize local gitcrawl thread data to cluster duplicates and verify already-landed fixes before applying labels or making close decisions.

What is the best way to enforce evidence requirements for bug fix pull requests?

Enforcing evidence requirements for bug fix pull requests involves requiring reproducible logs, a verified root cause with specific code file and line numbers, implicated code-path coverage, and regression testing or explicit justification.

How do I apply r:* labels to GitHub issues and pull requests during triage?

Applying r:* labels to GitHub issues and pull requests requires matching the triage scenario to the correct label and relying on the repository workflow to manage comment, close, and lock behavior automatically.

Can I use local gitcrawl data to identify duplicate pull requests before checking GitHub?

Yes, you can use local gitcrawl data to identify duplicate pull requests and cluster similar attempts before checking GitHub, ensuring low-signal or risky changes are not landed blindly without proper verification.

How do I format GitHub comments safely when landing pull requests?

Formatting GitHub comments safely when landing pull requests requires using newline-safe comment bodies like heredocs, following landing conventions such as commit link inclusion, and utilizing the global /landpr process.

Why do I need guardrails to prevent speculative merges during pull request triage?

Guardrails are needed to prevent speculative merges during pull request triage because they enforce symptom and root-cause evidence verification, ensuring that risky code changes without proper evidence are not merged blindly.