standup-mr 0.1.2 → 0.2.0

package/mcp/README.md

@@ -1,6 +1,7 @@
 # MCP server
 
-Exposes one tool, `get_standup_data`, returning the same JSON as `standup fetch`.
+Exposes one tool, `get_standup_data`, for either GitLab or GitHub, returning
+the same JSON as `standup fetch`.
 
 ## Install
 
@@ -10,6 +11,8 @@ npm install standup-mr @modelcontextprotocol/sdk
 
 ## Configure
 
+GitLab:
+
 ```json
 {
   "mcpServers": {
@@ -25,9 +28,28 @@ npm install standup-mr @modelcontextprotocol/sdk
 }
 ```
 
-`GITLAB_HOST` and `GITLAB_TOKEN` are the supported configuration for MCP use. If
-`glab` happens to be installed and authenticated it is used as a fallback, but do
-not rely on that inside a container.
+GitHub:
+
+```json
+{
+  "mcpServers": {
+    "standup": {
+      "command": "node",
+      "args": ["/absolute/path/to/standup-mr/dist/mcp/server.js"],
+      "env": {
+        "GITHUB_HOST": "github.com",
+        "GITHUB_TOKEN": "ghp_..."
+      }
+    }
+  }
+}
+```
+
+`GITLAB_HOST`/`GITLAB_TOKEN` and `GITHUB_HOST`/`GITHUB_TOKEN` are the supported
+configuration for MCP use — set whichever pair matches the provider you want.
+If `glab` or `gh` happens to be installed and authenticated it is used as a
+fallback, but do not rely on that inside a container.
 
-The tool returns data only. Ask your client to write the note, or use the Claude
-Code skill in `skills/standup/`, which carries the note-writing rules.
+The tool returns data only. Ask your client to write the note, or install the
+Claude Code plugin (`/plugin install standup@standup-mr`), which carries the
+note-writing rules.

package/package.json

