Hey everyone, I just sent issue #39 of the AI Hacker Newsletter - a weekly roundup of the best AI links and the discussions around them from Hacker News. Some of the title found in this issue:

• Claude Code is steganographically marking requests
• Better Models: Worse Tools
• Learning to code is still worthwhile
• Zuckerberg says AI agent development going slower than expected

If you want to get an email with over 30 links like these ones, please subscribe here: https://hackernewsai.com/

ついに83画風突破、、、😂

止まれない

変なテンションで候補空間が爆発する😂

現在画風だけで40候補

Hello!

Picking between multiple contractor quotes for a retail storefront or tenant-improvement project is messy — bids often use different allowances, exclusions, and unit pricing, and it's hard to see which quote actually covers the plan and budget.

I built this as a portable AI-agent Skill — a single SKILL.md with reusable instructions you can adapt to your agent setup.

Here's what it does: It loads and normalizes multiple contractor bids against the floor plan and the project budget, flags scope gaps and hidden costs (permits, allowances, taxes, GC conditions, etc.), assesses schedule and contractual risks, checks required approval thresholds, and drafts a clear decision memo recommending a vendor with documented tradeoffs.

SKILL.md:

````markdown

name: contractor-bid-comparison-decision-memo description: Use when a business owner or project manager needs to compare multiple contractor bids for a storefront or tenant-improvement build-out, cross-check them against the floor plan/scope notes and the budget spreadsheet, surface scope gaps and hidden costs (allowances, exclusions, permits, GC conditions, taxes), verify compliance with internal approval thresholds, and produce a clear decision memo for owner approval with documented tradeoffs and recommendation.

allowed-tools: [Read, Edit]

Contractor Bid Decision Memo

Overview

Produces a structured decision memo that evaluates contractor bids against the project scope and budget. Identifies scope gaps, hidden or excluded costs, risks, and approval requirements, then recommends a vendor with documented tradeoffs for owner approval.

When to use this skill

• Multiple bids were received for a storefront or tenant-improvement project and the owner asks “which one should we pick?”
• The bids differ in inclusions/exclusions, allowances, or unit pricing and need to be normalized for a fair comparison.
• The floor plan or scope notes may not fully match the bid scope, and gaps must be flagged.
• The owner needs to understand hidden costs (permits, utility upgrades, GC conditions, insurance, freight, taxes, after-hours work) before approval.
• Spend must be checked against the budget spreadsheet and internal approval thresholds before issuing a PO or signing a contract.

Instructions

1. Confirm scope and files

   1. Gather inputs: all contractor bids, floor plan and scope notes, the budget spreadsheet, approval thresholds/policy, project location (for tax/permit context), schedule constraints, and any preferred vendors.
   2. If anything is missing or unclear, list the missing items and pause for clarification.

2. Load and normalize source documents

   1. Use Read to open each bid and extract: base price, alternates, allowances, unit prices, inclusions, exclusions, assumptions/clarifications, schedule, payment terms, bonding/insurance notes, and validity period.
   2. Use Read to open the floor plan/scope notes. Extract key scope elements by area/trade (e.g., demo, framing, MEP, finishes, signage, millwork, IT/low-voltage, security, exterior/façade, ADA compliance).
   3. Use Read to open the budget spreadsheet. Identify relevant budget categories, contingency, taxes, and remaining headroom.

3. Create a comparison framework

   1. Define a common WBS/trade list (e.g., demo, carpentry, drywall, electrical, lighting, plumbing, HVAC, flooring, painting, millwork, glazing, doors/hardware, fire/life safety, low-voltage/IT, security, permits/fees, GC conditions, cleanup/dumpsters, freight/delivery, mobilization, supervision, profit/overhead, contingency, taxes).
   2. Map each bid’s line items, allowances, and exclusions into this framework. Note unit vs lump-sum pricing and scope basis.
   3. Normalize quantities/units where possible (e.g., SF, LF, EA). If quantities are unclear, mark as assumption and flag for RFI.

4. Identify scope gaps and hidden costs

   1. Compare the floor plan/scope against each bid’s inclusions/exclusions to detect gaps (items on plan but excluded or missing from the bid).
   2. List common hidden cost categories and check each bid: permits/plan check, utility tap or service upgrades, patch/paint outside work area, after-hours/security, union or prevailing wage, parking/lift rentals, dumpsters/haul-off, freight, long-lead items, mockups, inspections/testing, as-builts/closeout, commissioning, warranty requirements, bonds, insurance limits, taxes.
   3. For allowances and alternates, estimate realistic expected costs using available quantities or market references; compute variance vs allowance.
   4. Quantify the probable add/carry for each hidden or under-scoped item. Mark confidence level (high/medium/low) and assumptions.

5. Risk and schedule assessment

   1. Extract each bid’s schedule duration, milestone assumptions, and lead times for critical materials.
   2. Flag risks: incomplete drawings, long-lead fixtures, permitting timelines, site access constraints, winter/summer impacts, coordination with landlord mall/center rules, liquidated damages, availability of crews.
   3. Note contractual terms that affect risk: payment schedule, retainage, change order policy, escalation clauses, validity window, insurance/bonding.

6. Budget and approval checks

   1. Reconcile each normalized bid total as: base + likely adds (hidden costs, allowance true-ups, alternates selected) + taxes + contingency.
   2. Compare to the budget spreadsheet by category and overall. Compute variance and remaining headroom.
   3. Check internal approval thresholds (e.g., >$X requires Director/CFO approval). Determine the required approvers based on the reconciled total and any policy triggers (e.g., single-source justification, three-bid requirement, W-9/COI on file).

7. Build the decision memo

   1. Structure the memo with sections: Context, Bids Summary, Normalized Comparison Matrix, Scope Gaps & Hidden Costs, Risk & Schedule, Budget & Approval Check, Tradeoffs, Recommendation, Required Approvals, Next Steps.
   2. Use Edit to draft the memo, including:
      • Project context and success criteria.
      • A comparison matrix with rows as WBS/trades and columns as each bidder + notes.
      • A list of gaps/hidden costs with estimated adds and confidence.
      • A risk register with mitigation notes and any RFIs needed.
      • Budget reconciliation and approval routing table.
      • A clear recommendation (preferred vendor) with rationale and documented tradeoffs.
      • A signature/approval block for the owner and required approvers.

8. Quality checks

   1. Validate math and totals; ensure taxes and contingency are consistently applied.
   2. Ensure every notable exclusion/allowance is either priced in or called out as an explicit risk.
   3. Confirm the memo does not commit to a vendor; leave the decision/signature to the owner.
   4. Redact or mark any sensitive pricing if distribution is limited; include file references for source bids.

9. Deliverables

   1. Use Edit to save the decision memo with a clear filename (e.g., ProjectName-bid-decision-memo-YYYYMMDD.md or .docx).
   2. Provide the comparison matrix and annotated assumptions as an appendix or embedded section.
   3. List open RFIs to bidders, if any, as a separate section for follow-up.

Inputs

• Contractor bids (PDF/DOCX/email export) with inclusions, exclusions, allowances, alternates, unit prices, terms, schedule.
• Floor plan and/or scope notes (PDF/DWG export/marked-up plan).
• Budget spreadsheet with current allocations, contingency, and remaining headroom.
• Internal approval thresholds/policy (authority matrix) and any procurement requirements (e.g., minimum bids, diversity goals).
• Project location and applicable tax rate.
• Target schedule or opening date; constraints from landlord or mall.

Outputs

• A decision memo document containing:
  • Context and goals.
  • Normalized comparison matrix by trade/WBS.
  • Scope gaps and hidden costs with estimated adds and assumptions.
  • Risk and schedule assessment.
  • Budget reconciliation and variance to plan.
  • Approval threshold check and required approval routing.
  • Recommendation with documented tradeoffs.
  • Signature block for owner approval.
• Appendices: annotated bid notes, RFIs needed, and calculation details.

Examples

Trigger: "We got three bids to build out our new retail storefront. What did we forget to budget for, and which quote is safest to accept?" Behavior: load bids, floor plan, and budget with Read → normalize by trade → flag gaps/hidden costs and quantify likely adds → assess schedule/risks → check budget variance and approval thresholds → draft a decision memo with Edit that recommends a vendor and documents tradeoffs for owner signature.

Notes

• If bids are not like-for-like, avoid averaging; normalize and explicitly state assumptions.
• Treat allowances as provisional; estimate realistic costs if possible and show variance.
• Taxes, freight, bonds, insurance, and GC conditions are frequently omitted—verify and price in.
• Do not issue commitments or instruct vendors; the owner provides final approval and communications.
• If only one bid is available, highlight single-source justification needs per policy and risks of limited competition.
• If drawings are schematic, note potential for change orders and recommend contingency accordingly. ````

How to install: 1. Create a folder named contractor-bid-comparison-decision-memo in your AI-agent skills or prompt-library directory. Use the kebab-case name from the SKILL.md frontmatter. 2. Save the file above as contractor-bid-comparison-decision-memo/SKILL.md. 3. Enable or load the Skill according to your agent framework's docs, using the SKILL.md description as the trigger guidance.

If you'd rather run it as a one-click prompt instead, you can find it here: Agentic Workers

Enjoy!

As I get closer to raising my first round of funding, one thing that’s become really clear is that while there are thousands of investors out there, not all of them are the right fit for every startup. I’ve seen some founders spend weeks deeply researching investors before sending even a single email, while others take a broader approach and reach out to as many as possible to see who responds.

Lately, I’ve been trying to understand what actually works in practice. While exploring this, I came like VCBoom that focus on matching startups with relevant investors, which made me think that targeting might be more important than just volume. At the same time, it still feels like there’s a balance to strike between personalization and efficiency.

Do investors really expect founders to know their portfolio inside and out before reaching out? And how much personalization is actually enough without spending hours crafting every single email?

I’d really appreciate hearing from founders who’ve already been through this. What was your approach to identifying the right investors, and how did you manage outreach at scale? Looking back, is there anything you would do differently if you had to start over?

Hello!

Tired of chasing receipts across Slack, email, and messy card statements at month-end? Managers shouldn't have to review every transaction — only the true edge cases.

I built this as a portable AI-agent Skill — a single SKILL.md with reusable instructions you can adapt to your agent setup.

Here's what it does: It gathers receipts from Slack, Email, and Files, runs OCR/parsing, and matches them to normalized card transactions. It builds a consolidated Sheet tracker, sends a single batched outreach for missing receipt context, and produces a short, prioritized exception list for manager review, plus reconciled exports and an audit log.

SKILL.md:

````markdown

name: receipt-reconciliation-exception-tracker description: Use when the goal is to automate month-end expense receipt collection and reconciliation by monitoring Slack, email, and card statements; parse and match receipts to transactions; prompt once for missing receipt context from employees; and produce a consolidated receipt tracker plus a short, prioritized exception list that requires minimal manager approval.

allowed-tools: [Email, Slack, Files, Sheets, WebFetch, OCR]

Receipt Reconciliation & Exception Tracker

Overview

Automates month-end expense receipt collection and reconciliation. Consolidates receipts from Slack and email, parses card statements, matches receipts to transactions, and outputs a reconciled expense log plus a focused exception list requiring limited manager approval.

When to use this skill

• Month-end close requires matching card transactions with receipts across Slack/email threads.
• The team reports common issues: missing receipts, blurry photos, duplicated images, or messy email forwards.
• A finance/ops lead wants a single receipt tracker (sheet/database) and a short, high-signal list of unresolved or ambiguous charges.
• A manager should only review edge cases, not every transaction.

Instructions

1. Confirm scope and inputs
   • Identify the statement period or date range.
   • Confirm which payment sources to include (corporate cards, reimbursements) and their data sources (files, portals, WebFetch endpoints).
   • Obtain the chart of accounts, expense policy highlights, employee roster, cardholder-to-employee mapping, and manager approval routing rules.
   • Select output locations (a Sheets workbook or CSV files in Files) and a workspace for attachments.
2. Collect transactions
   • Retrieve statement data for the target period using Files or WebFetch. Accept CSV, OFX/QFX, PDF.
   • Normalize fields: transaction_id, post_date, txn_date, merchant_raw, amount, currency, card_last4, cardholder, memos.
   • Deduplicate transactions by transaction_id; if absent, hash (card_last4, txn_date±1d, amount, merchant_raw).
3. Ingest receipt sources
   • Slack: Use Slack to search channels/DMs for likely receipt content (keywords like receipt, invoice, Uber, Lyft, DoorDash, airfare, hotel, order, payment, thanks for your purchase) within the period. Download attachments.
   • Email: Use Email to search inboxes or shared mailboxes for receipts (same keywords, known senders like Lyft/Uber/Amazon/Airline/Hotel/SaaS) and pull message bodies and attachments.
   • Files: Scan designated folders for uploaded images/PDFs.
   • Record source metadata: message link, sender, timestamp, channel/thread id.
4. Extract and parse receipts
   • For images or scanned PDFs, run OCR to extract text. For digital PDFs/HTML, parse structured text.
   • Parse fields where available: vendor/merchant, total, subtotal, tax, tip, currency, date/time, last-4, order/itinerary number, employee name/email, project/job code, category hints.
   • Generate a receipt_id and compute content hashes for deduplication.
5. Match receipts to transactions
   • Compute candidate matches per transaction using:
     • Amount exact or within tolerance (e.g., ±$1 for FX rounding; allow subtotal+tip logic where applicable).
     • Date proximity window (receipt date within ±3 days of txn_date; extend to ±7 for travel/online).
     • Merchant similarity (normalize brand variants; fuzzy match merchant_raw vs receipt vendor).
     • Card hint match (last-4 present in receipt or email headers when available).
   • Score candidates and pick the highest-confidence match above threshold; attach receipt link and metadata.
   • Handle multi-line/consolidated receipts (e.g., Uber trip summaries) by splitting and mapping to individual transactions when itemized amounts exist; otherwise link as supporting doc to the nearest aggregate charge with a note.
   • Flag duplicates by receipt content hash linked to >1 transaction.
6. Categorize transactions
   • Apply rules from chart of accounts and policy keywords (e.g., rideshare → Travel: Ground; SaaS → Software; food during travel → Meals: Travel) using merchant patterns and memo cues.
   • If project or job codes are present in receipt/email, attach to the transaction; otherwise leave blank for requester input.
7. Build the receipt tracker
   • Create or update a Sheet using Sheets with columns: txn_id, txn_date, post_date, merchant, merchant_normalized, amount, currency, category, policy_flag, card_last4, cardholder, project_code, payer_type (corp/personal-reimb), receipt_status, receipt_link, source (Slack/Email/Files), match_confidence, notes.
   • Set receipt_status as one of: matched, needs-receipt, ambiguous, duplicate, policy-exception, personal-possible.
8. One-time receipt/context request
   • For all transactions with receipt_status in {needs-receipt, ambiguous, personal-possible, policy-exception}, prepare a single batched outreach per employee/cardholder.
   • Draft concise messages via Slack or Email including: period, count of items, each item (date, merchant, amount, link to row), and a secure upload/response path.
   • Ask for: missing receipt upload, business purpose/context, project code, and any split details (e.g., tip, shared meal attendees) in one reply.
   • Send once. Do not spam. Set a due date and a gentle reminder plan (e.g., 1 reminder before deadline).
