Sync public skills from monorepo

plugins/windmill/skills/collect-feedback/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: collect-feedback
-description: Context and guidance for collecting user-initiated feedback about colleagues. Use when user wants to give feedback to a coworker.
+description: Context and guidance for collecting user-initiated feedback with selectable visibility. Use when the user wants to give feedback to a coworker.
 domain: feedback
 resourceFilename: collecting_user_initiated_feedback_skill.md
 ---
@@ -21,9 +21,9 @@ resourceFilename: collecting_user_initiated_feedback_skill.md
 ## Collection Workflow
 1. Identify targets via employees_query query; reject self; clarify ambiguous matches
 2. Collect feedback (see conversation rules below)
-3. Load current feedback settings and resolve any required visibility or shoutout choices
+3. Call feedback_requests_query with direction "incoming" and targetEmployee for the resolved target. Ask whether the feedback should answer a matching request. Use handling_requests_for_feedback_skill.md for more pages or multiple matches. Load current feedback settings and resolve required audience or shoutout choices
 4. Show the feedback and its audience, then ask for final confirmation
-5. Submit via feedback_create (supports multiple pieces of feedback and optional shoutout creation)
+5. Save with feedback_create. Include feedbackRequestId on the entry when the user agreed to answer a request
 6. Confirm success after all submissions are complete
 
 ## Conversation Rules
@@ -57,9 +57,18 @@ If the user explicitly asks you to "turn this into feedback", "clean it up", "re
 - Do not enter rewrite mode unless the user explicitly signals it
 
 ## Handling Visibility
-- Check the current visibility and shoutout state via feedback_settings_load
-- Note: Shoutouts will set visibility to PUBLIC regardless of default setting
-- Employee cannot control visibility directly
+- Load feedback_settings_load after collecting the feedback and before confirmation
+- If the user accepts an offer to help save feedback, start this visibility workflow. That acceptance is not a visibility choice or final confirmation
+- If the user already selected an allowed visibility, use that selection
+- If multiple options are allowed and the user did not select one, ask one short question that includes the labels, audience descriptions, and default
+- The default is a recommendation. Do not select it for the user when multiple options are allowed
+- If only one option is allowed, use it without asking the user to choose
+- A visibility choice is not confirmation to save
+- After the visibility is selected, show the feedback text and selected audience, then ask for final confirmation
+- Call feedback_create only after that final confirmation
+- Pass the selected visibility with each entry in feedback_create
+- If saving reports that an option is no longer available, reload settings and ask the user to select again
+- A shoutout makes its linked feedback PUBLIC. State this in the final confirmation
 
 ## Offering Shoutouts
 - The shoutouts system will share positive feedback to a pre-configured channel

plugins/windmill/skills/create-pulse/SKILL.md

@@ -49,7 +49,7 @@ The tool call also requires:
 The pulse is created in ACTIVE status. If no schedule fields are provided, it defaults to MANUAL.
 
 After creation, the user can:
-- Update configuration (via `pulse_update`)
+- Update name, prompt, participants, and other editable settings (via `pulse_update`)
 - Update schedule (via `pulse_update`)
 - Send it now (via `pulse_send_now`)
 
@@ -121,6 +121,8 @@ Pulses require Windmill membership. Set `windmillAccess: "HAS_ACCESS"` in the pa
 ### Step 4: Confirm other settings
 Confirm the other settings with the user.
 
+Confirm anonymity before calling `pulse_create`. It can still change with `pulse_update` before launch, but it is locked after launch.
+
 Response Anonymity Options:
 - Named (default):
   - Each response shows who said it
@@ -153,7 +155,7 @@ Call `pulse_create` with:
 - `prompt`: What they want to learn (required)
 - `discussionTopics`: Array of topics (required)
 - `participants`: Employee filter from Step 3 (required)
-- `anonymity`: NAMED, ANONYMOUS, or MANAGER_HIERARCHY (optional, defaults to NAMED if omitted/null)
+- `anonymity`: NAMED, ANONYMOUS, or MANAGER_HIERARCHY (required; null defaults to NAMED)
 - `durationMinutes`: Response duration in minutes, min 30 (optional, omit for no deadline)
 - `notificationDelayMinutes`: Minutes before first **reminder** to non-respondents (optional, defaults to 1440). Do NOT change this based on when the user wants to send the pulse; it only controls reminder timing.
 - `runUpdatesEnabled`: Whether creator gets updates from the agent throughout each run (required boolean)

plugins/windmill/skills/manage-1on1s/SKILL.md

@@ -33,7 +33,7 @@ the other employee, or the linked calendar event.
 
 Synthetic example:
 - Search returns `oneOnOneId: "01997b00-0000-7000-8000-000000000012"`,