@@ -1,8 +1,8 @@
 {
     "name": "standup-mr",
-    "version": "0.1.2",
+    "version": "0.2.0",
     "description": "Standup notes from merge request state, not commit logs.",
-    "keywords": ["standup", "gitlab", "merge-request", "cli", "mcp"],
+    "keywords": ["standup", "gitlab", "github", "merge-request", "pull-request", "cli", "mcp"],
     "license": "MIT",
     "author": {
         "name": "İlker Balcılar",
@@ -31,10 +31,11 @@
     "bin": { "standup": "./dist/cli.js" },
     "main": "./dist/index.js",
     "types": "./dist/index.d.ts",
-    "files": ["dist", "skills", "mcp/README.md", "README.md", "LICENSE"],
+    "files": ["dist", "skills", "mcp/README.md", "README.md", "CHANGELOG.md", "LICENSE"],
     "scripts": {
         "build": "tsup",
         "test": "bun test",
+        "test:tz": "TZ=Europe/Istanbul bun test ./src/dates/dates.tz.istanbul.cases.ts && TZ=America/Los_Angeles bun test ./src/dates/dates.tz.los-angeles.cases.ts",
         "typecheck": "tsc --noEmit",
         "prepublishOnly": "tsup"
     },

package/skills/standup/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: standup
 description: >-
-  Generates a daily standup note from GitLab merge request state. Groups the
-  previous working day's activity into themes, reports which merge requests are
-  ready to merge or blocked, and diagnoses failed pipelines from their job logs.
-  Use for "/standup", "standup note", "what did I do yesterday", "what's on my
-  plate today", "daily note".
+  Generates a daily standup note from GitLab merge request or GitHub pull
+  request state. Groups the previous working day's activity into themes,
+  reports which merge requests are ready to merge or blocked, and diagnoses
+  failed pipelines from their job logs. Use for "/standup", "standup note",
+  "what did I do yesterday", "what's on my plate today", "daily note".
 ---
 
 # Standup Note
@@ -19,25 +19,41 @@ Not a commit log — what finished, what is waiting, what is stuck.
 npx standup-mr fetch
 ```
 
-Prints one JSON document. Add `--lang tr` for Turkish date labels. Nothing else
-needs running: the command resolves the host and token, works out which day to
-report on, and reads failed job logs itself.
+Prints one JSON document. The command picks GitLab or GitHub on its own — from
+flags, host, environment, or whichever of `gh`/`glab` is logged in. If the user
+already said which one they mean, pass it explicitly instead of guessing:
+
+```bash
+npx standup-mr fetch --provider github
+npx standup-mr fetch --provider gitlab
+```
+
+Add `--lang tr` for Turkish date labels. Nothing else needs running: the
+command resolves the host and token, works out which day to report on, and
+reads failed job logs itself.
 
 If the command exits non-zero, relay its stderr verbatim — do not invent a
-cause. The usual fix is `glab auth login`, or setting `GITLAB_HOST` and
-`GITLAB_TOKEN`.
+cause. The usual fix is `gh auth login` or `glab auth login`, depending on
+which provider it was trying to reach.
 
 ## 2. Shape of the JSON
 
 | Field | Contents |
 |---|---|
-| `previous` | Last active day: `date`, `label`, `gapDays`, `eventCount` |
-| `previousEvents` | That day's events — `action`, `project`, `branch`, `commits`, `commitTitle` |
+| `provider` | `gitlab` or `github` — decides the vocabulary, see below |
+| `previousDays` | Chronologically ascending list of active days since the last report. Each entry: `date`, `label`, `gapDays`, `events` |
 | `todayEvents` | Anything already done today (usually empty) |
-| `myMrs` | Open merge requests with `bucket`: `ready` / `blocked` / `draft` / `stale`, plus `pipelineMissing` |
+| `myMrs` | Open merge/pull requests with `bucket`: `ready` / `blocked` / `draft` / `stale`, plus `mergeStatus` and `pipelineMissing` |
 | `reviews` | Review requests, with `fresh` and `approvedByMe` |
 | `reviewPendingCount` | Reviews genuinely awaiting action |
-| `blockers` | Failed pipelines with real error lines from the job trace |
+| `blockers` | Failed CI runs with real error lines pulled from the job log |
+
+Each entry in `previousDays` carries its own `events` — `action`, `project`,
+`branch`, `commits`, `commitTitle`. **Every active day gets its own section in
+the note; never fold one day into another.** Running on a Monday typically
+means the list holds Friday plus any weekend day that had activity — one entry
+if the weekend was quiet, more if it was not — and each must be written up
+under its own `label`, never merged into a single "yesterday".
 
 ## 3. Write the note
 
@@ -46,11 +62,12 @@ user is speaking, phrased the way they would say it out loud.
 
 ### Previous day
 
-Use `previous.label`. Never say "yesterday" — after a weekend or a day off it is
-wrong, and the label already carries the right day.
+Write one section per entry in `previousDays`, in order, each headed by its own
+`label`. Never say "yesterday" — after a weekend or a day off it is wrong, and
+the label already carries the right day.
 
-**Group by theme; never list events one by one.** A 60-event day should collapse
-to four to six bullets. Group on project + branch + subject:
+**Group by theme within each day; never list events one by one.** A 60-event
+day should collapse to four to six bullets. Group on project + branch + subject:
 
 > **Virtual keyboard — two fixes, two releases** (`acme/ui` → main)
 > - keeps scaling on large screens, no longer widens modals → **0.5.13**
@@ -65,25 +82,55 @@ rollout — make it **one bullet** and say how many projects it touched.
 
 ### Today
 
-- **`ready`** → count them, give project + `!iid`.
+- **`ready`** → count them, give project + reference. The bucket name means
+  "nothing known is blocking it" — it is **not** a claim that the merge/pull
+  request is mergeable. Use `mergeStatus` to say which:
+  - `mergeable` → say it plainly, "ready to merge".
+  - `unchecked` (GitLab has not evaluated it yet) → say so explicitly, e.g.
+    "GitLab hasn't checked mergeability yet" — never round this up to "all
+    green".
+  - anything else (`conflict`, `need_rebase`, `discussions_not_resolved`,
+    GitHub's `dirty`/`blocked`/`behind`, …) → name that specific reason instead
+    of the generic bucket label.
+  - `null` (the field is `string | null`) → say **nothing** about mergeability.
+    The provider did not report it; do not guess a reason and do not round it
+    up to "ready to merge".
   - If `pipelineMissing` is true, say **"no pipeline ever ran"** explicitly. Do
     not let it pass as green.
-- **`blocked`** → say which: red pipeline, or unresolved comments, or both.
+- **`blocked`** → say which: red pipeline, unresolved comments, or both. On
+  GitHub the thing that blocks is a **change request**
+  (`CHANGES_REQUESTED`), not an unresolved comment thread — `unresolved` holds
+  the count of reviewers who requested changes.
 - **`draft`** → what needs finishing. Collapse drafts that share a branch prefix
   or scope into one line, and flag it when they must merge in order.
 - **`stale`** → a count and the oldest date. No long list.
 
-For reviews, use `reviewPendingCount`, not the raw length of `reviews` — GitLab
-keeps you on the reviewer list after you approve, so the raw number overstates
-the work. List the pending ones with author and `!iid`. If the user has both
-their own merge request and a review in the same project, note the conflict risk.
+For reviews, use `reviewPendingCount` on **both** providers, not the raw length
+of `reviews`. GitLab keeps you on the reviewer list after you approve, so its
+raw count overstates the work; GitHub drops you from the list once you approve,
+so `approvedByMe` is almost always `false` there — `reviewPendingCount` is the
+field that stays trustworthy either way. List the pending ones with author and
+reference. If the user has both their own merge/pull request and a review in
+the same project, note the conflict risk.
+
+### Vocabulary
+
+Match the platform's own words. When `provider` is `github`, say "pull
+request" and reference it as `#123`. When it is `gitlab`, say "merge request"
+and reference it as `!123`. The bucket names (`ready` / `blocked` / `draft` /
+`stale`) stay the same on both sides — only the noun and the reference prefix
+change.
 
 ### Blockers
 
 If `blockers` is empty, **omit the section entirely.** Never write "no blockers".
 
-Otherwise the useful content is the lines in `errors`, not the job name. Collapse
-several merge requests sharing one root cause into a single blocker.
+Otherwise the useful content is the lines in `errors`, not the job name — on
+GitLab those lines come from a failed pipeline job's trace, on GitHub from a
+failed Actions job's log or from a non-Actions check's summary. The rule does
+not change with the provider: what matters is what `errors` says, not which
+job produced it. Collapse several merge/pull requests sharing one root cause
+into a single blocker.
 
 > The CI token cannot pull the private packages — `npm ci` gets a 404. Two
 > pipelines are red for the same reason; the third passes because it has no such