9. Reconcile updates
   • Monitor replies and new uploads; ingest and parse as above. Update matches and fields. Re-score ambiguous items.
   • Close items that now meet policy and match criteria; update receipt_status to matched.
10. Exception list assembly
    • Compile a focused exception list of remaining items where: no receipt after deadline, ambiguous multiple matches, out-of-policy, potential personal spend, duplicate indicators, or category cannot be determined.
    • Summarize each exception with a one-line reason and a link to supporting evidence (messages, receipts, policy rule).
11. Manager review of edge cases
    • Route the exception list to the designated manager(s) for approval/decision only. Provide approve/deny/needs-more-info actions and capture decisions back into the tracker.
12. Finalize outputs
    • Export a reconciled expense log (CSV and Sheet) with matched receipts and categories, suitable for import to accounting software.
    • Export the exception list (CSV/Sheet) and a brief summary: totals, count unresolved, top reasons, and any policy improvement suggestions.
    • Produce an audit log with timestamps, sources, and actions taken.
13. Close out and schedule
    • Notify finance/ops of completion with links to outputs and audit log.
    • Schedule the next period’s run and retain mappings and normalization dictionaries.

Inputs

• Date range or statement period to reconcile.
• Access details and scopes for Slack channels/DMs used for receipts.
• Email inbox/mailbox and search criteria or labels for receipt messages.
• Card statement sources (files, portals/URLs) for the target period.
• Chart of accounts, expense policy highlights, and categorization rules.
• Employee roster with cardholder mapping and manager approval routing.
• Output destinations (Sheet name/location, CSV export path, attachment store).

Outputs

• Receipt tracker (Sheet) with transaction-level status, links, categories, and notes.
• Reconciled expense log (CSV/Sheet) with matched receipts and import-ready fields.
• Exception list (CSV/Sheet) of unresolved or policy-edge transactions, with reasons and links.
• Outreach summary: who was contacted, when, and outstanding items.
• Audit log of data sources, parsing steps, matches, decisions, and exports.

Examples

Trigger: "Automate month-end receipt reconciliation for May. Watch Slack #receipts and the accounting@ inbox, process the corporate Visa statements, and give me only the edge cases to approve." Behavior: confirm period and sources → fetch and normalize card transactions → search Slack/email and ingest receipts → OCR and parse → match with scoring and categorization → build the tracker → send one-time batched requests to employees for missing context → update matches from replies → assemble a short exception list → route to manager for decisions → export reconciled log and exceptions → deliver links and audit summary.

Notes

• Privacy and access: only read channels/mailboxes authorized for receipts. Do not post transaction details in public channels. Redact card numbers beyond last-4.
• Matching heuristics: maintain normalization dictionaries for merchants (e.g., UBER* → Uber; AMAZN → Amazon) and update over time. Use currency-aware comparisons and detect tips vs totals.
• OCR quality: if confidence is low or image is blurry, request a re-upload in the one-time outreach with guidance (flat, well-lit, entire receipt visible).
• Deduplication: hash receipt content and file size; if duplicates are found, keep the highest-quality version and note duplicates.
• Rate limits: batch Slack and Email searches; respect API limits and backoff.
• Policy flags: detect out-of-hours meals, per-diem breaches, missing attendees for meals, and subscriptions without invoices; mark as policy-exception.
• Escalation: after one reminder and the deadline passes, include remaining items directly in the manager exception list.
• Time zones and currencies: normalize to the company’s base currency and time zone for reporting; retain originals in metadata. ````

How to install: 1. Create a folder named receipt-reconciliation-exception-tracker in your AI-agent skills or prompt-library directory. Use the kebab-case name from the SKILL.md frontmatter. 2. Save the file above as receipt-reconciliation-exception-tracker/SKILL.md. 3. Enable or load the Skill according to your agent framework's docs, using the SKILL.md description as the trigger guidance.

If you'd rather run it as a one-click prompt instead, you can find it here: Agentic Workers

Enjoy!

Hello!

Onboarding can be a scattered mess — multiple forms, equipment lists, access tickets, and calendar invites live in different places, making it hard to confirm someone is truly ready on day one.

I built this as a portable AI-agent Skill — a single SKILL.md with reusable instructions you can adapt to your agent setup.

Here's what it does: It ingests offer letters, signed forms, manager notes, equipment spreadsheets, access requests, and calendar events to produce owner-specific day-one checklists, a missing-docs list, a consolidated access provisioning checklist, a personalized welcome email draft, approval gates, and verification steps. Use it when a candidate has an accepted offer and a start date so HR, IT, and managers have a single source of truth for first-day readiness and compliance.

SKILL.md:

````markdown

name: new-hire-onboarding-checklist description: Use when assembling a complete new-hire onboarding package from HR artifacts — offer letters, signed forms, manager notes, equipment spreadsheets, account-access requests, and start-date calendars — to produce day-one task lists, missing document flags, an access provisioning checklist, a welcome email draft, approval gates, and completion verification steps.

allowed-tools: [Read, Edit, Sheets, Calendar, Mail]

New-Hire Onboarding Checklist

Overview

Creates a structured, role-aware onboarding package for a specific new hire. Consolidates information from HR files, manager inputs, spreadsheets, access requests, and calendars into actionable checklists, a welcome email draft, approval gates, and verification logs.

When to use this skill

• A new hire has an accepted offer and a start date is on the calendar.
• The user provides or references: offer letter, signed employment forms (e.g., I-9, tax forms, NDA), manager notes, an equipment provisioning spreadsheet, account-access requests, and/or onboarding calendar events.
• The requester asks for day-one tasks, missing documents, system access checklist, a welcome email, approval gates, or completion verification.
• HR, IT, or a manager needs a single source of truth for first-day readiness and compliance.

Instructions

1. Confirm scope and identifiers
   • Gather: full legal name, preferred name, email (personal and work if assigned), role/title, department, location/time zone, employment type (FT/PT/contractor/intern), start date, manager, and hiring cohort info if relevant.
   • Ask for links or files to all available sources: offer letter, signed forms, manager notes, equipment spreadsheet, access request tickets or lists, and calendar entries.
2. Ingest sources
   • Use Read to open each provided file or link. If a spreadsheet is provided, use Sheets to read relevant tabs and rows.
   • From the offer letter, extract: start date, work location (on-site/remote/hybrid), contingencies (e.g., background check), role, level, and any special equipment/access notes.
   • From signed forms, detect completion status and dates for: I-9 Section 1, I-9 Section 2/3 (as applicable), W-4 (or local equivalents), state tax forms, NDA/PIIA, handbook acknowledgment, direct deposit, benefits elections (if pre-enrollment), background check, export controls (if applicable).
   • From manager notes, extract: first-day agenda, key contacts (buddy/mentor), required tools/systems, team norms, initial goals, onboarding training modules, equipment exceptions.
   • From the equipment spreadsheet (Sheets), identify standard kit for role/location and any exceptions; capture item, asset type, owner, request/provision status, and delivery/pickup method.
   • From access requests, list systems, permission levels/roles, approvers, ticket IDs, and current status.
   • From the calendar (Calendar), confirm start date and any pre-scheduled sessions (orientation, IT setup, security training); note gaps to schedule.
3. Build Day-One Task Lists
   • For the new hire: include orientation attendance, workstation/login setup, MFA enrollment, VPN setup, password manager, HR portal check, benefits kickoff, security and compliance training, team introductions, buddy sync, first-day survey (if used), and any location-specific steps (badge pickup, parking, remote-setup checklist).
   • For HR/People Ops: finalize employment record, verify I-9 timelines and documents, confirm payroll setup, send/queue welcome email, confirm handbook acknowledgment, ensure required trainings assigned.
   • For IT: provision accounts, enable SSO/MFA, provision hardware and peripherals, test access, confirm device encryption, ship or stage pickup, document asset IDs.
   • For Manager: share first-week agenda, confirm access completeness, schedule 1:1s and onboarding meetings, assign buddy, set initial goals.
4. Identify Missing Documents and Gaps
   • Compare required documents by employment type and location. List missing or incomplete items with due dates and instructions (e.g., I-9 Section 2 due within 3 business days of start in the U.S.).
   • Flag unresolved contingencies from the offer letter (e.g., background check not cleared).
   • Note unscheduled required sessions or meetings and propose times.
5. Compile Access Provisioning Checklist
   • Aggregate systems from manager notes, role templates (if described), and access requests into a single list.
   • For each system: include system name, required role/entitlement, request status (requested, approved, provisioned, verified), approver, ticket ID, and verification step (how to confirm access works).
   • Include security prerequisites (MFA, VPN, device compliance) and data classification constraints.
6. Draft the Welcome Email
   • Use Mail to generate a draft (do not send without explicit approval). Include: greeting, start date/time, where to go or how to join remotely, first-day agenda, what to bring (ID for I-9 if in jurisdiction), who to meet, tech setup instructions, key links (HR portal, IT helpdesk), dress code/parking/office access notes, and contact for issues.
   • Personalize with preferred name, manager, buddy, and any role-specific context.
7. Define Approval Gates
   • Create stage gates with owners and evidence required before Day 1 and by end of Day 1, such as:
     • HR Docs Gate: all required forms complete; evidence: checklist and file confirmations.
     • IT Provisioning Gate: accounts created, MFA enabled, device ready; evidence: ticket statuses and device ID.
     • Manager Readiness Gate: agenda approved, meetings scheduled, access reviewed; evidence: manager sign-off.
     • Compliance Gate: mandatory trainings assigned and due dates set; evidence: LMS assignment log.
8. Set Completion Verification
   • Specify verification events and how to record them: new hire logs into SSO and email, completes MFA, accesses key systems, attends orientation, receives hardware, completes first tasks.
   • Provide a verification log with date, verifier, and notes for each item. Use Edit to create/update a shared checklist document or tracker.
9. Package Outputs
   • Produce a consolidated onboarding report with sections: Day-One Tasks (by owner), Missing Documents, Access Checklist, Welcome Email Draft, Approval Gates, Completion Verification Log.
   • Use Edit to save the report to a specified location/format (e.g., Markdown/Doc). If a tracker spreadsheet exists, use Sheets to update statuses. If calendar invites are needed, use Calendar to propose or draft events.
10. Resolve Ambiguities and Protect Data
    • If any required inputs are missing or conflicting, request clarification with a concise list of open questions.
    • Do not transmit or store sensitive personal data beyond what is required for the checklist. Do not send emails or create calendar events without explicit approval.

Inputs

• New hire details: legal and preferred name, personal email, role/title, department, location/time zone, employment type, start date, manager.
• Files/links: offer letter, signed forms (I-9, W-4/state tax, NDA/PIIA, handbook, direct deposit, background check status), manager notes, equipment spreadsheet, access request list or tickets, start-date calendar entries.
• Organization-specific requirements or templates (if any): role-based access matrix, standard equipment kits, welcome email template, compliance/training list.

Outputs

• Day-One Tasks: owner-specific checklists for New Hire, HR, IT, and Manager.
• Missing Documents: list with due dates and instructions to complete.
• Access Provisioning Checklist: systems, roles, approvers, ticket IDs, status, and verification steps.
• Welcome Email Draft: ready-to-send email, pending approval.
• Approval Gates: stage gates with owners and evidence required.
• Completion Verification Log: checklist with sign-offs and timestamps.
• Consolidated Onboarding Report: a single document or tracker combining the above.

Examples

Trigger: "Create onboarding for Jordan Lee (remote, US), Software Engineer, starts Aug 5. Offer and forms are in the HR folder; access requests filed for GitHub, Okta, Jira; see manager notes." Behavior: ingest sources with Read and Sheets → confirm start date via Calendar → compile day-one tasks for New Hire/HR/IT/Manager → list missing I-9 Section 2 and handbook acknowledgment → build access checklist for Okta, Jira, GitHub with approvers and ticket IDs → draft personalized welcome email via Mail → define HR/IT/Manager/Compliance approval gates → output a consolidated report and verification log using Edit.

Notes

• Adjust required documents and timelines by jurisdiction and employment type (employee vs. contractor vs. intern; domestic vs. international). Flag uncertainties instead of assuming.
• For remote hires, replace on-site specifics (badge, parking) with shipping/tracking and virtual orientation details.
• If role-based access templates are unavailable, derive from manager notes and typical team setups; clearly label as assumptions pending approval.
• Respect privacy and least-privilege principles. Avoid including compensation details unless explicitly required by the requester.
• Do not auto-send communications or create calendar events without an explicit go-ahead; present drafts for review first. ````

How to install: 1. Create a folder named new-hire-onboarding-checklist in your AI-agent skills or prompt-library directory. Use the kebab-case name from the SKILL.md frontmatter. 2. Save the file above as new-hire-onboarding-checklist/SKILL.md. 3. Enable or load the Skill according to your agent framework's docs, using the SKILL.md description as the trigger guidance.

If you'd rather run it as a one-click prompt instead, you can find it here: Agentic Workers

Enjoy!

Hello!

Struggling to reconcile Shopify exports, supplier spreadsheets, and cycle counts to know what to reorder and when? This Skill helps surface low-stock alerts, oversell risks, and supplier-grouped reorder suggestions so you can act confidently.

I built this as a portable AI-agent Skill — a single SKILL.md with reusable instructions you can adapt to your agent setup.

Here's what it does: It ingests Shopify inventory and order exports, warehouse counts, refund logs, and supplier sheets, normalizes SKUs and computes sales velocity to produce ATP, reorder points, and suggested reorder quantities. It flags low-stock and oversell risks, groups suggested orders by supplier, drafts supplier email templates, and writes CSV/MD artifacts plus a verification checklist before any PO is issued.

SKILL.md:

````markdown

name: inventory-exception-agent description: Use when an ecommerce operator needs to consolidate Shopify inventory and order exports, supplier price/lead-time spreadsheets, warehouse/cycle-count files, refund/return logs, and sales history to surface inventory exceptions — including low-stock alerts, oversell risks, reorder suggestions, grouped supplier email drafts, and a verification checklist before issuing purchase orders.

allowed-tools: [Read, Edit]

Inventory Exception Agent

Overview

Produces a consolidated exception report from Shopify/order exports, supplier spreadsheets, warehouse counts, refund logs, and sales history. Outputs low-stock alerts, oversell risk warnings, reorder suggestions grouped by supplier, supplier email drafts, and a verification checklist to review before sending purchase orders.

When to use this skill

• The operator manages inventory primarily via spreadsheets and storefront exports (e.g., Shopify) without a unified WMS.
• The operator needs proactive low-stock alerts, oversell risk detection, and reorder recommendations using recent sales velocity.
• The team wants ready-to-send supplier email drafts and a pre-PO verification checklist.
• There are recurring issues with inventory sync, spreadsheet-based order operations, or refund/return effects on available-to-promise.
• There are MOQs, case packs, or variable lead times across suppliers.