-  `otherEmployee.employeeId: "cma7k9f2n0001lxr91cvdj8qy"`, and
+  `otherEmployee: "alex-rivera-j8qy"`, and
   `calendarEvent.calendarEventId: "01997b00-0000-7000-8000-000000000099"`.
 - Pass `"01997b00-0000-7000-8000-000000000012"` to one_on_ones_open as `oneOnOneId`.
 - Pass that same `oneOnOneId` to one_on_ones_agenda_mutate, copying the opened

plugins/windmill/skills/manage-notes/SKILL.md

@@ -34,13 +34,15 @@ Semantic search:
 Text search:
 - Use private_notes_query with `textQuery` for exact phrases or specific keywords
 - Best for finding specific words or names
+- A plain string matches only notes that contain it as written, so search one short phrase from the note. Use `full_text` mode for several keywords
 
 Employee filter:
 - Combine with semantic or text queries when user mentions a specific person
 - Use `employeeId` parameter after resolving employee via employees_query
 
 Fallback strategy:
 - If zero results with one search type, try the other
+- Do not tell the user that a note does not exist or did not save until a shorter phrase and `semanticQuery` also find nothing
 - Broaden filters if still no results
 - Ask user to clarify or try different keywords
 

plugins/windmill/skills/manage-pulse/SKILL.md

@@ -164,7 +164,7 @@ Members with the send-all capability may use any supported participant filter. O
 | Field | Purpose | Default |
 |-------|---------|---------|
 | `notificationDelayMinutes` | Delay before first **reminder** to non-respondents (does NOT control when the pulse is sent) | 1440 (1 day) |
-| `durationMinutes` | Response deadline window (min 30, null = no deadline) | null |
+| `pulse_deadline_update` | Change deadlines for existing runs or future defaults | Preview first |
 
 CRITICAL: When a user says "send now" or "send immediately", use `pulse_send_now`. Do NOT change `notificationDelayMinutes`; that controls reminder timing, not pulse delivery.
 
@@ -242,7 +242,7 @@ For pulse-level rollups (counts of completed runs, last run timestamp, etc.) use
 
 ## Product Rules
 
-- Cannot change anonymity after responses collected
+- Anonymity can change with `pulse_update` only before launch. It is locked after launch; if the user needs a different mode, explain that they must create a new pulse.
 - Schedule updates: pulse must not be COMPLETED or ARCHIVED
 - Send now: pulse must be ACTIVE
 - Cannot remove last owner with WRITE access

plugins/windmill/skills/respond-to-your-review/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: respond-to-your-review
+description: Participant workflow playbook for completing your own performance review: find open to-dos, load the full review context, and draft and submit answers. References the best-practices skill for writing guidance.
+domain: performance-reviews
+resourceFilename: performance-reviews_respond_to_your_review_skill.md
+---
+
+# Respond to Your Review
+
+Participant workflow for completing a performance review as a reviewee.
+
+## Relevant Resources
+- performance-reviews_system_context.md
+- performance-reviews_review_best_practices_skill.md: writing quality, evidence, fairness, tone, and the "help me think through my own review" relational guidance
+
+Tools with the `performance-reviews_admin_*` prefix require cycle-admin access. Use the participant tools below for your own work; enrollment and stage-assignment lookups are not required.
+
+## Step 1: Find What You Owe
+
+Call performance-reviews_my_todos_load to get the participant's open review tasks across all active cycles.
+
+- Returns assignments with their stage type (SELF, PEER, UPWARD) and submission state.
+- List them with links; no caveats needed at this stage.
+
+## Step 2: Load the Full Review Context
+
+Call performance-reviews_review_load for the specific assignment, with `include: ["employees", "questions", "own.drafts"]`.
+
+- Add `contextReport` for the review's context brief, if one has been generated (it may be empty early in the cycle).
+- For a peer review, add `nomination` for the nomination behind it.
+- Use the loaded context as the basis for drafting. Do not fill in answers from memory or assumption.
+
+## Step 3: Draft and Submit
+
+Call performance-reviews_review_answer to save draft answers or submit.
+
+- Saving a draft is reversible; submission is the meaningful commit.
+- Before submitting, preview the answers with the user and confirm intent.
+- Refer to performance-reviews_review_best_practices_skill.md for specificity, evidence, and tone guidance, especially the relational element when writing a self-assessment.
+
+## Key Constraints
+
+- A participant never sees the peer feedback or upward feedback written about them.
+- Self-review answers are visible to the participant's manager and cycle admins.
+- Submitting is not the same as sharing: a submitted manager review isn't accessible to the receiving employee until it is shared with them.

