@troylar/sightline 1.120.2 → 1.171.0

package/skills/sightline-meeting-to-plan/SKILL.md

@@ -20,14 +20,17 @@ Use the notes supplied by the person; do not claim to record or transcribe a mee
 - Separate agreed changes, ideas, open questions and informational updates. Use explicit wording from the notes to distinguish a decision from a suggestion.
 - Match named work to existing stable IDs. Ask when two items plausibly match. Keep duplicate mentions as one item.
 - Draft amendments for agreed plan changes only. Capture requested vague ideas as unscheduled idea-stage outcomes. Do not turn an idea into a scheduled initiative or task with invented dates or owners.
+- Capture each request, idea, process gap or open question raised in the meeting with `outcome.add` and its `capture` type, `raised` (the meeting's date), `source` (the meeting) and `askedBy` (a person or group from `planning.people` or `planning.groups`, by ID). Set `lane` only when the workstream is clear; otherwise leave it out so it lands under Unassigned. A team that isn't in the plan yet needs `group.add` in the same change, and that change always waits for review. Keep a capture to the request in one line; never paste the transcript.
+- Before capturing, compare each request with the captures already in the plan (open or closed: their names and `raisedAgain`). When one clearly covers it, record it there with `outcome.raiseAgain` (`id` of that capture, your own unique `ask` id, and `who`, `raised`, `source` for this meeting) instead of adding a second capture. When you're unsure, capture it separately and say in your report which capture it may repeat. Never merge or delete captures.
 - Preserve uncertainty and explain suggested workstream placement using projectGuide. A person being mentioned in the meeting does not establish ownership.
+- When the meeting agreed an order of work but not dates, add tasks with `after` (the tasks each starts after) instead of a date, and `rough: true` for lengths you estimated. Never invent a start to fill the gap.
 - Record agreed decisions, risks, starts-after links, owners and milestones with the guide's action ops (`{op:"action", action, args}`, listed under `actions`): `decision.add`/`decision.set`, `risk.add`/`risk.set`, `link.add`/`link.remove`, `milestone.add`, `person.setAlloc`, and days off agreed in the meeting with `holiday.add`/`holiday.addRange` (everyone) or `person.timeOff.add` (one person). Give each new item your own unique id. Planning-guide edits have no operation: give a concise copy-ready draft with the UI destination, separate from the amendments.
 
-Report: agreed changes proposed; ideas captured; open decisions; unsupported items for manual entry. Keep the output brief enough to review during the meeting.
+Report: agreed changes proposed; requests, ideas, gaps and questions captured, with who asked, and the ones recorded as raised again; open decisions; unsupported items for manual entry. Keep the output brief enough to review during the meeting.
 
 ## Write proposals only when requested
 
-Use only the operations and fields in the fresh context's `guide`, current choices and stable target IDs. Use its version 1 envelope, current plan ID, fresh batch ID, creation timestamp and `basedOn.planRevision`. Keep change IDs stable when revising the same proposal. Keep operations that depend on one another in the same change; unrelated changes must remain independently reviewable. Each change must apply entirely or leave the plan unchanged; include exact current `prev` values. Never invent a new operation or a Jira edit.
+Use only the operations and fields in the fresh context's `guide`, current choices and stable target IDs. Choose each action by its one-line `desc` in `actions`, and use its `args` exactly. Use its version 1 envelope, current plan ID, fresh batch ID, creation timestamp and `basedOn.planRevision`. Keep change IDs stable when revising the same proposal. Keep operations that depend on one another in the same change; unrelated changes must remain independently reviewable. Each change must apply entirely or leave the plan unchanged; include exact current `prev` values. Never invent a new operation or a Jira edit.
 
 Only the assistant-owned `sightline-amendments.json` may be replaced. Serialize the complete JSON, check it fits within 512 KiB in UTF-8, with at most 100 changes and 25 operations per change, write a sibling temporary file, parse it, then atomically replace the destination where the writer supports it. If atomic replacement is unavailable, provide the complete file for deliberate manual connection; do not use a truncating write over the live file. Never overwrite context, results, chat mailboxes, the shared plan or Jira output.
 

package/skills/sightline-plan-roadmap/SKILL.md

@@ -27,7 +27,7 @@ Report the proposed quarter-by-quarter outcomes, material tradeoffs and the one
 
 ## Write proposals only when requested
 
-Use only the operations and fields in the fresh context's `guide`, current choices and stable target IDs. Use its version 1 envelope, current plan ID, fresh batch ID, creation timestamp and `basedOn.planRevision`. Keep change IDs stable when revising the same proposal. Keep operations that depend on one another in the same change; unrelated changes must remain independently reviewable. Each change must apply entirely or leave the plan unchanged; include exact current `prev` values. Never invent a new operation or a Jira edit.
+Use only the operations and fields in the fresh context's `guide`, current choices and stable target IDs. Choose each action by its one-line `desc` in `actions`, and use its `args` exactly. Use its version 1 envelope, current plan ID, fresh batch ID, creation timestamp and `basedOn.planRevision`. Keep change IDs stable when revising the same proposal. Keep operations that depend on one another in the same change; unrelated changes must remain independently reviewable. Each change must apply entirely or leave the plan unchanged; include exact current `prev` values. Never invent a new operation or a Jira edit.
 
 Only the assistant-owned `sightline-amendments.json` may be replaced. Serialize the complete JSON, check it fits within 512 KiB in UTF-8, with at most 100 changes and 25 operations per change, write a sibling temporary file, parse it, then atomically replace the destination where the writer supports it. If atomic replacement is unavailable, provide the complete file for deliberate manual connection; do not use a truncating write over the live file. Never overwrite context, results, chat mailboxes, the shared plan or Jira output.
 

package/skills/sightline-sort-jira/SKILL.md

@@ -24,7 +24,8 @@ Read `sightline-assistant-view.json` afresh from the private assistant folder th
    - `jira.toWorkstream {keys:[key], lane}`: its own initiative in that workstream.
    - `jira.toInitiative {keys:[key], id}`: a task on an existing initiative from `jiraSort.targets.initiatives`, when the summary clearly belongs to that initiative.
    - `jira.notOurs {keys:[key]}`: only when the issue is clearly another team's work. It hides the issue from Sort Jira work, and a person can bring it back.
-3. To place a whole epic, use `jira.epicLink {epic, id}` (onto an existing initiative) or `jira.epicNew {epic, lane}` (a new initiative for it).
+   - Don't use `jira.hide` to sort: it's for work the team already decided to keep off the plan's views, and it needs a reason a person gave.
+3. To place a whole epic, use `jira.epicLink {epic, id}` (onto an existing initiative) or `jira.epicNew {epic, lane}` (a new initiative for it). Once an epic is linked, Jira owns that initiative's status and dates, even later in the same change: don't set them there. If they look wrong, propose the change in Jira instead. An epic counts on one initiative: `jira.epicLink` refuses an epic another initiative holds (the reason names it) and a 51st epic, and moves an epic that's parked elsewhere.
 4. Give every change a `reason`, one plain line about why it belongs there (the workstream's guidance, the epic, the initiative it extends), and a `confidence` of `high` or `low`. Say `low` when you are going on the assignee alone.
 5. When you can't justify a placement, don't guess. Put the issue in your own report under **Couldn't place**, with the one question you'd need answered (for example, "Who owns cleanup work with no epic?"). It is not a change.