diff --git a/plugins/windmill/skills/collect-feedback/SKILL.md b/plugins/windmill/skills/collect-feedback/SKILL.md index aa1d9f6..0f119c5 100644 --- a/plugins/windmill/skills/collect-feedback/SKILL.md +++ b/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 diff --git a/plugins/windmill/skills/create-pulse/SKILL.md b/plugins/windmill/skills/create-pulse/SKILL.md index 94e961b..3d07e36 100644 --- a/plugins/windmill/skills/create-pulse/SKILL.md +++ b/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) diff --git a/plugins/windmill/skills/manage-1on1s/SKILL.md b/plugins/windmill/skills/manage-1on1s/SKILL.md index 75adbce..48079ba 100644 --- a/plugins/windmill/skills/manage-1on1s/SKILL.md +++ b/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 diff --git a/plugins/windmill/skills/manage-notes/SKILL.md b/plugins/windmill/skills/manage-notes/SKILL.md index 0b188b3..68e58bb 100644 --- a/plugins/windmill/skills/manage-notes/SKILL.md +++ b/plugins/windmill/skills/manage-notes/SKILL.md @@ -34,6 +34,7 @@ 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 @@ -41,6 +42,7 @@ Employee filter: 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 diff --git a/plugins/windmill/skills/manage-pulse/SKILL.md b/plugins/windmill/skills/manage-pulse/SKILL.md index 2e82f25..19c9008 100644 --- a/plugins/windmill/skills/manage-pulse/SKILL.md +++ b/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 diff --git a/plugins/windmill/skills/respond-to-your-review/SKILL.md b/plugins/windmill/skills/respond-to-your-review/SKILL.md new file mode 100644 index 0000000..eb27353 --- /dev/null +++ b/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. diff --git a/plugins/windmill/skills/review-best-practices/SKILL.md b/plugins/windmill/skills/review-best-practices/SKILL.md new file mode 100644 index 0000000..d1201e4 --- /dev/null +++ b/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. diff --git a/plugins/windmill/skills/write-manager-reviews/SKILL.md b/plugins/windmill/skills/write-manager-reviews/SKILL.md new file mode 100644 index 0000000..8e598f0 --- /dev/null +++ b/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.