@reneturcios/greenlight 0.6.0 → 0.8.0

package/integrations/copilot/copilot-instructions.snippet.md

@@ -9,7 +9,8 @@ it does not exist).
 
 You have the Greenlight MCP server connected (server `greenlight`, tools:
 check_issue, scan_repo, repo_friction, claim_issue, prep_issue, open_pr,
-ci_triage, review_triage, guard_pr, repo_digest, claim_status, preflight).
+ci_triage, review_triage, guard_pr, repo_digest, claim_status, preflight,
+verify_comment, babysit_prs, evidence_pack).
 Apply these instructions whenever working on a
 pull request to an open source project:
 
@@ -17,14 +18,23 @@ pull request to an open source project:
    issue URL. If the verdict is TAKEN or GATED, stop and tell the user why,
    quoting the reasons. Never start work on a TAKEN or GATED issue without
    being told to.
-2. Before claiming or setting up work, call `prep_issue` (dry run) to learn
-   the repo's exact CLA path, house rules, and changeset convention. Report
-   the plan; do not create forks or branches unasked.
-3. If the PR's CI goes red, call `ci_triage` before changing code, and tell
+2. Before claiming an issue, run it through `preflight` (or
+   `claim_status`): who holds the issue, until when, who is queued. Join
+   the queue instead of duplicating held work. Then call `prep_issue` (dry
+   run) to learn the repo's exact CLA path, house rules, and changeset
+   convention. Report the plan; do not create forks or branches unasked.
+3. If the repo takes no outside PRs (the check says the contribution is a
+   verified comment): draft with `verify_comment` from your notes. Do not
+   open a PR there.
+4. If the PR's CI goes red, call `ci_triage` before changing code, and tell
    the user whether each failure is pre-existing, likely theirs,
    indeterminate, or an external blocker.
-4. After review comments arrive, call `review_triage`. Fix likely-real
+5. After review comments arrive, call `review_triage`. Fix likely-real
    findings first; bring needs-decision items to the user; push back on
    likely-noise only with the tool's evidence. Drafts are output only.
-5. Never post claim comments, open PRs, or write anything to GitHub without
+6. When the user asks for proof a PR is sound, assemble `evidence_pack`
+   and present it.
+7. To check on the user's open PRs, call `babysit_prs` and lead with the
+   needs-you-now items.
+8. Never post claim comments, open PRs, or write anything to GitHub without
    the user's explicit go-ahead.

package/integrations/cursor/greenlight.mdc

@@ -7,7 +7,8 @@ alwaysApply: false
 
 You have the Greenlight MCP server connected (server `greenlight`, tools:
 check_issue, scan_repo, repo_friction, claim_issue, prep_issue, open_pr,
-ci_triage, review_triage, guard_pr, repo_digest, claim_status, preflight).
+ci_triage, review_triage, guard_pr, repo_digest, claim_status, preflight,
+verify_comment, babysit_prs, evidence_pack).
 Apply these rules whenever the user is working on
 a pull request to an open source project:
 
@@ -15,14 +16,23 @@ a pull request to an open source project:
    issue URL. If the verdict is TAKEN or GATED, stop and tell the user why,
    quoting the reasons. Never start work on a TAKEN or GATED issue without
    being told to.
-2. Before claiming or setting up work, call `prep_issue` (dry run) to learn
-   the repo's exact CLA path, house rules, and changeset convention. Report
-   the plan; do not create forks or branches unasked.
-3. If the PR's CI goes red, call `ci_triage` before changing code, and tell
+2. Before claiming an issue, run it through `preflight` (or
+   `claim_status`): who holds the issue, until when, who is queued. Join
+   the queue instead of duplicating held work. Then call `prep_issue` (dry
+   run) to learn the repo's exact CLA path, house rules, and changeset
+   convention. Report the plan; do not create forks or branches unasked.
+3. If the repo takes no outside PRs (the check says the contribution is a
+   verified comment): draft with `verify_comment` from your notes. Do not
+   open a PR there.
+4. If the PR's CI goes red, call `ci_triage` before changing code, and tell
    the user whether each failure is pre-existing, likely theirs,
    indeterminate, or an external blocker.
-4. After review comments arrive, call `review_triage`. Fix likely-real
+5. After review comments arrive, call `review_triage`. Fix likely-real
    findings first; bring needs-decision items to the user; push back on
    likely-noise only with the tool's evidence. Drafts are output only.
-5. Never post claim comments, open PRs, or write anything to GitHub without
+6. When the user asks for proof a PR is sound, assemble `evidence_pack`
+   and present it.
+7. To check on the user's open PRs, call `babysit_prs` and lead with the
+   needs-you-now items.
+8. Never post claim comments, open PRs, or write anything to GitHub without
    the user's explicit go-ahead.

package/integrations/windsurf/README.md

@@ -6,7 +6,7 @@ Windsurf's global MCP config lives at:
 
 Copy the `mcp_config.json` file in this folder there (merging with any
 servers you already have), then restart Windsurf and check its MCP panel:
-the `greenlight` server should list 12 tools. Newer Windsurf versions also
+the `greenlight` server should list 15 tools. Newer Windsurf versions also
 accept a project-level `.windsurf/mcp.json` file using the same
 `mcpServers` format.
 

package/package.json

@@ -25,7 +25,7 @@
     "test": "tsx --test test/*.test.ts"
   },
   "type": "module",
-  "version": "0.6.0",
+  "version": "0.8.0",
   "mcpName": "io.github.CloudCorpRecords/greenlight",
   "publishConfig": {
     "access": "public"

package/server.json

@@ -6,13 +6,13 @@
     "url": "https://github.com/CloudCorpRecords/greenlight",
     "source": "github"
   },
-  "version": "0.6.0",
+  "version": "0.8.0",
   "packages": [
     {
       "registryType": "npm",
       "registryBaseUrl": "https://registry.npmjs.org",
       "identifier": "@reneturcios/greenlight",
-      "version": "0.6.0",
+      "version": "0.8.0",
       "runtimeHint": "npx",
       "packageArguments": [
         {