@troylar/sightline 1.177.0 → 1.182.0

package/docs/assistant-workflow.md

@@ -309,6 +309,23 @@ and never shows on hover cards. Anyone who can open the plan, and your assistant
 advice, never authorization: it can't approve a change or lower the review level. Set it with the item's `.set`
 action, field `aiHint`.
 
+### An outcome's priority
+
+`outcome.set` {id, field: class, why or reconsider, value, prev} sets an outcome's priority: `class` is `rock`
+(committed), `pebble` (supports a commitment), `sand` (if there's room) or blank, and `why` (why it matters) and
+`reconsider` (when to reconsider it) are one line each, up to 300 characters. A change to any of them always waits
+for a person, at every review level: the team's priority and its reason are a person's call. A plan with a class or
+either line needs this version or later: older copies open it read-only.
+
+### The work order
+
+`initiative.order` {ids} sets the team's work order: every initiative id, in the order the team will take them, and
+`[]` clears it. The forecast follows it when people are busy: ordered work gets people first, a nested initiative
+takes its nearest listed holder's place, and unordered work follows in workstream order, then by start. What an item
+waits for still comes first, and Jira-dated initiatives keep their sprint, so they can't be in the order. It always
+waits for a person, at every review level. The export has `planning.workOrder` and each initiative's `workOrder`
+place, from 1. A plan with a work order needs this version or later: older copies open it read-only.
+
 ### Workstream actions
 
 `workstream.set` {id, field: note, color, from or until, value, prev} and `workstream.move` {id, index} change a

package/docs/bundled-skills.md

@@ -42,5 +42,5 @@ changes made after that build. To get newer skills, get the newer **sightline.ht
 compare or install its collection. There is no background download or automatic overwrite.
 
 A running assistant still needs access to the plan's [private context folder](assistant-workflow.md). Installing
-skills doesn't connect a model or change the in-app companion's protocol. See [the six planning workflows](skills.md)
+skills doesn't connect a model or change the in-app companion's protocol. See [the planning skills](skills.md)
 for ordinary-language requests you can start with.

package/docs/skills.md

@@ -1,7 +1,8 @@
 # Planning skills that start where your team is
 
-A skill is reusable instructions for an AI assistant. Sightline ships six: turn rough notes into a roadmap,
-make a precise edit, review the gaps, summarize the plan and teach the assistant your team's vocabulary.
+A skill is reusable instructions for an AI assistant. Start with **sightline-plan**, the one way in: paste
+notes, emails, bug reports, ideas, a leader's priorities or a question, and it works out where each piece
+belongs and prepares changes for you to review. It hands off to the specialist skills below when a job needs them.
 [Back to the tour](../README.md#documentation).
 
 ## Start with your normal conversation
@@ -17,7 +18,7 @@ node bin/sightline.js skills --to ../planning-skills
 This works without a public npm package. Builds 1.95.0 and later also offer
 [skill deployment from the HTML](bundled-skills.md); check [availability](availability.md) first.
 
-You do not need to learn six command names to have a useful planning conversation. Say what you need:
+You do not need to learn any skill names to have a useful planning conversation. Say what you need:
 
 > Read the current context in my private assistant folder. Organize these notes against existing work,
 > leave unknown owners unknown, and show the three decisions that matter most. Prepare only the changes I request.
@@ -30,6 +31,7 @@ Sightline tab writing its outputs. [Connect the folder and complete a session](a
 
 | Skill | Input | Result |
 | --- | --- | --- |
+| [sightline-plan](../skills/sightline-plan/SKILL.md) | Anything: notes, emails, bug reports, ideas, priorities, questions | Each piece sorted and answered; changes prepared for review; grooming agendas and Jira issue drafts in the reply |
 | [sightline-plan-roadmap](../skills/sightline-plan-roadmap/SKILL.md) | Goals, notes and an explicit horizon | Proposed outcomes, placement and timing; unknowns remain unknown |
 | [sightline-meeting-to-plan](../skills/sightline-meeting-to-plan/SKILL.md) | Notes you supply | Agreed changes, ideas and open decisions kept distinguishable |
 | [sightline-edit-plan](../skills/sightline-edit-plan/SKILL.md) | A targeted change | Small amendments with stable IDs and current-value preconditions |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@troylar/sightline",
-  "version": "1.177.0",
+  "version": "1.182.0",
   "description": "Your team's work, in plain sight. One HTML delivery planner, Jira context, and human-reviewed AI planning.",
   "license": "MIT",
   "keywords": [

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

@@ -24,6 +24,8 @@ Make the smallest coherent change that satisfies the request.
 - Check jiraLinked and datesFromTasks before proposing dates or status. Jira facts need a permitted Jira proposal; derived dates cannot be independently edited.
 - Keep logically dependent operations in one atomic change. Separate unrelated changes so the person can accept one without another.
 - For starts-after links, deletions, workstreams, people (role, allocation, workstream), milestones and what they're done after, gates, risks and decisions, holidays and time off, effort estimates (only numbers the person gives you) and what an initiative delivers, when people join and leave, how someone's time splits across workstreams, the support reserve, a workstream's note, color, dates and order (`workstream.set`, `workstream.move`; `workstream.del` only for an empty workstream, and it always waits for review; `workstream.reid {lane, id}` when a workstream's id no longer matches what it is, which also always waits for review: use the ids under `planning.workstreams`, and treat `was` as former ids, never as new ones), the skills catalog (`skill.add`, `skill.rename`, `skill.remove`, refused while a skill is in use), people's `skills` and work's `needs`, milestone stories, gate descriptions, meeting notes and `aiHint`, use the guide's action ops (`{op:"action", action, args}`) with the arguments listed under `actions`. Give every new item your own unique id, and put ops that depend on each other in one change, in order.
+- An outcome's priority (`class`: rock, pebble or sand; `why`; `reconsider`) is set with `outcome.set`, one line each, and always waits for a person at every review level. Change it only when the person asks.
+- The team's work order (`planning.workOrder`) is set with `initiative.order {ids}`: every initiative id, in order (`[]` clears it). Only when the person asks; it always waits for a person at every review level. Jira-dated initiatives aren't in it.
 - When the order of work is known but not its dates, add tasks with `after` (the tasks each starts after) and no `start`, and mark lengths you estimated with `rough: true`. To line up a task already in the plan, use `task.move` with `start: "after"`, never a delete and re-add: it keeps the task's ID and links. A task with `rough: false` in the context is set with `prev: false`.
 - For broad requests such as “move everything back,” show scope and affected IDs before generating changes. If something is in neither the guide's operations nor its actions, describe the manual UI path.
 

package/skills/sightline-plan/SKILL.md

@@ -0,0 +1,55 @@
+---
+name: sightline-plan
+description: The one way in to Sightline. Takes anything (notes, emails, bug reports, ideas, a leader's priorities, questions) and works out where each piece belongs, proposing changes for a person to review. Use it first; it hands off to the other Sightline skills.
+---
+
+## What this is
+
+People paste whatever they have: meeting notes, a forwarded email, a bug report, an idea, "the CIO wants SSO first", or a question like "can we take this on?". They should never have to know how Sightline is organized. You sort it out, answer what was asked, and prepare changes that a person reviews in Sightline. Nothing you write changes the plan by itself.
+
+Read the connected context first, exactly as `sightline-meeting-to-plan` describes (fresh context, matching plan ID and revision, coverage, what's omitted). When you write changes, follow its "Write proposals only when requested" rules. Pasting things in to be recorded counts as the request to prepare proposals; a question on its own doesn't.
+
+## Sort every piece
+
+Split the input into separate observations. Each one gets exactly one of these, and your reply says which:
+
+- **A question** about the plan: answer it (see "Answering questions"). Asking never changes the plan.
+- **Something heard** (a request, idea, complaint, bug, process gap): compare what's affected and what's wanted with the open and closed captures and the Jira items in the context, not just titles. Then propose one of: `outcome.raiseAgain` on the capture that clearly covers it; a new capture (`outcome.add` with `capture`); or, when unsure, a new capture and a note naming the capture it may repeat. One observation per capture, one line, with who raised it (a person or group already in the plan, or a role like "support", never an outside person's name or contact details), when, and where it came from. Never paste the email or transcript into the plan.
+- **A decision or a risk** that was agreed or raised: `decision.add` or `risk.add`.
+- **A priority someone stated** ("the VP wants Dashboard first"): record it as a request capture, with who said it, their role then, the date, and the reason, linked by name to the work it's about. Never change an outcome's class or the work order to match it. If the team might act on it, propose the change separately, as its own change, so a person can accept the request and decide the order on its own. Both always wait for review.
+- **A plan edit someone asked for**: follow `sightline-edit-plan`. Roadmap goals: `sightline-plan-roadmap`. Unsorted Jira work: `sightline-sort-jira`. Guidance for a workstream: `sightline-planning-guide`. A summary for an audience: `sightline-status`. A review for gaps and contradictions: `sightline-review-plan`.
+- **Not enough to act on** ("notifications are broken"): keep it separate and ask the one question that would change what happens next. Don't guess, and don't merge it with something that only sounds similar.
+
+A forwarded copy of a report is not another report. The same email pasted twice is one report. When you can't tell whether two reports come from different people, say "two mentions", not "two people".
+
+## The reply
+
+Lead with what you understood, then what you prepared, then what needs a person:
+
+> Seven topics. Four connect to work you already have; three are new.
+> **CSV exports**: one more report from support on the existing request (ABC-42). The forwarded copy isn't counted twice.
+> **SSO and Dashboard**: the CIO asked for SSO first; a Dashboard date was promised to sales. I recorded both; the order is unchanged and waits for your decision.
+> **"Notifications are broken"**: kept aside. Customer notifications or release alerts?
+> Ready to review in Sightline. Nothing has been applied.
+
+Use the team's words, not Sightline's internal ones: say "request", "work order", "what matters most", not field or action names. Give no confidence percentages; give the reason a match is uncertain.
+
+## Answering questions
+
+Answer from the context only, and say what it doesn't cover.
+
+- **What should I work on?** Go by the team's work order, then each outcome's class (rock = committed, pebble = supports a commitment, sand = if there's room) and its "why it matters". Name the next ready item for that person and what it serves. If the order is empty, say so instead of inventing one.
+- **Can we take this on? / How are we against capacity?** Use Sightline's forecast and capacity figures, never your own schedule. Missing effort means "can't tell yet: it has no estimate", and name what estimate would answer it. Say what would wait.
+- **Why is X above Y?** Quote the recorded reasons, who set them and when. If there's no recorded reason, say so.
+
+## Prep our grooming
+
+Return a short agenda that starts with decisions, not a tour of the backlog: at most five topics (fewer is fine), each with why it's on the agenda, the evidence, and the result to aim for, with minutes that fit the meeting's length (assume 30 minutes when unknown). Typical topics: a stated priority that conflicts with the work order or a promise; work near the top of the order with no estimate; requests that need one clarifying question; items that need a tracker check. End with how many other new requests stay outside today's agenda. Preparing an agenda changes nothing in the plan.
+
+## Does it need a Jira issue?
+
+Work near the top of the order with no Jira link needs a tracker check, not automatically a new issue: say whether it has linked Jira work, may belong in an existing issue, or has no known link. When an issue is needed, put a draft in your reply only (summary, problem, expected and actual behavior, steps to reproduce, acceptance criteria, evidence, open questions), citing the Sightline item. Never invent requirements: missing ones are open questions. Tell the person to search Jira once more before filing. Sightline never creates issues. After filing, the person adds the key to the item.
+
+## No file access
+
+If you can't read or write files, work from what the person pasted from Sightline's "Copy for my assistant". Say which items it included and ask for "more about X" when a match depends on something missing. Return the proposals as one JSON block in the same version 1 envelope, so the person can choose "Paste proposed changes" in Sightline. Sightline checks it again before anything is applied.

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

@@ -21,6 +21,8 @@ Translate the requested goals into outcomes the team can discuss.
 - Match existing outcomes by stable ID before proposing additions. Prefer an outcome describing a user or business result, with brief customer wording; distinguish a result from the tasks needed to achieve it.
 - Use the saved projectGuide and actual workstream IDs to suggest placement. Explain uncertain placements. Leave owners and timing unknown when the user has not supplied them; an idea can stay at idea stage without a date.
 - Preserve outcomes outside the requested window and call out any relevant ones. Calendar targets express planning intent; they do not establish team capacity or a delivery commitment.
+- An outcome's priority is the team's call. Propose a class (`rock` committed, `pebble` supports a commitment, `sand` if there's room) only when the person asks, always with a one-line `why`, through `outcome.set`; it always waits for a person. A class is importance, not size.
+- When the person asks for a work order, propose `initiative.order` with committed work first, and say why; it always waits for a person.
 - Propose only the changes the person requested. Put optional extra work in a separate suggestion, not in the proposal batch.
 
 Report the proposed quarter-by-quarter outcomes, material tradeoffs and the one missing decision that matters most. If a requested operation is absent from the current context guide, explain the UI step instead of inventing an operation.

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

@@ -25,6 +25,8 @@ Review the requested scope, or the next four explicit calendar quarters when no
 - Missing or ambiguous owner, target or workstream information. Distinguish unknown from deliberately unassigned.
 - Unsupported timing or progress claims, especially Jira-derived status or dates. State snapshot freshness and omitted Jira coverage.
 - Dependencies, risks, capacity and decisions only where the supplied evidence supports them. The assistant view omits notes and may omit parts of the plan or Jira; do not claim to have reviewed missing data.
+- Priority gaps: a rock (`class: "rock"`) with no target, release or date recorded, or a class with no `why`. Point them out; never reclassify an outcome, since its class is the team's call.
+- Work order gaps: an initiative that delivers a rock but isn't in `planning.workOrder`, or sits after initiatives that only deliver sand. Point them out; never reorder, since the order is the team's call.
 - Relevant work outside the requested quarters. Do not recommend deleting it simply because the view excludes it.
 
 Lead with up to three material findings, naming stable IDs and the evidence behind each. End with focused next decisions. If no material issue is supported, say so and state the coverage limits. Offer proposed edits only if the person subsequently asks.