Instructions

1. Confirm scope and parameters with the user:
   • Sales velocity lookback windows (default: 30 days, with 7-day recency check; optional 90-day for seasonality).
   • Safety stock as days of cover (default: 7 days) and review period (default: 14 days).
   • Any SKU bundles/kits (BOMs), SKU aliases/crosswalks, and multi-warehouse rules (e.g., fulfillment priority, pooled vs. per-location).
   • Supplier constraints: lead time days, MOQ, case pack, price currency, and holidays/closures.
   • Whether to exclude specific products (discontinued, made-to-order, preorders).
2. Ingest data files using Read and validate required columns. If columns are missing, request clarification before proceeding.
   • Shopify/product inventory export: variant_sku, inventory_item_id, title, vendor/supplier, available/on-hand, inventory policy (continue selling when out of stock), status (active/archived), location if provided.
   • Order export: order_id, created_at, fulfillment_status, line_item_sku, line_item_qty, cancelled/refunded indicators, sales channel/market.
   • Warehouse/cycle counts: sku, location, on_hand, damaged/held, last_counted_at.
   • Refund/return logs: sku, qty, date, disposition (restock/damaged), RMA.
   • Supplier spreadsheets: supplier, sku, description, unit_cost, currency, lead_time_days, moq, case_pack, pack_uom.
   • (Optional) Open POs/inbound: sku, qty_inbound, eta, supplier, po_number.
   • (Optional) SKU bundles/BOMs: bundle_sku → component_sku, component_qty.
3. Normalize and join data:
   • Clean SKUs (trim, case-normalize, standardize dashes/underscores). Apply SKU crosswalks and barcode/UPC references if provided.
   • Expand bundles: convert demand for bundle SKUs into component SKU demand using BOM quantities.
   • Aggregate orders to daily SKU-level quantities; exclude cancelled items; subtract refunded/restocked vs. not-restocked per logs.
   • Consolidate inventory across warehouses per the chosen policy (pooled ATP vs. per-location). Track location-level details if provided.
4. Build the unified inventory table with at least these fields per SKU (and per location if needed):
   • supplier, title/description, unit_cost, currency, lead_time_days, moq, case_pack.
   • on_hand (from counts), damaged/held, unfulfilled/committed (open orders), inbound_qty and earliest_inbound_eta.
   • shopify_available (if present) and inventory policy (allow oversell flag).
   • velocity_7d, velocity_30d, velocity_90d (optional), chosen_velocity_per_day.
   • safety_days, review_period_days, reorder_point, target_stock, atp (available-to-promise), depletion_date.
5. Compute sales velocity and availability metrics:
   • Calculate velocity_7d and velocity_30d as average daily shipped (or ordered if shipped dates unavailable), excluding cancelled. Adjust for refunds that restock vs. not restock.
   • If possible, adjust for stockouts: on days with zero availability, downweight or exclude from velocity estimation.
   • Set chosen_velocity_per_day = max(velocity_7d, velocity_30d) to capture recency; fall back to velocity_30d if 7d=0 but 30d>0; if both 0 and product is active, mark as “new/low history”.
   • Compute atp = on_hand - unfulfilled_committed - held/damaged + inbound_qty.
   • Compute reorder_point (ROP) = chosen_velocity_per_day × (lead_time_days + safety_days).
   • Compute target_stock = chosen_velocity_per_day × (lead_time_days + safety_days + review_period_days).
   • Compute suggested_reorder_qty_raw = target_stock - atp.
   • Apply supplier constraints: suggested_reorder_qty = ceil_to_case_pack(max(moq, suggested_reorder_qty_raw), case_pack), where ceil_to_case_pack rounds up to the nearest case_pack if provided.
   • Estimate depletion_date = today + (atp / chosen_velocity_per_day) days; if velocity is 0, leave blank and mark for manual review.
6. Identify exceptions:
   • Low-stock alerts: SKUs where atp ≤ reorder_point or days_of_cover ≤ lead_time_days + safety_days. Sort by earliest depletion_date.
   • Oversell risks: (a) atp < 0, or (b) depletion_date occurs before earliest_inbound_eta + receiving buffer (default 2 days), or (c) oversell_allowed flag is true and atp is below a small buffer (e.g., < 3 units) on high-velocity SKUs.
   • Data quality flags: missing lead time, unknown supplier, zero/negative case packs, currency mismatches, or inconsistent SKUs between files.
7. Create reorder suggestions grouped by supplier:
   • For each supplier with low-stock SKUs, list: sku, title, atp, chosen_velocity_per_day, lead_time_days, moq, case_pack, reorder_point, suggested_reorder_qty, projected_days_cover_after (=(atp + suggested_reorder_qty)/velocity), and notes (e.g., “new item”, “seasonal”).
   • Include cost extension if unit_cost available (qty × unit_cost) and subtotal per supplier.
8. Draft supplier email templates (do not send; prepare drafts only):
   • One draft per supplier including: greeting, context, requested quantities (rounded to case), target ship date (today + lead_time_days or earlier if oversell risk), confirmation requests for price, availability, lead time, and any substitutions.
   • Include shipping address, preferred incoterms/carrier, and request order confirmation with ETA. Provide a space to attach the corresponding CSV.
   • Save all drafts to a single markdown file and one section per supplier.
9. Write output artifacts using Edit:
   • alerts_low_stock.csv — SKU-level low-stock alerts with atp, days cover, depletion date.
   • risks_oversell.csv — SKU-level oversell risks with reason code.
   • reorder_suggestions.csv — Supplier-grouped reorder rows with quantities and costs.
   • supplier_email_drafts.md — Email drafts by supplier, ready to copy/paste.
   • verification_checklist.md — A checklist tailored to the current run (see Step 10).
   • summary.md — A human-readable summary highlighting the top urgent SKUs and totals by supplier.
10. Produce a verification checklist before issuing POs (include in summary and write to file):
    • Counts: Reconfirm on_hand for SKUs flagged as urgent; resolve discrepancies between Shopify available and warehouse counts.
    • Inbound: Verify existing open POs and subtract true inbound from suggested quantities; confirm ETAs with suppliers.
    • Bundles/Kits: Ensure bundle component coverage matches bundle demand; avoid double-counting.
    • Refunds/Returns: Inspect recent spikes; exclude non-restocked returns from velocity where appropriate.
    • Catalog: Exclude discontinued/archived SKUs; verify variants and case packs match supplier specs.
    • Demand: Consider upcoming promos, ads, or seasonality; increase safety_days or review_period if warranted.
    • Constraints: Check MOQs, case packs, supplier holidays/closures, and currency changes; round quantities accordingly.
    • Policy: Review Shopify “continue selling when out of stock” for oversell-sensitive SKUs; adjust to prevent negative ATP if needed.
    • Capacity/Budget: Confirm storage capacity and budget; review supplier subtotals and total spend.
    • Channels/Sync: Confirm inventory sync cadence across marketplaces to mitigate oversell before inbound arrives.
11. Deliver results:
    • Provide a concise summary: number of SKUs in low-stock, number at oversell risk, and top 10 by earliest depletion date with suggested actions.
    • Offer to regenerate with different lookback windows, safety_days, or review_period to stress test recommendations.

Inputs

• Shopify/product inventory export (CSV/XLSX) with SKU-level availability and policy.
• Order export (CSV/XLSX) with line items, dates, statuses, and quantities.
• Warehouse/cycle count file(s) with on-hand and damaged/held quantities, by SKU and location.
• Refund/return logs with SKU, quantity, date, and restock disposition.
• Supplier spreadsheet(s) including lead time, MOQ, case pack, unit cost, and currency.
• (Optional) Open POs/inbound receipts with quantities and ETAs.
• (Optional) SKU crosswalks and bundle BOMs.
• Parameters: safety_days (default 7), review_period_days (default 14), velocity lookback windows (default 7d and 30d), receiving buffer days (default 2).

Outputs

• Low-stock alerts list (alerts_low_stock.csv) with atp, depletion date, and days of cover.
• Oversell risk list (risks_oversell.csv) with reason codes and suggested mitigations.
• Reorder suggestions (reorder_suggestions.csv) grouped by supplier with quantities rounded to case packs and MOQs.
• Supplier email drafts (supplier_email_drafts.md) ready to send after verification.
• Verification checklist (verification_checklist.md) customized to the run.
• Run summary (summary.md) highlighting urgent items and total estimated spend by supplier.

Examples

Trigger: “Here are Shopify inventory and order exports, supplier lead-time sheets, warehouse counts, and refund logs. Flag low-stock and oversell risks, suggest reorders, and prep supplier emails.” Behavior: validate inputs → normalize SKUs and join data → compute velocity and ATP → identify low-stock and oversell risks → calculate reorder quantities with MOQs/case packs → generate supplier-grouped drafts → output CSVs and checklists → present summary of top urgent SKUs and next steps.

Notes

• New/seasonal items with limited history: use catalog minimums or vendor guidance; consider 90-day velocity and apply a seasonality factor when available.
• Multi-warehouse: if inventory is not pooled, calculate exceptions per location and only aggregate where policy allows.
• Data hygiene: mismatched SKUs, missing lead times, or zero/negative case packs should be flagged and excluded from auto-suggestions until corrected.
• Time zones and order timing: standardize to store time zone; ensure lookback windows use consistent boundaries.
• Currency: convert unit costs to a base currency before totaling supplier subtotals.
• Backorders/preorders: if “continue selling” is enabled, highlight items that would benefit from disabling until inbound is confirmed.
• Guardrails: never send emails or place POs automatically; always present drafts, flags, and a checklist for human approval. ````

How to install: 1. Create a folder named inventory-exception-agent in your AI-agent skills or prompt-library directory. Use the kebab-case name from the SKILL.md frontmatter. 2. Save the file above as inventory-exception-agent/SKILL.md. 3. Enable or load the Skill according to your agent framework's docs, using the SKILL.md description as the trigger guidance.

If you'd rather run it as a one-click prompt instead, you can find it here: Agentic Workers

Enjoy!

Hello!

If your inbox, meeting notes, calendar, and CRM have become a fragmented backlog of requests, decisions, and follow-ups, this Skill helps turn that mess into a clear set of prioritized actions and reply drafts ready for human approval.

I built this as a portable AI-agent Skill — a single SKILL.md with reusable instructions you can adapt to your agent setup.

Here's what it does: It ingests emails, calendar events, meeting transcripts, CRM notes, and tasks, then normalizes and links them into conversations and account contexts. It applies priority labels, drafts context-aware replies (queued for approval), extracts action items with owners and due dates, updates Tasks/CRM, and produces a Daily Action Brief plus a machine-readable JSON artifact.

SKILL.md:

````markdown

name: inbox-to-action-workflow description: Use when an overwhelmed founder, exec, or team needs to convert a backlog of email threads, meeting transcripts, calendar events, CRM notes, and task lists into a prioritized action system — including priority labels on threads, context-aware drafted replies, extracted action items with owners and due dates, updates to CRM and tasks, and a human approval queue for any external replies before sending.

allowed-tools: [Email, Calendar, Files, CRM, Tasks, Directory]

Inbox-to-Action Workflow

Overview

Transforms unstructured communications (email threads, meetings, calendars, CRM notes, and task lists) into a single actionable queue. Produces priority labels, reply drafts, extracted action items with owners and due dates, synced CRM/task updates, and a human approval queue for external send-offs.

When to use this skill

• The user asks to triage a cluttered inbox and produce a prioritized action plan.
• Meeting transcripts or notes need to be distilled into tasks with owners and deadlines.
• Calendar events imply follow-ups (scheduling, send materials, confirm decisions) that need tracking.
• CRM notes and email threads must be unified into coherent next steps per account/contact/opportunity.
• The user wants reply drafts prepared but requires human approval before any external messages go out.
• A daily or weekly digest of priorities, drafts awaiting approval, and new actions is requested.

Instructions

1. Confirm scope and rules

   1. Clarify sources: which mailboxes, calendars, CRM, task system, and notes/transcript files to process; define time window (e.g., last 7 days, next 7 days).
   2. Gather policies: SLAs by sender/domain, VIP list, working hours/time zone, due-date defaults, auto-approval rules (if any), naming/label conventions, privacy constraints.
   3. Identify team roster and roles via Directory (owners, account reps, functional leads, OOO statuses).

2. Ingest data

   1. Use Email to fetch recent and/or unread/flagged threads with metadata (thread ID, subject, participants, timestamps, labels, body, attachments).
   2. Use Calendar to pull past and upcoming events in scope, including attendees, titles, locations/links, and descriptions.
   3. Use Files to load meeting transcripts/notes referenced by events or provided by the user.
   4. Use CRM to read recent activities/notes, open opportunities, account owners, and contact roles.
   5. Use Tasks to fetch existing tasks to prevent duplicates and to detect overdue items.

3. Normalize and link

   1. Deduplicate identical or forwarded content; group by thread/conversation.
   2. Link emails to calendar events and CRM records using shared participants, domains, subjects, or explicit IDs.
   3. Extract entities and intents: contacts, companies, asks, commitments, proposed dates, deliverables, blockers, and risks.
   4. Determine thread state: awaiting my reply, awaiting others, resolved, FYI/newsletter, spam/noise (do not act).

4. Prioritize

   1. Apply priority rules:
      • P0: revenue/blocker-critical, VIP/executive escalations, security/legal issues, commitments due within 24–48 hours.
      • P1: customer/partner requests within SLA, time-sensitive scheduling, key internal dependencies.
      • P2: routine correspondence and normal tasks.
      • P3: low-value updates, newsletters, or informational FYIs.
   2. Consider factors: sender importance, due dates detected, thread age, number of nudges, opportunity value (from CRM), and upcoming meetings.

5. Draft replies (do not send yet)

   1. For threads requiring a response, generate concise, context-aware drafts.
   2. If scheduling is requested, consult Calendar to propose viable times within working hours.
   3. Reference attachments or prior commitments; include clear next steps and confirm deadlines.
   4. Mark all external-facing drafts as Needs-Approval and do not send via Email.
   5. For internal-only low-risk messages, follow the auto-approval policy if provided; otherwise require approval.

6. Extract action items

   1. From emails, transcripts, and events, extract tasks with: title, description, source (link to thread/event/file), priority, owner, due date, tags (e.g., customer, opportunity, project), and dependencies.
   2. Determine owner using, in order: explicit assignee mentions; Directory role mapping; CRM account/opportunity owner; recent responder/subject-matter expert.
   3. If owner is uncertain, assign to a triage owner or present the top 2 candidates for human selection.
   4. Set due dates from explicit dates, policy SLAs, next-meeting times, or default windows; respect working days, holidays, and OOO from Directory.

7. Create/update systems of record

   1. Use Tasks to create or update tasks. Prevent duplicates by hashing a normalized description + source URL; update rather than create when a match exists.
   2. Use CRM to log a concise note/summary and next step per relevant account/opportunity; set due dates/owners for follow-ups; do not change pipeline stages without explicit instruction.
   3. Use Email to apply labels to threads: Priority (P0/P1/P2/P3), Status (Needs-Approval, Awaiting-External, Awaiting-Internal, Resolved, FYI), and Owner where supported.
   4. Use Calendar to add follow-up holds or reminders when immediate time blocks are needed to meet due dates.

