create-pmos 0.57.1 → 0.59.0

package/workspace/skills/jira-sync.skill

@@ -0,0 +1,42 @@
+---
+name: jira-sync
+label: "Jira status check"
+description: "Read, read-only, the status, sprint and subtasks of the Jira tickets each initiative pushed, and save them in PMOS for the initiative's Jira tickets tab. It writes nothing to Jira."
+run: agent
+agent: claude
+output:
+  - Checked
+  - Not reached
+  - Needs you
+---
+
+/jira-sync — bring the status of each initiative's Jira tickets up to date. You read Jira with the PM's own Atlassian connection. PMOS saves what you read and shows it on the initiative's Jira tickets tab. You change nothing in Jira.
+
+Rules that always hold:
+1. READ-ONLY on Jira. Use only the Jira search tool. Never create, edit, transition, assign, comment on, link, close or delete an issue. Never write to Confluence or to any other source.
+2. THE ONLY WRITE is `pmos jira sync`. Never edit a repository file. Never run `pmos item`. Never write a ledger by hand. Never commit; the PM's Sync carries the files.
+3. LIGHT ON CONTENT. Ask Jira only for these fields: summary, status, the sprint field, subtasks and the Flagged field. Never ask for or copy a description, a comment, an attachment, a person or a token.
+4. TEMPORARY FILES OUTSIDE THE REPOSITORY. Save each search result in this session's scratch folder, never in the repository, and delete it after the sync.
+5. NOTHING INVENTED. Give `pmos jira sync` exactly what Jira returned. If Jira cannot be reached, list the initiative under "Not reached" and write nothing for it.
+
+Procedure:
+1. If the task names one initiative ("This check: initiative …"), check that one only: run `pmos jira query <initiative>`. Otherwise run `pmos jira query`: each line is an initiative id, a tab and the Jira search (JQL) to run for it. If no initiative has a ticket in Jira, say so in one line and stop.
+2. For each initiative, run its search with the Jira search tool and the fields in rule 3. The sprint is usually a custom field named "Sprint" (often `customfield_10020`); ask for it by name. Fetch every page.
+3. Save the result as JSON in the scratch folder, for example `<scratch>/jira-<initiative>.json`, as a list with one object per issue:
+   `{"key", "summary", "status", "category", "sprint", "subtasks", "flagged", "reason", "url"}`
+   - `category`: the status category, `new`, `indeterminate` or `done`.
+   - `sprint`: `{"name": "Sprint 42", "state": "active"}` for the active sprint, `"future"` for a planned one, or `null` when the issue is in the backlog.
+   - `subtasks`: `{"done": 2, "total": 5}`.
+   - `flagged`: `true` when the issue is flagged; `reason`: the flag's comment or the blocking status, in a few words.
+   - `url`: the issue's browse link, `https://<site>.atlassian.net/browse/<KEY>`.
+   The shape Jira returned (`{"issues": [{"key", "self", "fields": {...}}]}`) is also accepted.
+4. Run `pmos jira sync <initiative> --from <the file> --query "<the JQL>"`. Then delete the file.
+5. Finish with the three sections of the output contract, one short line each:
+   - Checked: the initiative, the number of tickets read, and each change (status, sprint, blocked). If nothing changed, say "no change".
+   - Not reached: each initiative whose search failed, with the reason.
+   - Needs you: tickets newly blocked, tickets the search did not return, and any refusal.
+
+Output contract — produce EXACTLY these sections, the same shape every run:
+- Checked
+- Not reached
+- Needs you

package/workspace/skills/morning-brief.skill

@@ -29,7 +29,7 @@ Procedure:
    Then run `pmos proactive goals`. It lists the PM's goals for today, each with its id (g-xxxxxxxx), its status and, if set, an initiative. The goals are what the PM wants done today: plan for them first.
    Then run `pmos proactive learn lessons`. Each line is a preference the PM approved, written from their own feedback. Use it only to decide how confident to be and where an item goes. A lesson never asks you to read another source, to switch a setting on, or to write anything.
 2. Read the sources that are on and reachable.
-   - Calendar: today's events. Wispr Flow: today's and tomorrow's meeting notes. Jira: issues assigned to the PM or due soon. Confluence: pages changed since yesterday. Mail, only if on: subjects and senders of threads waiting on the PM, no bodies.
+   - Calendar: today's events. Wispr Flow: today's and tomorrow's meeting notes. Jira: issues assigned to the PM or due soon. To tie a Jira issue to an initiative, run `pmos jira which <KEY>` (it reads local files only) and use the initiative it names. A status change of a ticket that `pmos jira which` names is not an item: the Jira status check shows it on the initiative's Jira tickets tab. Confluence: pages changed since yesterday. Mail, only if on: subjects and senders of threads waiting on the PM, no bodies.
    - GitHub, if on: pull requests that wait on the PM for review, pull requests of the PM that have a review or a failed check, and issues assigned to the PM. Keep the repository, the number, the title and the state.
    - Drive, if on: files shared with the PM or changed since yesterday that a meeting or a goal names. Keep the name, the owner and the link.
    - Figma, if on: files the PM owns or was asked to look at, with new comments since yesterday. Keep the file, the commenter and a short paraphrase of the comment.