plugins/windmill/skills/review-best-practices/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: review-best-practices
+description: Standalone guidance for writing high-quality performance reviews: specificity, evidence-grounding, fairness/bias avoidance, tone, the relational coaching element, and when to defer to the human before taking outward-facing actions.
+domain: performance-reviews
+resourceFilename: performance-reviews_review_best_practices_skill.md
+---
+
+# Performance Review Best Practices
+
+## Specificity
+- Ground every claim in concrete behavior or output: what the person did, in what situation, with what result.
+- Avoid vague superlatives ("great communicator") without an example.
+- Reference specific projects, milestones, or incidents when you can.
+
+## Evidence
+- Use only evidence available through the review context loaded by the tool (self-review text, peer feedback, upward feedback, prior notes).
+- Do not invent examples or borrow details from other employees.
+- When evidence is thin, say so rather than overstating.
+
+## Fairness and Bias Avoidance
+- Apply the same evaluative bar across all reviewees. Do not adjust expectations based on tenure, background, or identity.
+- Watch for recency bias (weighting only the last few weeks) and halo/horn effects (letting one strong or weak signal dominate).
+- If peer or upward feedback conflicts, acknowledge the range rather than flattening it.
+
+## Tone
+- Developmental, not punitive: describe what happened and what better looks like.
+- Direct and honest: softening critical feedback to the point of obscuring it is not kindness.
+- Calibrate length to question importance; do not pad or truncate.
+
+## Relational Element
+- For managers writing about a report: frame feedback around how you will help them grow, not just what they did.
+- For participants completing their own self-review or peer feedback: an honest, grounded self-assessment or peer assessment is more useful to the person than flattery.
+- When helping someone think through their own review, ask clarifying questions to surface concrete examples before drafting.
+
+## When to Defer to the Human
+- Before submitting or triggering any outward-facing action (submit, share, release), preview what will happen and ask for confirmation.
+- If the user seems uncertain about what to write, offer to talk through the questions first rather than generating a draft immediately.
+- Submitted answers are not easily reversed; a submitted manager review isn't accessible to the receiving employee until it is shared with them, but submission itself is a meaningful commit. Confirm intent before calling the tool.
+- When in doubt about whether an action is reversible, surface the question rather than proceeding.

plugins/windmill/skills/write-manager-reviews/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: write-manager-reviews
+description: Core manager workflow for writing performance reviews: load the full review context (self/peer/upward feedback + per-question suggestions), draft and submit, locking and submission semantics, fairness guidance, and the manager↔report coaching element.
+domain: performance-reviews
+resourceFilename: performance-reviews_write_manager_reviews_skill.md
+---
+
+# Write Manager Reviews
+
+Core manager workflow for completing a manager review for a direct (or assigned) report.
+
+## Relevant Resources
+- performance-reviews_system_context.md
+- performance-reviews_review_best_practices_skill.md: specificity, evidence, fairness/bias avoidance, tone, and the manager↔report coaching element
+
+Tools with the `performance-reviews_admin_*` prefix require active WRITE ownership of the cycle. Manager access alone does not grant this permission. Use the review tools below for manager work.
+
+## Step 1: Gather Context
+
+Call performance-reviews_review_load for the manager review assignment, with `include: ["employees", "questions", "own.drafts", "contextReport", "observations"]`. It returns:
+- The configured manager-review questions and your drafts
+- A manager context report with per-question suggestions, when one has been generated for the review (it may be empty early in the cycle)
+- The review's observations
+
+Then call performance-reviews_reviews_search with the review's cycle, `reviewTypes: ["SELF", "PEER", "UPWARD"]`, the subject as `targetEmployeeIds`, and `include: ["questions", "answers"]`. It returns the subject's self review, peer feedback, and upward feedback that you may read.
+
+Use everything loaded here as the drafting foundation. Do not summarize or invent details not present in the loaded context.
+
+## Step 2: Draft and Submit
+
+Call performance-reviews_review_answer with `reviewType: MANAGER` to save drafts or submit.
+
+- Drafts are reversible; submission is the meaningful commit for the manager review.
+- Before submitting, preview all answers with the manager and confirm intent.
+- Submitted manager reviews aren't accessible to the receiving employee until the review is shared with them.
+
+## Fairness and Specificity
+
+- Evaluate the employee against the role and cycle criteria, not relative to peers in this session.
+- Peer and upward feedback are inputs, not the final word. The manager review is the manager's own assessment, informed by that feedback.
+- Where feedback is conflicting, acknowledge the range or explain which signal you weight more and why.
+- See performance-reviews_review_best_practices_skill.md for full guidance on evidence-grounding, bias avoidance, and tone.
+
+## Coaching Element
+
+Frame manager review answers developmentally: describe what the employee did well, where they can grow, and how you will support that growth. This is the manager's primary coaching artifact for the cycle; make it useful to the employee when it is eventually shared.
+
+## Locking and Submission Semantics
+
+- Submission and locking are separate: a submitted manager review remains editable until it is explicitly locked.
+- Submitting is a meaningful commit. You must get explicit user confirmation before calling the tool.