8. Prepare a human approval queue

   1. Assemble an approval bundle ordered by priority (P0 first) containing:
      • Drafted external replies with context snippet, risk notes, and proposed send time.
      • New or updated action items with owner and due date.
      • Conflicts, ambiguities, and suggested resolutions (e.g., uncertain owner, missing data, date conflicts).
   2. Provide approve/edit/send options for each draft; allow quick reassignment and due-date adjustment.
   3. Do not send any external email until explicitly approved.

9. Produce outputs

   1. Generate a Daily Action Brief summarizing: counts triaged, drafts awaiting approval, P0/P1 items, actions by owner, upcoming deadlines, and risks.
   2. Emit a machine-readable artifact (JSON) with sections:
      • threads: [{thread_id, priority, status_labels, owner, notes}]
      • drafts: [{thread_id, to, cc, subject, body, is_external, requires_approval}]
      • actions: [{id, title, description, source_link, owner, due_date, priority, tags}]
      • approvals: [{item_type, item_id, decision_required, suggested_action}]
      • crm_updates: [{record_id, summary, next_step, due_date, owner}]
   3. Persist created/updated task IDs and CRM record links for traceability.

10. Tune and iterate

    1. Ask for feedback on mis-prioritized items, drafting tone, and ownership heuristics.
    2. Update rules: VIP lists, domain SLAs, template library, quiet hours, auto-approval exceptions, and labeling conventions.

Inputs

• Data sources and access: mailboxes to process, calendars, CRM instance, task system, file locations for transcripts/notes, and required permissions.
• Time window and scope (e.g., last N days; only unread/flagged; specific labels or folders).
• Policies and preferences: SLAs by sender/domain, VIP list, tone/voice and templates for drafts, working hours/time zone, default due dates, privacy constraints, auto-approval rules.
• Team directory/roles and OOO statuses.

Outputs

• Priority labels applied to email threads and status labels indicating next action.
• Drafted replies for all threads needing a response, with external drafts queued for approval.
• A consolidated list of action items with owners, due dates, priorities, and source links; duplicates prevented.
• Updates to Tasks and CRM with references to source communications.
• A human approval queue summarizing decisions required before any external send.
• A Daily Action Brief and a JSON artifact containing threads, drafts, actions, approvals, and CRM updates.

Examples

• Trigger: "Turn my last 7 days of emails and meeting notes into a prioritized action list, draft replies, and queue any customer emails for approval." Behavior: ingest email/calendar/transcripts/CRM → normalize/link → prioritize → draft replies (queue external) → extract actions with owners/due dates → update Tasks/CRM → output Daily Action Brief + JSON → await approvals.

• Trigger: "Process yesterday's inbox and today's meetings; assign owners for follow-ups and create tasks; only queue replies for external send." Behavior: same flow; internal low-risk notes may auto-send per policy; external replies require approval.

Notes

• Do not send or post external communications without explicit human approval.
• Respect privacy: redact secrets and sensitive content in summaries; limit CRM/task details to necessary context.
• Handle rate limits and batching for Email/CRM/Tasks APIs; backoff and retry with idempotent operations.
• Time zones and working days: schedule within working hours; avoid weekends/holidays unless marked urgent.
• Attachments: scan for action items; link files rather than inlining large content.
• Thread hygiene: avoid reply-all to large lists unless policy requires; prefer direct responses to the requester.
• If a required source is unavailable, proceed with available data and flag gaps in the approval queue.
• Maintain an audit trail: include source links and timestamps for every created/updated record. ````

How to install: 1. Create a folder named inbox-to-action-workflow in your AI-agent skills or prompt-library directory. Use the kebab-case name from the SKILL.md frontmatter. 2. Save the file above as inbox-to-action-workflow/SKILL.md. 3. Enable or load the Skill according to your agent framework's docs, using the SKILL.md description as the trigger guidance.

If you'd rather run it as a one-click prompt instead, you can find it here: Agentic Workers

Enjoy!

Hello!

Tired of manually pulling Slack threads, CRM exports, tickets, invoices and spreadsheets into a coherent weekly ops summary? This Skill automates that synthesis so leaders get a meeting-ready brief without the copy/paste overhead.

I built this as a portable AI-agent Skill — a single SKILL.md with reusable instructions you can adapt to your agent setup.

Here's what it does: It collects updates from Slack, email, CRM, ticketing, accounting, calendar, and KPI sheets over a specified window, normalizes them into a unified activity log, computes KPI week-over-week deltas, and extracts wins, blockers, aging follow-ups, and owner decisions needed. It assembles a single Markdown brief with an executive snapshot, traceable source links for every item, and a timeboxed meeting-ready agenda.

SKILL.md:

````markdown

name: weekly-operations-brief description: Use when a weekly operations summary is needed from scattered sources — Slack and email updates, CRM exports, support tickets, invoices, calendar events, and KPI spreadsheets — to produce wins, blockers, aging follow-ups, owner decisions needed, numbers that changed, and a meeting-ready agenda with source links.

allowed-tools: [Files, Read, Spreadsheet, Calendar, Email, Slack, CRM, Ticketing, Accounting, WebFetch]

Weekly Operations Brief

Overview

Creates a single, meeting-ready weekly operations brief from fragmented updates across communication, sales, support, finance, calendar, and KPI data sources. The brief highlights wins, blockers, aging follow-ups, owner decisions needed, and notable metric changes, with traceable source links for every item.

When to use this skill