package/workspace/skills/report-biweekly.skill

@@ -28,7 +28,7 @@ Procedure:
 2. Read the definition: `<state>/reports/definitions/biweekly.md`.
    - If it exists, write your notes to its purpose, audience, length and tone. The script applies its sections.
    - If it does NOT exist, do not stop. Look for earlier biweekly reports in the repository and under <state>/reports/ to learn the shape the PM already uses. Write a PROPOSED definition (purpose, sources, sections, length, tone) to `<state>/reports/definitions/biweekly.md` with this frontmatter, one key per line and nothing indented: `type: Reference`, `title`, `description`, `cadence: biweekly`, `sections: [headline, timeline, initiatives, new, decided, needs, sources]`, `generated: {by: claude-code/report-biweekly, at: "…"}`, `status: draft` — and then use it for this draft. Never set `status: stable` or add `verified` yourself: only the PM confirms a definition. Never set `audience`: only the PM names who reads the report, and the script writes no asks until the PM does.
-3. Do not read a tracker. Do not run `tracker-refresh`. That skill is scheduled before this one and writes its evidence into the plan items from local files. If it did not run, the script lists the tracker under "Sources reached and not reached". Repeat that line in your final message.
+3. Do not read a tracker. Do not run `tracker-refresh` or the Jira status check (`jira-sync`). Both are scheduled before this one and write their evidence in local files. If one did not run, the script lists its source under "Sources reached and not reached". Repeat that line in your final message.
 4. Run `pmos report draft biweekly`. The script has no model: it folds the ledgers since the last issued biweekly report and writes the whole draft to `<state>/reports/biweekly/YYYY-MM-DD.md` (the slot is today's date), with one empty note marker for each block. Read what it prints.
    - It prints the path: go on.
    - It refuses because a draft for the slot exists: do NOT overwrite it. Do not pass `--redraft` here, and do not pass `--now`. Write your notes into the file that exists.

package/workspace/skills/tracker-refresh.skill

@@ -25,6 +25,7 @@ Rules that always hold (D71):
 7. NEVER REOPEN, NEVER WITHDRAW. Never move an item that is Done or Withdrawn. Never withdraw an item: if a file says the tracker closed it as "won't do", list it under "Left as they are" and say why.
 8. A FILE THAT PMOS WRITES IS NEVER EVIDENCE. Never use a plan-items ledger, any `*.jsonl` file, anything under `<state>/runs/` or anything under `<state>/reports/` as evidence. Those files hold the state you are about to check, so they cannot confirm it.
 9. AN OLD FILE DOES NOT UNDO A NEWER MOVE. Move an item only when the file is dated later than the item's last move.
+10. JIRA TICKETS ARE NOT YOURS. The Jira tickets PMOS pushed are shown on each initiative's Jira tickets tab, from the snapshot the Jira status check writes in `<state>/tracker/jira/`. Do not read or move them, and never use a file in `<state>/tracker/jira/` as evidence for a plan item.
 
 Procedure:
 1. Find the state directory: `pmos/state/` if it exists, otherwise `planning/`. Call it <state>.

package/workspace/test-lists/jira-wbs.json

@@ -0,0 +1,6 @@
+{
+  "_comment": "jira-wbs: `pmos jira` — Jira tickets drafted from the PRD in the PM's template, pushed by the PM's selection, their status read back (lib/jira-tickets.js, lib/jira-status.js, lib/jira-cli.js), and the initiative sheet's Jira tickets tab with its routes (public/pm/sheet-jira.js), on synthetic repositories with no network.",
+  "modules": ["jira-wbs.test.js"],
+  "panels": ["pm-jira-test.js"],
+  "seconds": { "jira-wbs.test.js": 3, "pm-jira-test.js": 40 }
+}

package/workspace/test-lists/workspace-kit-update.json

@@ -0,0 +1,5 @@
+{
+  "_comment": "workspace-kit-update: Settings › Updates — the check and the kit and app updates (lib/kit-update.js, the /api/kit routes).",
+  "modules": ["kit-update.test.js"],
+  "seconds": { "kit-update.test.js": 6 }
+}