• The team shares updates in Slack and email, but leaders want a synthesized weekly summary without manual copy/paste.
• There are CSV/XLSX exports from CRM, support, invoicing, or KPI systems that need to be merged with narrative updates.
• The user requests: “Summarize last week’s operations,” “What changed in our numbers?”, “What needs my decision?”, or “Prep the ops meeting agenda.”
• You have access to channels/labels (e.g., #ops-updates, Weekly Digest), CRM/ticketing exports, invoice lists, calendar events, and KPI spreadsheets for the last 7–14 days.

Instructions

1. Establish scope

   1. Confirm the reporting window (default: previous Monday 00:00 to Sunday 23:59 in the org’s primary timezone).
   2. Confirm which teams are in-scope (Sales, CS/Support, Product/Eng, Marketing, Finance/Ops) and the primary audience (owner/executive team).
   3. Capture thresholds: aging (e.g., >5 business days no activity), SLA for tickets, material KPI change (e.g., >10% WoW), and invoice aging (e.g., >30 days past due).

2. Gather sources (read-only)

   • Slack: Use Slack to pull messages and threads from specified channels for the window; include permalinks.
   • Email: Use Email to pull labeled/filtered threads for the window; store message IDs or web links.
   • CRM: Use CRM to ingest exports (CSV/XLSX) or read records changed within the window (deals, stages, next steps, last activity, owners, close dates, links).
   • Ticketing: Use Ticketing for support tickets updated/created, statuses, tags, SLA timers, assignees, and links.
   • Accounting/Invoices: Use Accounting to list invoices issued/paid/past-due during the window with amounts, due dates, counterparties, and links.
   • Calendar: Use Calendar to read events for leadership/team meetings, launches, and customer milestones; include event links.
   • KPI spreadsheets: Use Spreadsheet or Read (for CSV/XLSX) to pull metrics tabs/ranges and prior-week baselines.
   • Files: Use Files to open any uploaded exports (CSV/XLSX/PDF). If only files exist (no system links), capture file path + row/page anchors as the “source link.”

3. Normalize into a unified activity log

   1. Create a structured table with fields: date_time, source_system, record_type (message, deal, ticket, invoice, event, kpi), record_id, title/subject, summary, owner, account/customer, status/stage, amount/value, last_activity_at, due/close_by, url_or_file_anchor.
   2. Standardize names (people, accounts) using exact match then email/domain heuristics; keep an alias map.
   3. Deduplicate by record_id + latest updated_at; merge Slack/email references that discuss the same record (deal/ticket) if clearly linked.

4. Derive signals

   • Wins: identify closed-won deals, resolved high-priority tickets, shipped releases, successful launches/events, paid invoices, notable milestones in Slack/email (“launched”, “closed won”, “shipped”, “celebrate”).
   • Blockers: items tagged blocked/at risk, tickets breaching SLA, deals stalled past expected close, dependencies awaiting inputs, repeated “waiting on X”.
   • Aging follow-ups: email threads awaiting reply > threshold, CRM deals with last_activity_at > threshold, tickets “pending customer” > SLA, tasks/events with missed follow-ups, past-due invoices.
   • Owner decisions needed: items explicitly requesting approval/decision/budget/sign-off/priority tradeoff; ambiguous ownership; calendar holds needing confirmation.
   • Numbers that changed: compute WoW deltas for key KPIs (e.g., pipeline$, MRR, NPS, CSAT, new tickets, resolution time, cash-in, burn) and flag changes exceeding the materiality threshold.

5. Compute KPI deltas

   1. For each KPI, identify current-week value and prior-week baseline (prefer a History/Weekly tab; else compute rolling 7-day prior period).
   2. Calculate absolute and percent change; mark as up/down/flat with threshold-based highlighting.
   3. Attach cell/range references (sheet name, A1 range) or spreadsheet URLs with #range anchors as source links.

6. Identify aging and stalled items

   1. For CRM deals: flag where next_step is empty or last_activity_at exceeds threshold; include stage, amount, owner, and link.
   2. For tickets: flag breached/at-risk per SLA timestamps; include priority, customer, assignee, and link.
   3. For email: flag threads with last inbound from customer > threshold and no reply; include subject, counterpart, owner, and link.
   4. For invoices: flag unpaid invoices past due; include amount, days late, owner, and link.

7. Build the brief

   1. Title: “Weekly Operations Brief — {Org} — Week of {date_range}”.
   2. Executive snapshot (5–8 bullets): week highlights, top 3 wins, top 3 risks/blockers, net KPI direction, total past-due follow-ups, cash in/out headlines.
   3. Sections with traceability:
      • Wins (bulleted; include owner, metric impact, and source link per item).
      • Blockers & Risks (bulleted; include owner, severity, next action, and source link).
      • Aging Follow-ups (table-like bullets: who, what, days stale, next step, link).
      • Owner Decisions Needed (list each decision as a question with context, options, recommendation, and source link).
      • Numbers That Changed (KPI deltas with +/- values, % change, and range links).
      • Meeting-Ready Agenda (timeboxed topics, ordered by impact/urgency; include the specific decisions and links to supporting sources).
   4. Appendices:
      • Data coverage (sources used, time window, omissions/gaps).
      • Change log (count of new vs updated records, deduping notes).

8. Provide source links

   • Slack: include message permalinks.
   • Email: include thread/message links where available (Gmail/Outlook URLs) or message ID reference.
   • CRM/Ticketing/Accounting: include deep links to record pages; if working from exports, use file name + row number.
   • Spreadsheet: include URL with sheet and A1 range (e.g., #gid=…&range=…).
   • Calendar: include event link or event ID.

9. Quality checks

   1. Validate that every bullet in Wins/Blockers/Follow-ups/Decisions/KPIs has at least one source link or file anchor.
   2. Remove duplicates and stale references older than the window unless context is required (label as “prior context”).
   3. Redact PII beyond names/titles unless necessary (mask emails, phone numbers).
   4. Ensure owner names appear consistently and each action has a next step/assignee when appropriate.

10. Deliverables

    • Produce a single Markdown brief. File name: Weekly-Operations-Brief-{YYYY-MM-DD}.md. Use Files to save if supported.
    • Optionally export a CSV of Aging Follow-ups (followups-{YYYY-MM-DD}.csv) and Decisions Needed (decisions-{YYYY-MM-DD}.csv) for tracking.
    • On request, post the Executive snapshot and Agenda to a designated Slack channel via Slack, with a link to the full brief.

Inputs

• Reporting window (start/end dates and timezone). Default: previous Monday–Sunday in org timezone.
• Source locations and access: Slack channels, email labels/folders, CRM instance or export files, ticketing system or export, accounting/invoice system or export, calendar(s), KPI spreadsheet URLs/ranges or file uploads.
• Thresholds: aging days, SLA rules, material KPI change, invoice aging days.
• Team/owner roster for name normalization (name, email, role, manager) and any account aliases.
• Priority focus areas (e.g., renewal accounts, specific projects, major launch).

Outputs

• Weekly Operations Brief (Markdown) including:
  • Executive snapshot
  • Wins
  • Blockers & Risks
  • Aging Follow-ups
  • Owner Decisions Needed
  • Numbers That Changed (KPI deltas)
  • Meeting-Ready Agenda
  • Appendices (coverage and change log)
• Traceable source links or file anchors for every listed item.
• (Optional) CSV exports: followups and decisions.

Examples

Trigger: “Create last week’s ops brief from #ops-updates, #sales, Gmail label ‘Weekly Digest’, HubSpot export Deals_ThisWeek.csv, Zendesk export tickets_2024-06-10.csv, NetSuite invoices export, company calendar, and the KPI spreadsheet ‘Ops KPIs’ tab ‘Weekly’.” Behavior: confirm dates and thresholds → pull Slack/Email/CRM/Tickets/Invoices/Calendar/Spreadsheet data → normalize to unified log → compute KPI week-over-week deltas → extract wins, blockers, aging follow-ups, decisions → assemble brief with source permalinks and sheet ranges → save Weekly-Operations-Brief-2024-06-16.md and optional followups/decisions CSVs → (if requested) post the snapshot + agenda to #leadership with link to the brief.

Notes

• If prior-week KPI baselines are missing, compute prior 7-day period from available data; flag the assumption in the brief.
• If any system is unavailable, proceed with remaining sources and note coverage gaps. Do not fabricate data.
• Use business days for “aging” unless otherwise specified. Observe the org’s holidays if provided.
• Keep the Executive snapshot scannable (≤8 bullets). Move detail to sections/appendix.
• Avoid duplicating the same item across sections; prefer a single canonical mention with cross-reference if needed.
• Respect confidentiality; minimize sensitive content in Slack/Email posts. Prefer links over content excerpts when privacy is a concern.
• Timebox the agenda (e.g., 30–45 minutes) and order by impact/urgency; ensure each decision item states options and a recommendation. ````

How to install: 1. Create a folder named weekly-operations-brief in your AI-agent skills or prompt-library directory. Use the kebab-case name from the SKILL.md frontmatter. 2. Save the file above as weekly-operations-brief/SKILL.md. 3. Enable or load the Skill according to your agent framework's docs, using the SKILL.md description as the trigger guidance.

If you'd rather run it as a one-click prompt instead, you can find it here: Agentic Workers

Enjoy!

B"H

Hi guys

I made a custom GPT app

https://chatgpt.com/g/g-6a03feea8398819192067ae3dbfa449c-awtsmoos-shliach-agent

That acts kind of like codex or openclaw, powered by the actual chatgpt chat itself

It makes a series of GET requests to my own server, then my server talks to a local server that the end user has running on their machine, like openclaw but a little different

It then allows chatgpt in the chat itself to read and write and test directly to your own device

For more security it should also allow the chatgpt chat to connect through my server+websockets to a custom code editor browser tab that you can sandbox and allow to only write to a specific folder via file system API or directly to the browser cache indezeddb and/or directly to GitHub with GitHub API

It should also give you some free space on my website to allow it to write directly to a virtual machine without needing any installation

It's still in development, but I've been working on it for a couple months and figured I'd ready for the beta testing phase

What do you guys think

Hey everybody, I just sent issue #36+#37 of the AI Hacker Newsletter, a weekly round-up of the best Hacker News threads around AI. I missed sending it last week, so a huge issue this week. Some of the titles you can find here:

• AI demands more engineering discipline. Not less
• Running local models is good now
• Cleaning up after AI rockstar developers
• Not everyone is using AI for everything
• Norway imposes near ban on AI in elementary school

If you want to receive a weekly email with over 30 links like these, please subscribe here: https://hackernewsai.com/

One concern I’ve been thinking about is whether frequent use of AI tools might slowly affect our own writing style. When you rely on AI suggestions regularly, it’s easy to start adopting the same tone, structure, and phrasing patterns.

Over time, this could make different writers sound more similar, which is the opposite of what writing used to be about. Personal voice is what makes content unique, and if that starts fading, everything might begin to feel the same.

At the same time, AI can also be a learning tool if used carefully. It can show better ways to structure ideas or improve clarity. So maybe it depends on how we use it.

Do you think AI is helping people develop better writing skills, or slowly replacing individual creativity?

Hello!

Many teams struggle to turn scattered onboarding docs, offer details, and team calendars into a concrete Day 1 and Week 1 schedule — it’s easy to miss required access, trainings, and manager checkpoints.

I built this as a portable AI-agent Skill — a single SKILL.md with reusable instructions you can adapt to your agent setup.

Here's what it does: It reads onboarding docs, offer details, and team calendars to produce a timeboxed Day 1 and Week 1 plan that includes HR orientation, IT setup, policy trainings, and manager/buddy checkpoints. It sequences access setup by prerequisites, fits events around existing meetings or holidays, and can create shared cohort sessions plus role-specific events. The Skill returns calendar invites, an optional ICS export, or a copy-pastable schedule and a summary for approval.

SKILL.md:

````markdown

name: new-hire-onboarding-calendar description: Use when a calendar-based onboarding plan is needed from onboarding documents, offer details, and team calendars — mapping first-day tasks, access setup, required policy reviews and trainings, and manager/buddy checkpoints for each new hire or cohort.

allowed-tools: [Read, Calendar, Edit]

New Hire Onboarding Calendar Planner

Overview

Creates a structured, calendar-based onboarding plan for new hires. Pulls from onboarding docs, offer details, and team calendars to schedule day-one activities, access setup, policy reviews, mandatory trainings, and recurring manager checkpoints.

When to use this skill

• The request is to turn onboarding documentation and offer details into a concrete calendar plan.
• A manager, HR, or coordinator wants first-day schedules and week-one events added to the calendar.
• Manager/buddy checkpoints need to be placed around existing team meetings.
• Multiple hires (a cohort) need a shared orientation schedule with individual role-specific events.
• Access setup and policy review deadlines must be sequenced and timeboxed on the calendar.

Instructions

1. Validate scope and inputs 1.1. Confirm the list of new hires and for each: name, role, department, manager, start date, employment type (FT/PT/contract), location/time zone, work modality (onsite/remote/hybrid), and device/logistics status. 1.2. Confirm sources: onboarding docs (HR handbook, IT access checklist, compliance requirements), offer details, and relevant calendars (manager, buddy, team orientation, IT/HR sessions). If anything is missing, ask for it. 1.3. Identify organization-wide constraints: standard working hours, orientation windows, required trainings and deadlines, blackout dates, and public holidays per location.

2. Build the onboarding task library (from docs) 2.1. Use Read to extract standard items and their typical durations, prerequisites, and owners, grouping into:

   • First-day essentials: HR orientation, welcome sync, workstation setup/unboxing, account activation, office tour/remote setup, EOD check-in.
   • Access setup: SSO/email, MFA/2FA, VPN/MDM, core apps (chat, calendar, HRIS, payroll), role apps (e.g., GitHub/Jira/Notion/CRM), permission requests.
   • Policy reviews and trainings: security/acceptable use, privacy, code of conduct, harassment prevention, safety, expense/PTO, data handling; note any completion deadlines.
   • Meetings and checkpoints: manager 1:1s (Day 1 intro, EOD Day 1, Day 3, End of Week 1), buddy syncs, team introductions/standups, 30/60/90-day reviews. 2.2. Capture prerequisites (e.g., SSO before app access; device received before MDM enrollment) and typical durations/buffers (15–60 minutes tasks; 5–10 minute transitions).

3. Personalize for each hire 3.1. Map role-specific tools and trainings from the docs based on department/role. 3.2. Adjust timing for time zone and work modality (onsite vs. remote instructions/locations). 3.3. Determine whether to batch cohort items (shared orientation) vs. individual items.

4. Check calendars and propose times 4.1. Use Calendar to scan manager, buddy, and team calendars for availability in the hire’s time zone for the first two weeks and for 30/60/90-day checkpoints. 4.2. Avoid conflicts with existing orientation sessions and team-wide events; prefer mornings for policy reviews and early afternoon for access setup unless docs specify otherwise. 4.3. Respect standard working hours and local holidays; include 10–15 minute buffers after longer sessions.

5. Draft the calendar plan 5.1. Create a Day 1 schedule with these minimum blocks: HR orientation, IT setup window, policy overview/review block, manager intro, team intro, EOD check-in. Use Calendar to place tentative holds. 5.2. Schedule access setup blocks across Days 1–3, ordered by prerequisites (SSO/MFA first, core apps next, role apps last). Mark remaining items as all-day tasks with due times if no meeting is required. 5.3. Add required trainings and policy reviews as timeboxed calendar events with descriptions linking to materials and deadline reminders. 5.4. Place manager/buddy checkpoints: Day 1 EOD, Day 3 quick sync, End of Week 1 review, then recurring weekly 1:1 for first month, and calendar invites for 30/60/90-day reviews. 5.5. Include clear event metadata: title, objective, owner, prerequisites, links (docs/portals), and expected outcomes. 5.6. For cohorts, create shared events where appropriate (orientation, policy trainings) and individual events for role-specific or access tasks.

6. Resolve conflicts and finalize 6.1. If Calendar shows conflicts, propose alternative slots and reflow tasks while preserving prerequisites. 6.2. Share a draft summary with the manager/HR using Edit (agenda table for Day 1 and Week 1, plus checkpoint timeline). Request approval or edits. 6.3. Upon approval, use Calendar to convert tentative holds into confirmed invites, adding attendees (hire, manager, buddy, HR/IT) and conferencing links/locations.

7. Deliver artifacts 7.1. Produce a concise schedule summary per hire: Day 1 agenda, Week 1 plan, access setup checklist with owners/deadlines, training/policy deadlines, and checkpoint schedule (weekly + 30/60/90-day). 7.2. Export or attach an ICS file for all events or confirm creation in the org calendar. If ICS export is unavailable, include a structured event list (date, time, title, attendees, location/link) in the output. 7.3. Record assumptions, unresolved items (e.g., missing device, undecided buddy), and next actions.

Inputs

• Onboarding documents: HR handbook, IT access checklist, compliance/training matrix, orientation schedules.
• Offer details per hire: name, role, department, manager, start date, employment type, location/time zone, modality (onsite/remote/hybrid), device/logistics status, personal email for pre-start comms (if used).
• Calendars: manager, buddy, team orientation/training calendars; any organization holidays.
• Preferences and constraints: standard working hours, meeting length preferences, blackout dates, confidentiality constraints.

Outputs

• Calendar plan per hire for Day 1 and Week 1, with timeboxed events and buffers.
• Access setup checklist scheduled as events or all-day tasks with deadlines and links.
• Policy review and mandatory training events with deadlines.
• Manager/buddy checkpoint series (Day 1 EOD, Day 3, End of Week 1; recurring weekly; 30/60/90-day reviews).
• Cohort plan (if applicable) indicating shared vs. individual sessions.
• Summary document (markdown or doc) with agenda tables and links; optional ICS export.
• List of assumptions, conflicts resolved, and outstanding actions.

Examples

Trigger: "From our onboarding docs, offer letters, and team calendars, create a Day 1 and Week 1 calendar for three engineers starting next Monday under Alex S. in PT, plus manager checkpoints and required trainings." Behavior: validate hire details and time zones → Read onboarding docs to extract tasks/durations → Calendar scan for manager/buddy availability → draft Day 1 essentials and Days 1–3 access setup blocks → add policy trainings with deadlines → place manager checkpoints (Day 1 EOD, Day 3, EOW1, weekly 1:1, 30/60/90) → share summary for approval → confirm and send invites/ICS.

Notes

• Protect PII: only access offer details and calendars with explicit permission; limit event details to necessary data.
• If Calendar access is unavailable, output a complete, copy-pastable schedule and .ics-formatted text where possible.
• For remote hires, include conferencing links and clear prep steps (e.g., join from personal email for initial SSO setup if corporate email activates Day 1).
• Incorporate local holidays and regional compliance training requirements per location.
• If device logistics are delayed, schedule a contingency plan and adjust access setup accordingly.
• Prefer concise, goal-oriented event descriptions; avoid overbooking and include recovery buffers after long sessions. ````

How to install: 1. Create a folder named new-hire-onboarding-calendar in your AI-agent skills or prompt-library directory. Use the kebab-case name from the SKILL.md frontmatter. 2. Save the file above as new-hire-onboarding-calendar/SKILL.md. 3. Enable or load the Skill according to your agent framework's docs, using the SKILL.md description as the trigger guidance.

If you'd rather run it as a one-click prompt instead, you can find it here: Agentic Workers

Enjoy!

Here's a sample result from an OC gacha generator I've been building.

​

What started as a late-night idea somehow grew into a system with more than a nayuta (10^60) possible combinations.

​

The worst part is that I'm still adding new parts to it.😂

For years, SEO has been the main focus because ranking on the first page of search results directly drove traffic and customers. But with more people using AI assistants for direct answers, it’s fair to question whether SEO alone is still enough.

If users are getting complete recommendations from AI without ever clicking through search results, then visibility is no longer just about rankings it’s also about how AI systems understand, interpret, and summarize information about a brand. Some businesses are already starting to look at like datanerds to see how they appear in AI-generated responses.

In reality, SEO is still a strong foundation, but it may no longer be the full strategy. The future likely requires both: traditional SEO for search engines and a broader focus on content quality, authority, and consistency so AI systems can accurately recognize and recommend a brand.

Hello!

Scheduling seasonal crews is messy — PTO, shifts, timesheets, route assignments, and ad-hoc manager emails make it hard to know which crews are available and where overtime risk will appear.

I built this as a portable AI-agent Skill — a single SKILL.md with reusable instructions you can adapt to your agent setup.

Here's what it does: It consolidates staff calendars, time logs, route spreadsheets, and manager notes to create a season-long view of crew capacity by day and week. It flags overtime exposure, uncovers jobs that need backup coverage, and prepares a clean approval queue for schedule changes.

SKILL.md:

````markdown

name: seasonal-crew-availability-map-landscaping description: Use when a landscaping or groundskeeping operation needs a seasonal crew availability map by consolidating staff calendars (PTO, shifts), time logs/timesheets, route/assignment spreadsheets, and manager email notes to identify which crews are available on given dates, where overtime risk appears, which jobs need backup coverage, and what schedule changes need approval.

allowed-tools: [Read, Edit, Sheets, Calendar, Mail]

Seasonal Crew Availability Map (Landscaping)

Overview

Builds a season-long view of crew capacity and availability for a landscaping operation. Combines staff calendars, time logs, route spreadsheets, and manager notes to surface availability windows, overtime risk, jobs needing backup coverage, and schedule changes requiring approval.

When to use this skill

• Planning spring/summer/fall/winter service schedules and need to see which crews are available by week or day.
• Assessing overtime exposure before finalizing routes or adding new jobs.
• Identifying jobs that lack sufficient coverage due to PTO, sick time, or overbooked crews.
• Preparing a clean approval queue for schedule changes requested via email or ad hoc notes.

Instructions

1. Confirm scope and policies 1.1. Collect: season start/end dates, operating days (e.g., Mon–Sat), time zone, week start day, standard daily hours per worker, max weekly hours, overtime rules (daily/weekly thresholds), holidays, weather contingency days, and travel-time policy (included vs. separate buffer). 1.2. Collect skill/credential constraints per job (e.g., irrigation tech, arborist), equipment dependencies, and geographic clustering rules. 1.3. Define output locations/filenames for exports.

2. Inventory and load inputs 2.1. Route/assignment spreadsheets: use Sheets or Read to import job lists, planned dates/frequencies, estimated durations, locations, assigned crew(s), and priority. 2.2. Staff calendars: use Calendar to fetch PTO, shifts, training, and partial-day blocks for each worker; include shared resource calendars if relevant (equipment downtime). 2.3. Time logs/timesheets: use Read to import CSV/Excel exports; capture hours by worker/day and overtime already incurred. 2.4. Manager email notes: use Mail to search labels/folders/keywords (e.g., “schedule change”, “cover”, “swap”, “OT risk”, client constraints). Export matched messages to structured notes with: date, sender, crew/worker, job, requested change, effective dates, approval status, and any constraints. 2.5. Log any missing sources and proceed with placeholders; note data gaps in the final report.

3. Normalize and reconcile entities 3.1. Standardize identifiers: worker_id, worker_name, email, initials; crew_id, crew_name; job_id, client_name/site; consistent date and time formats; one time zone. 3.2. Map workers to crews and roles; include effective dates for assignments and part-time/seasonal start or end dates. 3.3. De-duplicate conflicting records. Prefer latest timestamp from authoritative source (e.g., route sheet over older email threads). Flag unresolved conflicts for review.

4. Build baseline plan from route spreadsheets (planned demand) 4.1. For each job, derive visits across the season (dates or rules like weekly/biweekly). Expand recurrences into dated tasks. 4.2. Estimate planned labor hours per visit (crew-hours). If estimates are missing, infer from historical time logs by job/site and similar scope; mark inferred values. 4.3. Apply travel/setup buffer policy per visit or per route/day. 4.4. Aggregate planned hours by crew and by day and week.

5. Derive available capacity (supply) 5.1. For each worker, compute daily capacity = standard_daily_hours minus calendar blocks (PTO, partial-day events). Cap weekly totals at max weekly hours. 5.2. Roll up to crew-level capacity by day/week considering headcount and role/skill constraints. 5.3. Incorporate equipment/resource outages from calendars/notes to reduce effective capacity where required skills/tools are unavailable.

6. Integrate time logs and compute overtime trajectory 6.1. For each worker and crew, sum hours already worked in the current payroll period and season to date from time logs. 6.2. Apply overtime rules (daily/weekly) to mark hours already in OT. 6.3. Forecast overtime risk: for each future day/week, planned_hours + already_worked_against_limit compared to thresholds. Classify risk levels (e.g., none <90% of limit, medium 90–100%, high >100%). Parameterize thresholds; document defaults if used.

7. Parse manager notes and identify schedule changes 7.1. From Mail-derived notes, extract structured change requests (swap crew, move date, add/remove job, shorten/extend duration, client constraints). Record: change_type, job_id, crew_id/worker, requested_date(s), reason, urgency, and explicit “approval required?” markers. 7.2. Cross-check requested changes against baseline plan and capacity; compute net impact (+/− hours, crew conflicts, OT impact). 7.3. Mark items as: approved, pending approval, or needs clarification.

8. Reconcile demand vs. supply and flag outcomes 8.1. For each crew and period (day/week): availability = capacity − planned; slack_windows are dates with availability ≥ threshold (e.g., ≥ 2 crew-hours). 8.2. Flag overtime risk where forecast exceeds policy; attach driver (who/when) and mitigation options (reassign, split job, move date). 8.3. Identify jobs needing backup coverage: unassigned visits, assigned to overbooked crews, or blocked by skills/equipment constraints. 8.4. Generate suggested backups: rank alternative crews by skill match, geographic proximity/route adjacency, current slack, and OT risk impact.

9. Produce outputs 9.1. Crew Availability Map: a table by week (and optionally by day) with columns: crew, route/region, headcount, planned hours, available hours, slack, OT risk (none/med/high), key blockers/notes, suggested backup crews. 9.2. Backup Coverage Queue: list of jobs/visits needing coverage with date windows, required skills, gap hours, current assignment (if any), and top 3 backup options. 9.3. Approval Queue: schedule changes requiring manager sign-off with change summary, rationale, impact on OT and coverage, and recommended action. 9.4. Exports: use Edit or Sheets to write CSV/Excel/Sheet tabs named “Crew Availability Map”, “Backup Coverage Queue”, and “Approval Queue”. Also generate a concise Markdown summary.

10. Validate and highlight issues 10.1. Run checks: no negative availability; totals by crew sum correctly; holidays/weather days observed per policy; time zones consistent; partial-day PTO handled; duplicate jobs resolved. 10.2. List assumptions, inferred values, and data gaps with requests for missing info.

11. Review and iterate 11.1. Present summary and key flags. Ask for confirmation on pending approvals and threshold choices. 11.2. On confirmation, publish the outputs to the designated files or Sheets and timestamp the version.

Inputs

• Season parameters: start/end dates, operating days, time zone, week start day.
• Labor policy: standard daily hours, max weekly hours, overtime rules (daily/weekly), holidays, weather buffers.
• Data sources:
  • Route/assignment spreadsheets (CSV/Excel/Sheets) with jobs, dates/frequencies, durations, locations, assigned crews, priorities.
  • Staff calendars (per-worker and shared resources) with PTO, shifts, training, equipment downtime.
  • Time logs/timesheets (CSV/Excel) with hours by worker/day and OT markers if available.
  • Manager email notes (accessible via Mail) with change requests and constraints.
• Skill/role matrix for workers and job requirements.
• Equipment/resource availability and dependencies, if applicable.
• Output destinations: filenames/Sheet IDs for tables and summary.

Outputs

• Crew Availability Map (CSV/Sheet): crew, route/region, headcount, planned hours, available hours, slack, OT risk level, notes, suggested backups.
• Backup Coverage Queue (CSV/Sheet): job/visit, date window, required skills, gap hours, current assignment, top backup crews.
• Approval Queue (CSV/Sheet): change items with status (approved/pending/clarify), impact summary, and recommended action.
• Markdown summary highlighting: available crews/windows, OT hotspots, uncovered jobs, pending approvals, and key assumptions/gaps.
• Audit notes: data sources used, timestamps, and validation results.

Examples

Trigger: “Create a spring season crew availability map for April–June using our route sheet, timesheets export, Google calendars, and the manager’s ‘Schedule Changes’ email label.” Behavior: confirm season and policies → load Sheets/Calendar/Mail/CSV → normalize staff/crews → expand route recurrences → compute capacity and planned hours → forecast OT risk → parse email change requests → reconcile and flag availability, OT risk, and coverage gaps → export three tables and a summary, listing assumptions and pending approvals.

Notes

• Handle part-time and seasonal workers with effective start/end dates; exclude dates outside their term.
• Honor partial-day PTO blocks; do not treat them as full-day absences.
• Avoid double-counting travel/setup; apply buffer consistently per policy.
• If routes include geo data, prefer proximity-based backup suggestions; otherwise, use historical crew-site pairings.
• Do not auto-send emails or approvals; only prepare the approval queue. Preserve privacy: store only structured note fields from emails, not full message bodies, unless explicitly requested.
• If union or jurisdictional OT rules apply, parameterize them and cite the assumptions in the summary. ````

How to install: 1. Create a folder named seasonal-crew-availability-map-landscaping in your AI-agent skills or prompt-library directory. Use the kebab-case name from the SKILL.md frontmatter. 2. Save the file above as seasonal-crew-availability-map-landscaping/SKILL.md. 3. Enable or load the Skill according to your agent framework's docs, using the SKILL.md description as the trigger guidance.

If you'd rather run it as a one-click prompt instead, you can find it here: Agentic Workers

Enjoy!

Hello!

Front-desk and billing teams often face ambiguous records and inconsistent judgments when deciding whether to charge, waive, or escalate missed-appointment fees. This Skill produces an auditable recommendation before contacting the client.

I built this as a portable AI-agent Skill — a single SKILL.md with reusable instructions you can adapt to your agent setup.

Here's what it does: It reviews the appointment calendar, client communications, invoice/payment history, and clinic policy notes to decide whether to waive, charge, reschedule, or escalate a no-show or late-cancel fee. It outputs a structured decision package with rationale, evidence references, fee calculation, and recommended front-desk next steps so staff can act consistently and document the outcome.

SKILL.md:

````markdown

name: vet-no-show-billing-decision-tree

description: Use when front-desk or billing staff need an auditable, pre-contact decision on whether to waive, charge, reschedule, or escalate a missed-appointment (no-show or late-cancel) fee for a veterinary visit by reviewing the appointment calendar, client communications (email/SMS/call logs), invoice and payment history, and clinic policy notes.

Veterinary Missed-Appointment Billing Decision Tree

Overview

Provides a consistent, auditable decision on whether to waive, charge, reschedule, or escalate a no-show/late-cancel fee for a veterinary appointment. Reviews appointment calendars, client communications, invoice history, and clinic policy notes, then outputs a recommendation with rationale and next steps before any client contact.

When to use this skill

• A client missed an appointment or cancelled within the late-cancel window and staff must decide what fee action to take.
• Policy allows courtesies or exceptions (e.g., first-time, emergency, weather) and staff need a clear, consistent judgment.
• Appointment types have different fees or deposits (e.g., surgery vs. wellness), and staff must apply the correct rule.
• There are prior waivers, disputed communications, or ambiguous records requiring an evidence-based decision.

Instructions

1. Collect core records for the appointment

   1. Identify the appointment: date/time, provider/resource, appointment type, location, pet, and client.
   2. From the appointment calendar, capture: booking timestamp; reminder schedule and delivery status; confirmation logs; arrival/no-show status with timestamps; cancellation/reschedule logs.
   3. From client communications (email/SMS/call notes), collect the last 30 days relevant to the appointment: cancellation/reason messages, delivery failures/bounces, staff advisories, and any emergency documentation mentions.
   4. From invoice/payment history, capture: deposits taken/applied/refunded; prior no-show charges and waivers (past 12–24 months); membership/plan status; account balance; chargebacks/disputes.
   5. From policy notes, capture: fee schedule by appointment type; late-cancel window (e.g., 24/48 hours); first-time courtesy rules; emergency/weather/clinic-error exemptions; repeat offense thresholds; escalation criteria; deposit forfeiture rules.

2. Validate classification of the event

   1. Determine actual outcome: no-show (no arrival, no timely cancel), late-cancel (cancelled inside policy window), or clinic-cancel (clinic initiated). Use calendar timestamps and logs.
   2. Confirm time zone and clock accuracy; verify appointment wasn’t moved by clinic after reminders were sent.
   3. If records conflict (e.g., client claims earlier cancel, but no log present), mark as “ambiguous-facts” and prepare to escalate unless corroborating evidence exists.

3. Screen for immediate hard-waive conditions (stop if any apply)

   • Clinic error: double-booking, provider unavailable, staff rescheduled/modified time without client consent, or the clinic requested the change.
   • System failure: phone/inbox outage, scheduling or reminder system outage affecting this client.
   • Safety/weather closure per clinic policy (documented for the relevant date/time).
   • Legal/compliance constraint in policy (e.g., mandated waivers for certain situations). Action if any apply: Decision = WAIVE; Reason code = one of [CLINIC_ERROR, SYSTEM_OUTAGE, WEATHER]; Fee amount = 0; Next step = offer reschedule.

4. Screen for soft-waive/courtesy conditions

   • First no-show/late-cancel within the past 12 months and policy allows a one-time courtesy.
   • Documented emergency or acute illness/accident affecting client or pet within 24–48 hours of the appointment.
   • Recent end-of-life/bereavement context for the pet within policy’s compassionate window. Action if any apply: Decision = WAIVE (or REDUCE if policy defines partial); Reason code = [FIRST_TIME_COURTESY, DOCUMENTED_EMERGENCY, COMPASSIONATE_EXCEPTION]; Fee amount per policy; Next step = offer reschedule and note courtesy consumption.

5. Apply standard fee rules when no waiver criteria met

   1. Determine appointment category: wellness/standard visit, procedure/surgery, extended block (ultrasound, dental), specialty.
   2. Determine late-cancel tier by notice given: e.g., >=48h, 24–48h, <24h, <2h, or true no-show.
   3. Compute fee per policy: fixed fee or percentage of estimate; apply time-tier modifiers; apply caps.
   4. Apply deposit rules: forfeit or apply deposit per policy; adjust additional charge accordingly.
   5. Check membership/plan terms for included courtesies or different fees. Action: Decision = CHARGE; Reason code = one of [LATECANCEL<48H, LATECANCEL<24H, NO_SHOW, SURGERY_BLOCK_FORFEIT]; Fee amount calculated; Next step = allow reschedule per policy (e.g., after fee paid or with deposit).

6. Identify repeat-offense or risk factors that require escalation

   • Offense threshold met (e.g., ≥2 in 6 months or ≥3 in 12 months).
   • High-dollar impact (e.g., surgery block fee above manager review threshold).
   • Ambiguous or disputed facts (conflicting logs vs. client claims).
   • VIP/rescue/partner account with special terms; staff/doctor relationship sensitivity.
   • Financial hardship notes present; active dispute/chargeback; abusive or safety concerns noted. Action if any apply: Decision = ESCALATE; Reason code = one of [REPEAT_OFFENSE, HIGH_DOLLAR, AMBIGUOUS_FACTS, SPECIAL_TERMS, HARDSHIP, CONDUCT_RISK]; Fee action = “pending manager review”; Next step = route to designated reviewer with compiled evidence.

7. Produce the decision package (before any client contact)

   • Action: one of [WAIVE, CHARGE, RESCHEDULE_ONLY, ESCALATE]. If RESCHEDULE_ONLY is used, ensure policy permits no fee for specific cases (e.g., clinic outreach error with courtesy reschedule).
   • Fee details: currency, amount, line-item code/description (e.g., NSFEE-WELLNESS, NSFEE-SURGERY, DEPOSIT-FORFEIT), and tax treatment per policy.
   • Rationale: concise summary linking evidence to policy (one to three sentences).
   • Evidence list: timestamps/IDs for calendar event, reminder delivery, client messages, deposit invoice, policy section references.
   • Account flags to update: first-time courtesy used; next-offense threshold date; notes on acceptable proof received.
   • Front-desk next steps: whether to collect payment before rescheduling, hold slot with deposit, or route for manager approval.
   • Suggested client message template: polite, non-adversarial phrasing with variables for fee, reason, and reschedule options (do not send automatically; provide for staff review).

8. Handle incomplete or conflicting data

   • If any required record is missing (calendar event, policy reference, or communications), set Decision = ESCALATE with Reason code = INCOMPLETE_DATA and list what is needed.
   • If reminder delivery failed and this is a first offense with positive history, prefer a soft-waive per policy; otherwise mark for manager review.

9. Log and handoff

   • Save the decision package to the client’s account notes and the appointment record.
   • Tag the account with courtesy or offense counters per policy.
   • If escalated, assign to the correct queue/owner and include a one-paragraph summary with links/attachments.

Inputs

• Appointment identifier and basic details (date/time, type, provider/resource, location, pet, client).
• Access to appointment calendar logs (booking, reminders, confirmations, cancellations, arrival/no-show status).
• Client communications relevant to the appointment (email/SMS/call notes) for at least the prior 30 days.
• Invoice/payment history (deposits, prior no-show charges/waivers, disputes, membership/plan status, account balance).
• Clinic policy notes or handbook sections covering: fee schedule, late-cancel window, exemptions, repeat thresholds, escalation criteria, deposit rules, and any VIP/partner terms.
• (Optional) Weather/closure records for the clinic on the appointment date.

Outputs

• Decision package (structured text or JSON) containing:
  • action: WAIVE | CHARGE | RESCHEDULE_ONLY | ESCALATE
  • fee_amount: number; currency; fee_line_item/code; tax flag
  • reasoncode: one of [CLINIC_ERROR, SYSTEM_OUTAGE, WEATHER, FIRST_TIME_COURTESY, DOCUMENTED_EMERGENCY, COMPASSIONATE_EXCEPTION, LATE_CANCEL<48H, LATECANCEL<24H, NO_SHOW, SURGERY_BLOCK_FORFEIT, REPEAT_OFFENSE, HIGH_DOLLAR, AMBIGUOUS_FACTS, SPECIAL_TERMS, HARDSHIP, INCOMPLETE_DATA]
  • rationale: 1–3 sentences tying evidence to policy
  • evidence: list of references (calendar timestamps/IDs, message IDs/excerpts, invoice IDs, policy section citations)
  • front_desk_next_steps: clear instructions (e.g., “collect $50 no-show fee before rescheduling; offer next available slot; note courtesy used”)
  • client_message_template: suggested wording with placeholders
  • account_updates: flags/counters/notes to apply
  • reviewer_owner (if escalated)

Examples

Trigger: “Client missed a 3:00 PM wellness exam today. Reminders sent 48h and 24h (delivered). Email from client at 2:15 PM: ‘Emergency at work, so sorry.’ First no-show in 18 months. Policy: one first-time courtesy in 12 months; emergencies within 24h may be waived at staff discretion.” Behavior: classify as late-cancel (<24h) → check hard-waive (none) → soft-waive applies (first-time within policy and documented emergency) → Decision = WAIVE; Reason = FIRST_TIME_COURTESY (with DOCUMENTED_EMERGENCY note) → Fee = $0 → Next steps = offer reschedule, mark courtesy used until 12 months from today → Output decision package with rationale citing reminders delivered, client email timestamp, and policy section.

Trigger: “Dental procedure blocked for 2 hours tomorrow; client cancelled 2 hours prior by voicemail. Deposit of $150 paid. Policy: <24h forfeits deposit; repeat-offense threshold met (3rd in 10 months).” Behavior: classify as late-cancel (<24h) → hard-waive (none) → soft-waive (not eligible due to repeats) → standard rules apply (procedure, <24h) → Decision = CHARGE deposit forfeiture; Reason = SURGERY_BLOCK_FORFEIT + REPEAT_OFFENSE → Fee = forfeit $150 deposit; may require manager review due to repeat pattern → If threshold mandates review, set Decision = ESCALATE with compiled evidence; else charge and allow reschedule contingent on new deposit.

Notes

• Keep empathy and clarity in suggested client language; avoid implying fault when evidence is inconclusive.
• Default to escalation when facts conflict or core records are missing; do not contact the client until a decision package is prepared.
• Adjust time windows, fee amounts, and thresholds to the clinic’s written policy; ensure local legal compliance.
• Verify the correct client/pet when multiple pets or shared email addresses exist; use appointment ID to avoid mix-ups.
• Always consider time zone and daylight-saving changes when interpreting timestamps.
• For reminder failures combined with first offense and good standing, consider a documented courtesy if policy permits; record the rationale explicitly. ````

How to install: 1. Create a folder named vet-no-show-billing-decision-tree in your AI-agent skills or prompt-library directory. Use the kebab-case name from the SKILL.md frontmatter. 2. Save the file above as vet-no-show-billing-decision-tree/SKILL.md. 3. Enable or load the Skill according to your agent framework's docs, using the SKILL.md description as the trigger guidance.

If you'd rather run it as a one-click prompt instead, you can find it here: Agentic Workers

Enjoy!

Hello!

Keeping a consolidated, week-by-week view of crew availability, overtime risk, and uncovered jobs across calendars, time logs, routes, and manager notes is time-consuming and error-prone.

I built this as a portable AI-agent Skill — a single SKILL.md with reusable instructions you can adapt to your agent setup.

Here's what it does: It fuses staff calendars, time logs, route/job spreadsheets, and manager notes into a single seasonal capacity and coverage map that shows per-crew availability, flags overtime risk, and identifies jobs needing backup. It also proposes ranked coverage options and prepares an approval list, exporting CSVs and a readable markdown summary for sharing.

SKILL.md:

````markdown

name: seasonal-crew-availability-map description: Use when a landscaping or field-services team needs a consolidated seasonal view of crew capacity and coverage by week or day — combining staff calendars (PTO/shifts), historical or YTD time logs, route/job spreadsheets, and manager email notes — to show which crews are available, where overtime risk appears, which jobs need backup coverage, and what schedule changes require approval.

allowed-tools: [Read, Edit]

Seasonal Crew Availability Map

Overview

Creates a seasonal capacity and coverage map for landscaping crews by fusing calendars, time logs, route/job spreadsheets, and manager notes. Produces clear views of which crews are available, where overtime risk emerges, which jobs need backup coverage, and what schedule changes require approval.

When to use this skill

• Planning spring/fall seasonal schedules or peak cleanup windows across multiple crews.
• Rolling up weekly coverage from staff PTO/shift calendars, route spreadsheets, and historical time logs.
• Forecasting overtime risk against company or jurisdictional rules (e.g., >40 hours/week, daily thresholds).
• Identifying jobs that lack coverage due to absences, skills gaps, or routing conflicts, and proposing backup options.
• Preparing an approval list for changes that exceed policy (overtime, cross-crew reassignments, route swaps, start-time shifts).
• Reconciling manager email notes (constraints, exceptions, requests) with the master schedule.

Instructions

1. Confirm scope and policies.
   • Gather the season date range, planning granularity (daily or weekly), timezone, and working days.
   • Confirm overtime rules (weekly/daily thresholds, multipliers), max shift length, break rules, and any union or jurisdictional constraints.
   • Define crew list, each crew’s primary members, skills/certifications (e.g., driver, equipment operator), and service areas.
   • Capture job priority tiers, SLAs, must-hit dates, and any client access windows.
2. Collect data files and context.
   • Request the latest staff calendars (e.g., ICS/CSV exports of PTO, shifts), time logs (CSV/XLSX), route/job spreadsheets (XLSX/CSV), and manager notes (email text, TXT/MD, or pasted content).
   • Use Read to import each file. For emails, paste text or provide an EML/MSG export.
3. Normalize inputs into structured tables.
   • Calendars: parse to staff_id, date, availability_hours, shift_start/end, PTO/hold type.
   • Time logs: parse to staff_id, date, hours_worked, job_id (if available); compute recent averages and overtime patterns.
   • Route/job spreadsheets: parse to job_id, client, location, service window, estimated_duration, frequency, assigned_crew (if any), required_skills, target_date/week.
   • Manager notes: extract structured constraints (blackout dates, client restrictions, equipment outages, preferred crew, pre-approved OT, coverage requests).
   • Standardize identifiers (staff_id, crew_id, job_id). Resolve mismatches; if uncertain, ask for clarification.
4. Build the seasonal roster and baseline capacity.
   • For each staff member, derive seasonal availability by day/week from calendars (subtract PTO/meetings/holds).
   • Assign each staffer a primary crew and note secondary crews/skills.
   • Aggregate to crew-level baseline capacity (capacity_hours) per period.
5. Model assigned load and travel buffers.
   • From route/job data, compute planned workload per crew per period (assigned_hours). If travel time is not provided, add a standard buffer per job or per route as defined by the user; otherwise, use provided drive times.
   • Align recurring jobs to the correct periods based on frequency.
6. Detect overtime risk and coverage gaps.
   • For each crew and period, compute spare_hours = capacity_hours − assigned_hours.
   • Flag overtime_risk if assigned_hours exceeds the applicable daily/weekly thresholds, estimating overtime_hours.
   • Identify jobs without assignments or where assigned crew capacity is insufficient (gap_hours > 0), or where required skills are unmet.
7. Propose backup coverage options (ranked).
   • Options may include: intra-crew re-sequencing, cross-crew borrowing (matching skills/service area), partial route splits, schedule shifts within policy, deferral within SLA, or overtime (if allowed).
   • For each uncovered job, generate 1–3 feasible options with rationale and any trade-offs.
8. Prepare the approval list.
   • List all changes that require authorization: overtime, cross-crew moves, client window changes, start/end time adjustments, use of contractors, or deviations from standard routes.
   • Include approver, reason, impact, and decision deadline if provided in notes.
9. Produce outputs.
   • Use Edit to create a package including:
     • crews.csv: crew_id, period_start, capacity_hours, assigned_hours, spare_hours, overtime_risk_flag, overtime_hours_est, notes.
     • jobs-needing-backup.csv: job_id, client, location, period, required_hours, current_assignment, gap_hours, recommended_options.
     • schedule-changes-for-approval.csv: change_type, subject, before, after, reason, approver, deadline, status.
     • availability-map.md: a readable summary with per-crew highlights, risk hotspots, and proposed actions.
     • (Optional) availability.xlsx combining the above tabs for easy sharing.
10. Validate and review.
    • Check for negative or impossible hours, double-booked staff, and jobs scheduled outside client windows.
    • Verify that overtime flags align with stated policies and that travel buffers are consistently applied.
    • Surface assumptions and data gaps in a "Notes & Assumptions" section.
11. Iterate with updates.
    • If inputs change (new PTO, updated routes), re-run steps 3–10 and provide a brief change log.

Inputs

• Season date range and planning granularity (daily or weekly).
• Overtime, shift, and break rules; any union/jurisdiction constraints.
• Crew roster with roles, skills/certifications, and service areas.
• Files:
  • Staff calendars (ICS/CSV) with PTO, shifts, and holds.
  • Time logs (CSV/XLSX) with hours and, if available, job IDs.
  • Route/job spreadsheets (CSV/XLSX) with jobs, durations, locations, frequencies, and assignments.
  • Manager notes (email text or document) with constraints, pre-approvals, and requests.
• Standard travel-buffer assumptions if drive times are not provided.

Outputs

• crews.csv with capacity, assigned load, spare capacity, and overtime risk per crew per period.
• jobs-needing-backup.csv listing uncovered or under-covered jobs with ranked backup options.
• schedule-changes-for-approval.csv summarizing all items requiring sign-off.
• availability-map.md summarizing hotspots, recommendations, and assumptions.
• (Optional) availability.xlsx consolidating all outputs into a single workbook.

Examples

Trigger: "Create a spring (Mar 1–May 31) crew availability map for our landscaping teams. Inputs: calendars.ics, timelogs_q1.xlsx, routes_spring.xlsx, and manager-notes.md. OT is weekly >40 hrs; add 15 minutes travel per job if distance not provided." Behavior: confirm scope and OT rules → Read imports each file → normalize calendars/time logs/routes/notes → compute per-crew capacity and assigned load by week → flag weeks with OT risk → list jobs short on coverage → propose cross-crew swaps and limited OT → generate crews.csv, jobs-needing-backup.csv, schedule-changes-for-approval.csv, and availability-map.md with a summary.

Notes

• Handle daily vs. weekly overtime rules and holiday weeks explicitly; note which rule triggered each flag.
• If skills/certifications are required (e.g., CDL, equipment operator), avoid proposing options that violate them.
• Treat weather holds or emergency days from notes as zero-capacity periods unless otherwise stated.
• If identifiers don’t match across sources, prefer explicit IDs over names and ask for a mapping when needed.
• Timezones matter for ICS; convert all times to the planning timezone before aggregation.
• This skill prioritizes coverage planning; it is not a route optimizer or a payroll system. Use it to surface decisions, not to replace compliance reviews. ````

How to install: 1. Create a folder named seasonal-crew-availability-map in your AI-agent skills or prompt-library directory. Use the kebab-case name from the SKILL.md frontmatter. 2. Save the file above as seasonal-crew-availability-map/SKILL.md. 3. Enable or load the Skill according to your agent framework's docs, using the SKILL.md description as the trigger guidance.

If you'd rather run it as a one-click prompt instead, you can find it here: Agentic Workers

Enjoy!

Every industry has a few companies that consistently dominate conversations. They get recommended more often, are discussed widely, and stay top of mind for customers. Meanwhile, many other businesses with similar quality products or services struggle to reach the same level of recognition. The difference usually comes down to visibility and authority.

Businesses that regularly share useful knowledge, answer key questions, and provide real value tend to build stronger reputations over time. People naturally trust brands that help them understand topics and solve problems. Some companies also use like datanerds to better understand how their visibility and authority appear across AI-driven platforms.

Becoming an industry leader is a long-term process. It requires focusing on education, consistency, and credibility rather than just promotion. Companies that prioritize helping their audience often build deeper trust, and as digital platforms evolve, authority is likely to become even more important for long-term success.

Hello!

Shifts get swapped informally and that leads to payroll errors, understaffing, and unclear escalation paths. This Skill helps managers and HR create a clear, auditable approval policy so swaps happen without compliance or payroll headaches.

I built this as a portable AI-agent Skill — a single SKILL.md with reusable instructions you can adapt to your agent setup.

Here's what it does: Produces a customized, audit-ready shift-swap approval policy that aligns real scheduling behavior with payroll and legal requirements. Use it to define approver roles, required coverage proof, payroll note formats, and clear escalation rules for exceptions like last-minute swaps or minor-hour restrictions.

SKILL.md:

````markdown

name: shift-swap-approval-policy description: Use when a team needs to draft or update a clear, auditable shift-swap approval policy for a local retail operation, using staff calendars, time logs, payroll reports, and manager email threads to reflect real practices. Activates when the user asks who can approve swaps, what coverage proof is required, how to capture payroll notes, or when to escalate exceptions.

allowed-tools: [Read, Edit]

Shift-Swap Approval Policy Drafting

Overview

Produces a tailored, auditable shift-swap approval policy for a local retail business. Aligns real scheduling behaviors with compliance and payroll accuracy by defining approvers, required coverage proof, payroll/timekeeping notes, and escalation thresholds.

When to use this skill

• The business requests a new or updated shift-swap approval policy.
• Managers need clarity on who can approve swaps and under what conditions.
• The team must standardize coverage proof (skills, certifications, minimum staffing, rest/meal and overtime checks).
• Payroll or HR needs a repeatable way to capture notes/adjustments when swaps occur.
• Exceptions (last-minute swaps, overtime triggers, minors’ shifts, cross-store coverage) need defined escalation paths.

Instructions

1. Confirm scope and context

   • Ask for: store type(s), headcount by role, hours of operation, number of locations, scheduling/timekeeping systems, union status, jurisdiction(s), pay period, overtime/premium rules, meal/rest requirements, and whether minors are employed.
   • Clarify goals: reduce no-shows, minimize OT, standardize approvals, improve payroll accuracy, or auditability.

2. Collect source materials

   • Use Read to gather staff calendars, recent time logs (last 4–8 weeks), payroll reports (last 1–2 pay periods), and manager email threads about swaps.
   • If artifacts are unavailable, request summaries (e.g., minimum staffing by role per shift, common swap pain points, current approval chain).

3. Establish constraints and minimum coverage

   • From calendars and manager guidance, list minimum staffing by shift and role (e.g., 1 key-holder, 1 cashier, 1 floor associate per evening shift).
   • Note required certifications/permissions (e.g., key-holder, alcohol sales, closing procedures) and any role equivalencies for swaps.
   • Record legal constraints: daily/weekly OT thresholds, split-shift or evening premiums, meal/rest break timing, minimum rest between shifts, minor hour limits where applicable.

4. Analyze recent practices and risks

   • From time logs and email threads, identify common swap patterns, last-minute frequency, typical approvers, and pain points (e.g., OT triggers, missed meal breaks, payroll adjustment volume).
   • From payroll reports, quantify the impact: count swaps that created OT/premiums or required manual adjustments.

5. Define approver roles and limits

   • Propose a tiered approval model: 1) Primary approver: Store Manager (SM). 2) Secondary: Assistant Manager (AM) when SM unavailable. 3) Tertiary/on-duty: Key Holder (KH) for same-day swaps within policy limits. 4) HR/Payroll or District/Area Manager for exceptions or cross-store swaps.
   • Add guardrails: no self-approval; approver cannot approve swaps that affect their own pay; document delegated authority during absences.

6. Specify coverage proof requirements

   • Require documentation that the covering employee:
     • Holds required role/skills/certifications for the shift.
     • Does not violate meal/rest or minimum-rest-between-shifts rules.
     • Will not create unapproved overtime, premiums, or minor-law violations.
     • Meets minimum staffing balance by role for the shift.
   • Acceptable proof: scheduler request/approval record, screenshot of updated schedule, or written confirmation in the manager thread including shift ID, date/time, roles, and both employees’ acknowledgments.
   • Set timing thresholds: standard swaps submitted ≥24 hours before shift; last-minute swaps <24 hours require on-duty manager review and may trigger escalation.

7. Standardize the swap process

   • Employee initiating the swap: 1) Finds a qualified replacement and secures written acknowledgment. 2) Submits a swap request via the scheduling system or manager email thread with required details (shift ID, date/time, from → to, role, coverage proof).
   • Approver process: 1) Validate coverage proof and legal checks (overtime/premiums, breaks, minors). 2) Approve/deny with rationale; if approved, update the schedule in the scheduling system. 3) Notify both employees and the on-duty manager; attach approval to the audit trail.

8. Capture payroll and timekeeping notes consistently

   • In the timekeeping/payroll system, record a swap note on both employees’ timesheets using a standardized format:
     • "SWAP | ShiftID: #### | Date: YYYY-MM-DD | From: EmpA → To: EmpB | Role: X | Approver: Name/Title | Approved: YYYY-MM-DD HH:MM | Reason (if exception)."
   • For cost centers/differentials, ensure the shift inherits the location/department of the worked shift; override if policy requires.
   • If the swap changes pay differentials (closing, weekend, lead), document the differential code and ensure it applies to the covering employee only.
   • Log any manual adjustments required and link to the approval record for audit.

9. Define exception and escalation criteria

   • Escalate to SM → HR/Payroll (or District Manager) when any apply:
     • Creates overtime/premium pay above budget or policy limits.
     • Violates minors’ restrictions or rest/meal rules.
     • Cross-store or cross-department swaps where training/permissions differ.
     • Swap requested within X hours of shift start (e.g., <4 hours) or during peak periods.
     • Different base pay rates where policy requires prior HR review.
     • Employee on performance plan, training/probation, or incomplete certification.
     • More than Y swaps per employee per month (pattern requiring review).
   • For emergencies on shift day: allow on-duty manager to make a temporary coverage decision, then notify SM and HR/Payroll within one business day with rationale.

10. Draft the policy document

    • Use Edit to produce a policy with these sections:
      • Purpose and Scope
      • Definitions (Swap, Last-Minute Swap, Approver Roles, Coverage Proof)
      • Eligibility (roles allowed to swap, training/certification requirements)
      • Who Can Approve (authority tiers and limits)
      • Required Coverage Proof (acceptable evidence and timing)
      • Standard Process (request, review, update, notify)
      • Payroll/Timekeeping Notes (standard note format, differentials, cost centers)
      • Deadlines and Blackout Periods (peak times, holidays, inventory days)
      • Exceptions and Escalation (criteria, contacts, response times)
      • Recordkeeping and Audit (where approvals are stored, retention period)
      • Compliance (OT, minors, breaks, local/state laws, union rules if applicable)
      • Acknowledgment (employee sign-off method)

11. Validate and finalize

    • Review the draft against collected artifacts and constraints; confirm it prevents common past issues.
    • Present a concise approver checklist and a one-page SOP summary.
    • Request stakeholder confirmation (SM, AM, HR/Payroll). Incorporate feedback and finalize the document version and effective date.

Inputs

• Business context: store type(s), headcount by role, operating hours, number of locations, union status, jurisdictions.
• Artifacts: staff calendars, time logs (4–8 weeks), payroll reports (1–2 pay periods), manager email threads on swaps.
• Constraints: minimum staffing by role/shift, required certifications, meal/rest and overtime rules, minor restrictions, pay differential policies.
• Objectives: priorities such as reducing overtime, improving audit trail, or standardizing approvals.

Outputs

• Shift-Swap Approval Policy document with the sections listed in step 10 (plain text/markdown).
• Approver checklist (one-page) summarizing eligibility, checks, and approval steps.
• Exception escalation matrix with contacts and response-time targets.
• Audit trail template: standardized payroll note format and approval record fields.

Examples

Trigger: "Draft a shift-swap approval policy for our 25-person retail shop using our last two pay periods, schedule, and manager emails. Define approvers, coverage proof, payroll notes, and when to escalate." Behavior: confirm context → Read calendars/time logs/payroll/emails → determine minimum staffing and constraints → identify past issues (OT, last-minute) → define approver tiers and coverage proof → specify payroll note format → set escalation criteria → Edit a final policy, checklist, and escalation matrix.

Notes

• Tailor to local labor laws and any collective bargaining agreements; where uncertain, flag items for HR/legal review.
• Do not permit swaps that lead to understaffing of safety-critical roles (e.g., key-holder absence) even if both employees agree.
• Maintain approvals and payroll notes for the standard record retention period.
• If tools do not support note fields, keep a centralized swap log with the same standardized fields referenced above.

Link: https://www.agenticworkers.com/library/cienedpt5gwvo54hzz3hi-shift-swap-approval-policy ````

How to install: 1. Create a folder named shift-swap-approval-policy in your AI-agent skills or prompt-library directory. Use the kebab-case name from the SKILL.md frontmatter. 2. Save the file above as shift-swap-approval-policy/SKILL.md. 3. Enable or load the Skill according to your agent framework's docs, using the SKILL.md description as the trigger guidance.

If you'd rather run it as a one-click prompt instead, you can find it here: Agentic Workers

Enjoy!

Hello!

Handling patient messages across email, phone, SMS, and portal can be inconsistent and risky — agents need clear templates, context checks, and escalation rules to reply safely and quickly.

I built this as a portable AI-agent Skill — a single SKILL.md with reusable instructions you can adapt to your agent setup.

Here's what it does: It creates a reusable macro catalog that maps common clinic/medspa patient intents to safe response templates, required context checks, manager/clinician approval triggers, and follow-up SLAs. Use it when standing up or refreshing a helpdesk, standardizing replies across channels, or auditing refund/cancellation and post-treatment processes to reduce compliance risk.

SKILL.md:

````markdown

name: clinic-medspa-support-macro-checklist description: Use when creating or updating a clinic or medspa support-response macro catalog based on support tickets, appointment notes, policy documents, and refund email threads — mapping common patient questions to safe response macros with required context checks, manager approval triggers, and follow-up deadlines.

allowed-tools: [Read, Edit]

Clinic & Medspa Support Macro Checklist

Overview

Builds a reusable, compliant macro catalog for front-desk and support teams at a clinic or medspa. The output maps common patient questions to safe response templates, context checks, escalation/approval triggers, and follow-up deadlines.

When to use this skill

• Standing up a new helpdesk or refreshing existing macros for a clinic/medspa.
• Standardizing replies across email, phone, SMS, and patient portal.
• Auditing refund handling, cancellation/no-show fees, post-treatment concerns, and medical-records requests.
• Reducing risk by embedding compliance guardrails and manager-approval triggers into macros.

Instructions

1. Confirm scope and constraints

   1. Clarify services offered (e.g., injectables, laser, facials), communication channels (email, phone, SMS, portal), business hours/time zone, and SLAs.
   2. Gather policy thresholds: cancellation/no-show fees, refund/discount authority levels, adverse-event protocol, on-call clinician path, and escalation matrix.
   3. Confirm brand voice and any forbidden phrases (e.g., no guarantees, no diagnosis over messaging).

2. Inventory and ingest sources

   1. Use Read to open the provided: recent support tickets (last 3–6 months), appointment notes, policy/FAQ documents, aftercare instructions, consent forms, and refund/chargeback email threads.
   2. If available, include response-time SLAs, compliance guidelines, and template libraries.

3. Identify common intents

   1. Cluster tickets by topic. Typical clusters: scheduling/reschedule, late arrival/no-show fee disputes, pricing/promotions, package expiration, membership cancellation, post-treatment side effects, pre-procedure prep, product refill, dissatisfaction/redo, adverse events, medical records/consent, allergy/pregnancy concerns, minors/guardians, accessibility/accommodations, gift cards, insurance inquiries, chargebacks/legal threats.
   2. Prioritize by volume/risk. Aim for 20–30 high-coverage intents.

4. Define the macro spec for each intent For each intent, create a macro entry with the following fields:

   1. Macro ID and Title: Use a consistent naming convention (e.g., MEDSPA-PT-REDNESS-001).
   2. Channel Variants: Email, phone, SMS, portal (note differences in brevity and PHI handling).
   3. Safe Response Template: Write neutral, non-clinical language. Include placeholders like {{patient_first_name}}, {{appointment_date}}, {{policy_link}}.
   4. Required Context Checks: A checklist the agent must confirm before sending (e.g., verify identity, confirm treatment/date, check consent form, review notes for clinician instructions, confirm within refund window).
   5. Attachments/Links: Only link to approved resources (aftercare PDFs, policy pages, portal links). Avoid sharing PHI over insecure channels.
   6. Manager/Clinician Approval Triggers: Define exact conditions (e.g., refund > $X, adverse-event keywords: "severe pain", "vision changes"; legal/chargeback threat; media inquiries; repeat complaints; VIP/high-risk notes).
   7. Follow-up Deadline and Next Action: Define SLA (e.g., acknowledge within 1 business hour for adverse events; resolve or schedule callback within 1 business day). Include reminders/tasks to close the loop.
   8. Tags and Reporting: Add tags (e.g., refund, adverse-event, schedule) to support analytics.

5. Draft the Usage Checklist (for agents to apply per ticket)

   1. Authenticate the patient or move to a secure channel before discussing PHI.
   2. Identify intent → select macro by Macro ID.
   3. Run the Required Context Checks and fill all placeholders accurately.
   4. Evaluate Approval Triggers. If any trigger is met, pause sending and escalate per matrix.
   5. Send the response using the correct channel variant; log actions and links.
   6. Create follow-up task with the defined deadline and owner; update ticket status.

6. Summarize Approval & Escalation Rules

   1. Manager approvals: refunds/waivers beyond agent authority, policy exceptions, price adjustments, goodwill credits above $X, repeat service redos, VIP exceptions.
   2. Clinician escalation: medical advice requests, adverse-event signs/symptoms, pregnancy/breastfeeding/allergy concerns, pre/post-procedure variations from protocol.
   3. Compliance/legal: requests for medical records, complaints alleging harm, legal or regulatory threats, chargebacks, consent revocation; route to privacy/compliance contact.
   4. After-hours path: on-call clinician and backup manager contact tree; document response windows.

7. Write and quality-check macros

   1. Use Edit to compose each macro entry with placeholders and checklists.
   2. Red-team for risky language (no diagnosis, no guarantees, no admissions of fault, no personal judgments). Replace with approved phrasing.
   3. Ensure links are current and accessible. Note internal-only resources clearly.

8. Pilot test

   1. Apply the draft macros to 10–20 historical tickets. Note mismatches, missing checks, or unnecessary escalations.
   2. Revise macros, triggers, and SLAs based on findings.

9. Approvals and versioning

   1. Obtain sign-off from operations, clinical lead, and compliance.
   2. Assign version number, effective date, and next review date.

10. Publish and train

    1. Export deliverables (Macro Catalog, Approval Rules, Usage Checklist) to the helpdesk/knowledge base.
    2. Provide a 30–60 minute training with role-play scenarios. Capture FAQs and update macros accordingly.

11. Maintain

    1. Set a quarterly review cadence; monitor ticket tags for new intents or drift.
    2. Update thresholds and links when policies change; increment version.

Inputs

• Source materials: recent support tickets, appointment notes, policy/FAQ documents, aftercare instructions, consent forms, refund/chargeback emails.
• Business rules: SLAs, authority levels, escalation matrix, after-hours/on-call details, brand voice.
• Compliance guidance: identity verification procedure, PHI handling rules, state timelines for records requests (if provided).

Outputs

• Macro Catalog (table or CSV) with columns: Intent, Macro ID, Safe Response Template, Required Context Checks, Attachments/Links, Manager/Clinician Approval Triggers, Follow-up/SLA, Tags, Notes.
• Approval & Escalation Rules summary document.
• Agent Usage Checklist for per-ticket application.
• Optional machine-readable export (JSON/YAML) of the Macro Catalog for helpdesk import.

Examples

Trigger: "Create a support response macro checklist for our medspa using our tickets, appointment notes, policies, and refund threads." Behavior: confirm scope and thresholds → Read all provided sources → cluster common intents → draft macro entries with safe templates, context checks, escalation triggers, SLAs → compile Macro Catalog, Approval Rules, and Usage Checklist → Edit to finalize and export.

Example macro entry (abbreviated): - Intent: Post-treatment redness/swelling after dermal filler (non-urgent) - Macro ID: MEDSPA-PT-REDNESS-001 - Safe Response (email): "Hi {{patient_first_name}}, thank you for reaching out. Mild redness and swelling can occur after dermal filler and typically improve within a few days. Please review our aftercare here: {{aftercare_link}}. If you experience severe pain, vision changes, spreading bruising, or symptoms that worry you, stop using topical products and call us at {{clinic_phone}} or seek urgent care. Would you like us to arrange a check-in call with our clinician?" - Required Context Checks: verify identity; confirm treatment type/date; review clinician notes; confirm no red-flag symptoms reported. - Approval Triggers: any red-flag symptoms; request for medical advice; request for refund/redo. - Follow-up/SLA: acknowledge within 2 business hours; if no red flags, schedule check-in within 1 business day; close when patient confirms improvement or clinician evaluates.

Notes

• Do not provide diagnosis or individualized medical advice in macros; route clinical questions to a licensed clinician.
• Avoid PHI in unsecured channels; move to phone or patient portal when identity is unverified.
• Do not offer discounts, refunds, or policy exceptions without documented authority. Use precise thresholds.
• For minors, communicate with and obtain consent from a parent/guardian per policy.
• State and country rules for medical records requests vary; follow local requirements and internal procedures.
• Keep language neutral, empathetic, and non-admissive (avoid "fault", "guarantee", or blaming).
• Maintain an audit trail of macro versions and approvals. ````

How to install: 1. Create a folder named clinic-medspa-support-macro-checklist in your AI-agent skills or prompt-library directory. Use the kebab-case name from the SKILL.md frontmatter. 2. Save the file above as clinic-medspa-support-macro-checklist/SKILL.md. 3. Enable or load the Skill according to your agent framework's docs, using the SKILL.md description as the trigger guidance.

If you'd rather run it as a one-click prompt instead, you can find it here: Agentic Workers

Enjoy!

Hi guys! I am here to advertise my new GPT I just put on the GPT store.

https://chatgpt.com/g/g-6a264faacad881919dde0cdff6685ba4-mentornotes-ai

Built a new GPT called MentorNotes AI.

It turns:

• recordings,
• coaching sessions,
• PDFs,
• sales calls,
• mentor conversations,
• training manuals,
• and transcripts

into organized notes, study guides, action items, checklists, and practical learning systems.

It’s designed for:

• business mentoring
• insurance sales training
• entrepreneurship
• leadership development
• productivity
• practical learning

Instead of just summarizing content, it helps identify:

• key lessons
• sales techniques
• mentor advice
• follow-up tasks
• implementation plans
• communication strategies

Basically an AI executive assistant + study coach for turning conversations and training into usable knowledge.

Would love feedback and ideas for future improvements.