u/CalendarVarious3992

Your support queue may contain requests for work your product was never designed to do. Some are edge cases. Others point to a recurring adjacent job, such as approval routing, reporting, migration, or compliance evidence. An agent can group those requests, but frequency does not prove a second product should exist. The task is to turn support evidence into testable hypotheses without confusing repeated requests with willingness to pay.

This workflow helps teams find patterns, trace source conversations, and decide what to validate.

A useful checklist from the guide:

• Support tickets or conversations with stable IDs and timestamps
• Existing issue categories, product areas, and resolution codes
• Account metadata limited to useful fields such as plan, industry, or tenure
• Product scope and current roadmap definitions
• Links to source tickets so every cluster can be audited

https://www.agenticworkers.com/blog/what-support-requests-reveal-about-your-next-product

Tailoring one resume is manageable. Tailoring it for ten different roles is where files multiply, verified details drift, and old mistakes return.

A safer approach is to treat resume writing as a controlled system:

• keep one master career file;
• give every achievement an evidence ID;
• map job requirements to that evidence;
• stop for factual questions before drafting;
• review truth, ownership, privacy, relevance, writing quality, and delivery separately.

Here is the compact prompt pattern from the workflow:

Run a controlled resume-tailoring workflow using verified evidence only.

1. Extract the 6 to 10 most important job requirements.
2. Map each requirement to evidence IDs.
3. Label each one supported, partial, or unsupported.
4. Stop for factual questions about ownership, scope, dates, tools, and outcomes.
5. Draft only after those questions are answered.
6. Add evidence IDs beside every internal draft claim.
7. Review truth, ownership, privacy, relevance, writing quality, and delivery accuracy.
8. Produce the clean application copy only after human approval.

Never invent employers, titles, dates, credentials, metrics, responsibilities, or outcomes.

The main idea is simple: drafting language can change, but the claims cannot outrun the evidence.

https://www.agenticworkers.com/blog/how-to-build-a-resume-system-with-agentic-workers

Hello!

Managing a busy delivery fleet means juggling odometer logs, inspection findings, invoices, and route commitments — it's hard to know which vehicles need urgent attention. This Skill turns those scattered records into a single, auditable exception register so dispatchers can make safe, timely decisions.

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: This Skill consolidates odometer logs, repair invoices, inspection forms, driver notes, and route schedules to identify overdue or at-risk maintenance, assign risk levels (High/Medium/Low), and draft a Fleet Maintenance Exception Register with recommended actions and a human decision field. Use it when you're asked which vehicles are overdue, have safety findings, or need prioritized maintenance before scheduling — it also prepares dispatcher escalation packets and a tentative service schedule.

SKILL.md:

---
name: fleet-maintenance-exception-register
description: Use when a delivery, logistics, or fleet office manager needs to consolidate odometer logs, repair invoices, inspection forms, driver notes, and route schedules to identify overdue or at-risk maintenance, draft a fleet exception register, group vehicles by risk level, and escalate safety or downtime decisions to a dispatcher before scheduling service.
allowed-tools: [Read, Edit]
---

# Fleet Maintenance Exception Register

## Overview
Creates a single, auditable exception register for a vehicle fleet by consolidating maintenance-relevant inputs. Identifies overdue or at-risk maintenance, assigns risk levels, prepares dispatcher escalations for safety and downtime decisions, and proposes a service scheduling plan.

## When to use this skill
- The office manager asks which vehicles are overdue for service or inspections.
- There are new inspection findings or driver notes indicating possible safety issues.
- Weekly planning or midweek triage requires a prioritized maintenance list and dispatcher decisions before scheduling.
- The fleet needs a single view with per-vehicle source mileage, due services, risk flags, recommended actions, and a human decision field for accountability.

## Instructions
1. Confirm scope and policies
   1.1. Confirm fleet roster (vehicle ID, plate, VIN, class) and the time window to analyze.
   1.2. Confirm maintenance policies and intervals (e.g., oil/filter every N miles or M months; PM A/B/C; DOT annual; emissions; brake/tires checks) and any OEM-specific intervals.
   1.3. Define thresholds for “Due Soon” (e.g., within 500–1,000 miles or 15–30 days) and “Overdue” (past due date/mileage). Record these in an Assumptions log.

2. Ingest sources
   2.1. Use Read to extract data from: odometer logs, repair invoices, inspection forms, driver notes, and route schedules.
   2.2. Capture for each vehicle: latest odometer reading with date and source; last service date/type; parts replaced; open defects and severity; driver-reported issues; upcoming route windows/assignments; warranty or contract constraints.

3. Normalize and reconcile
   3.1. Standardize units (miles vs km), date formats, and vehicle identifiers; map aliases to canonical IDs.
   3.2. Deduplicate entries; prefer the most recent dated reading for mileage.
   3.3. Resolve conflicts (e.g., decreasing mileage) by flagging as data issues and noting the chosen source. Do not invent values.

4. Determine due services
   4.1. For each service category (e.g., oil/filter, tire rotation, brake inspection, transmission, coolant, PM levels, DOT annual, emissions), compute next-due mileage and/or date using last service data and the confirmed intervals.
   4.2. If an interval is unknown, request it or mark the service as "Interval needed" and exclude from overdue calculations until provided.

5. Identify exceptions
   5.1. For each vehicle, compare current mileage/date against computed due points to classify statuses: Overdue, Due Soon, or OK by service.
   5.2. Flag Safety-Critical when inspection findings or driver notes indicate brakes, steering, tires, lights, leaks, or other critical defects; include references to the source lines.
   5.3. Flag Downtime Risk using a combination of: number of open defects, repeat repairs, parts on order, and upcoming route commitments that conflict with service needs.

6. Group by risk level
   6.1. Assign overall risk: High (any Safety-Critical or >1,000 mi/>30 days overdue), Medium (Due Soon or non-critical open defects), Low (OK).
   6.2. Document the rule definitions used for the risk grouping in the Assumptions log.

7. Build the Fleet Exception Register
   7.1. Create one row per vehicle containing at minimum:
       - Vehicle ID (and plate/VIN if available)
       - Source mileage (value, date, and source document)
       - Due service(s) with due mileage/date and basis (policy/OEM)
       - Risk flag/level (High/Medium/Low, plus Safety-Critical and/or Downtime Risk flags)
       - Recommended action (e.g., "Escalate to dispatcher for immediate pull", "Schedule next available window", "Monitor")
       - Human decision field (Dispatcher/Manager decision, name, timestamp)
   7.2. Include additional helpful fields when available: last service reference (invoice #/date), open defects summary, parts on order, warranty status, DOT/emissions deadlines, route impact notes, and comments.
   7.3. Use Edit to draft the register as a Markdown table or CSV; maintain a link/back-reference to each source item.

8. Escalate before scheduling
   8.1. For High risk and Safety-Critical items, prepare a concise escalation summary per vehicle citing sources and recommended immediate actions.
   8.2. Present the summary for dispatcher decision on pull-from-route, substitution, or temporary restrictions. Pause and record the decision in the human decision field.
   8.3. For Downtime Risk, analyze route schedules to propose options: swap vehicles, after-hours service, split routes, or defer within policy limits. Record the decision.

9. Propose a service schedule
   9.1. After decisions, build a tentative schedule that respects route windows, shop capacity, provider hours, parts lead times, and warranty requirements.
   9.2. Batch Medium/Low risk items for efficiency and geographic proximity if using external vendors.
   9.3. Mark schedule items as Tentative until dispatcher approval.

10. Verification and quality checks
   10.1. Verify each vehicle row contains: source mileage, due service(s), risk flag, recommended action, and a human decision field.
   10.2. Check for logical consistency: no negative intervals, no duplicated services recently performed, and no mileage regressions.
   10.3. Flag missing inputs that block decisions and request the specific documents or data points.

11. Output and handoff
   11.1. Use Edit to produce: (a) the Fleet Exception Register, (b) an escalation packet for dispatcher review, (c) a tentative service schedule, and (d) an Assumptions & Data Issues log.
   11.2. Summarize counts by risk level and list vehicles requiring immediate action.
   11.3. Capture acknowledgments/approvals and time-stamp the artifacts for audit.

## Inputs
- Fleet roster (vehicle IDs, plates, VINs, classes).
- Odometer logs with dates and sources.
- Repair invoices and service history.
- Inspection forms (e.g., DOT, preventive maintenance checklists) with findings and severities.
- Driver notes/defect reports.
- Route schedules and upcoming assignments.
- Maintenance policy intervals and OEM recommendations.
- Shop capacity constraints and preferred vendors (optional).

## Outputs
- Fleet Maintenance Exception Register (Markdown/CSV) with one row per vehicle including: source mileage, due service(s), risk flag, recommended action, and human decision field.
- Dispatcher escalation packet summarizing High-risk and Safety-Critical vehicles with source citations.
- Tentative maintenance schedule aligned to route windows and capacity.
- Assumptions and Data Issues log with risk rules and unresolved gaps.
- Summary dashboard: counts by risk and list of immediate actions.

## Examples
Trigger: "Audit our fleet using last month’s odometer logs, inspection forms, and driver notes. Create an exception register and tell me what must be escalated to dispatch today."
Behavior: confirm policies and thresholds → Read the provided documents → normalize IDs/units/dates → compute due services and overdue status → assign risk levels → build the exception register with required fields → prepare dispatcher escalation for High/Safety-Critical items → pause for decisions and record them → draft a tentative service schedule → output artifacts and a summary by risk level.

## Notes
- Do not fabricate intervals or mileage. If an interval is missing, request it or mark the item as "Interval needed."
- Safety-critical defects must be escalated before scheduling; do not recommend continued service without explicit dispatcher approval.
- Keep units consistent; convert km to miles when needed and note the conversion.
- Respect warranty and regulatory constraints (e.g., DOT annual inspection due dates) and prioritize accordingly.
- If telematics or ELD data are available, prefer those for current mileage; reconcile discrepancies against manual logs and note the choice.
- For newly repaired vehicles, cross-check invoices to avoid duplicating work; mark such services as recently completed.
- Maintain data lineage: include source document names/IDs and dates for auditability.

How to install:

1. Create a folder named fleet-maintenance-exception-register 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 fleet-maintenance-exception-register/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!

This has been my favorite prompt this year. Using it to kick start my learning for any topic. It breaks down the learning process into actionable steps, complete with research, summarization, and testing. It builds out a framework for you. You'll still have to get it done.

**Prompt:**

[SUBJECT]=Topic or skill to learn
[CURRENT_LEVEL]=Starting knowledge level (beginner/intermediate/advanced)
[TIME_AVAILABLE]=Weekly hours available for learning
[LEARNING_STYLE]=Preferred learning method (visual/auditory/hands-on/reading)
[GOAL]=Specific learning objective or target skill level

Step 1: Knowledge Assessment

1. Break down [SUBJECT] into core components
2. Evaluate complexity levels of each component
3. Map prerequisites and dependencies
4. Identify foundational concepts
5. Output detailed skill tree and learning hierarchy

~ Step 2: Learning Path Design

1. Create progression milestones based on [CURRENT_LEVEL]
2. Structure topics in optimal learning sequence
3. Estimate time requirements per topic
4. Align with [TIME_AVAILABLE] constraints
5. Output structured learning roadmap with timeframes

~ Step 3: Resource Curation

1. Identify learning materials matching [LEARNING_STYLE]:
2. - Video courses
3. - Books/articles
4. - Interactive exercises
5. - Practice projects
6. Rank resources by effectiveness
7. Create resource playlist
8. Output comprehensive resource list with priority order

~ Step 4: Practice Framework

1. Design exercises for each topic
2. Create real-world application scenarios
3. Develop progress checkpoints
4. Structure review intervals
5. Output practice plan with spaced repetition schedule

~ Step 5: Progress Tracking System

1. Define measurable progress indicators
2. Create assessment criteria
3. Design feedback loops
4. Establish milestone completion metrics
5. Output progress tracking template and benchmarks

~ Step 6: Study Schedule Generation

1. Break down learning into daily/weekly tasks
2. Incorporate rest and review periods
3. Add checkpoint assessments
4. Balance theory and practice
5. Output detailed study schedule aligned with [TIME_AVAILABLE]

Make sure you update the variables in the first prompt: SUBJECT, CURRENT\_LEVEL, TIME\_AVAILABLE, LEARNING\_STYLE, and GOAL

If you don't want to type each prompt manually, you can run the Agentic Workers, and it will run autonomously.

Enjoy!

Hello,

I thought I'd put together a quick guide on how any can build a team of Agentic Workers with just $120/m. I think this is the minimum starting point and I'll also include areas where you can spend more depending on what you're looking to achieve.

Lets break down where the spend goes,

Models:
You can purchase compute from various models (GPT, Claude, Grok, etc) from various places. But here's my recommendation, buy a ChatGPT Codex $20/m subscription. This will give you the most frontier model tokens per dollar.

Computer:
If you really want your agents to work, they need to have an computer. This ensures that your agents can generate any file type, never forget what you were working on which compounds in your favor over time, a browser which helps access information that may not have an API, CLI, or MCP, and the ability to schedule recurring jobs so you agent works 24/7.

Harness:
This is the tooling around your model. This is the ability to connect to your integrations, search the web for real time information, save and execute workflows, generate images, etc.

You can run agents on your personal computer but this is where agenticworkers.com comes in, this gives you the harness, model, and computer already packaged up for your agents with a simple setup. This also means you don't need to keep your computer online and can scale to as many agents as you need. You get all this for $99.

So with $120/m you can setup your whole Agentic Team. Now where do you scale?

If you need smart agents to complete complex work, upgrade your ChatGPT subscription to Max or buy an Openrouter API so you can delegate to expensive models when needed.

If you need more tokens, upgrade your chatGPT subscription to Max, you get around $2k worth in tokens for $200/m.

If you need to do CPU intensive task, like Video and Game development / App development invest in more CPU and storage on your agents computer.

Hope you find this helpful!

Here's a Skill to generate a short launch video for your SaaS product.

---

name: create-proof-led-launch-video

description: Create polished 20–45 second product launch films, SaaS promos, homepage hero videos, feature explainers, and proof-led demos that open with a business problem, show a simple setup, demonstrate the product doing real work, connect proof or feedback to a better outcome, and end with clear category positioning and a CTA. Use for HyperFrames-based motion design and final MP4 delivery when the user wants a crisp, kinetic, production-quality product video with reusable brand variables rather than a one-off branded template.

---

# Create a Proof-Led Launch Video

Build a short product film around one persuasive idea: show why the current workflow fails, how quickly the product changes it, and what proof the buyer receives. Keep the composition reusable by resolving every brand-specific choice through variables.

## Use the video toolchain

Read and follow the available `hyperframes`, `product-launch-video`, `hyperframes-creative`, `hyperframes-animation`, `hyperframes-cli`, and `media-use` skills as applicable. Treat this skill as the narrative and art-direction layer over that production workflow.

Use HyperFrames for the editable composition, deterministic animation, preview, checks, snapshots, and render. Use local, licensed, generated, or user-provided media only. Do not render a final video until the user has reviewed the interactive preview and approved it.

## Resolve the variable contract

Create a project-level `video-brief.json` or equivalent data object with this shape. Fill explicit user inputs first, derive defensible values from supplied product material second, and use the defaults last.

```json

{

"format": {

"duration_seconds": 30,

"width": 1920,

"height": 1080,

"fps": 30,

"deliverable": "mp4"

},

"brand": {

"company_name": "{{COMPANY_NAME}}",

"product_name": "{{PRODUCT_NAME}}",

"logo_path": "{{OPTIONAL_LOGO_PATH}}",

"site_url": "{{SITE_URL}}",

"primary_color": "#5B35F5",

"accent_color": "#BDFB4B",

"background_color": "#F4F1E8",

"ink_color": "#11110F",

"heading_font": "Inter",

"body_font": "Inter",

"mono_font": "ui-monospace",

"visual_tone": "crisp, confident, editorial, technical"

},

"message": {

"audience": "{{PRIMARY_AUDIENCE}}",

"business_problem": "{{THE COSTLY OR FRUSTRATING STATUS QUO}}",

"trust_gap": "{{WHAT THE BUYER CANNOT SEE, VERIFY, OR IMPROVE}}",

"solution": "{{ONE-SENTENCE PRODUCT SOLUTION}}",

"setup_action": "{{THE SIMPLEST REAL FIRST STEP}}",

"work_shown": "{{WHAT THE PRODUCT DOES ON SCREEN}}",

"proof_object": "{{THE RESULT, ARTIFACT, OR EVIDENCE CREATED}}",

"improvement_loop": "{{HOW FEEDBACK OR PROOF IMPROVES THE NEXT OUTCOME}}",

"category_positioning": "{{PLAIN CATEGORY SENTENCE OR X-FOR-Y ANALOGY}}",

"cta_label": "{{CTA_LABEL}}",

"cta_url": "{{CTA_URL}}"

},

"demo": {

"install_command": "{{OPTIONAL_LITERAL_COMMAND}}",

"product_url": "{{OPTIONAL_PRODUCT_URL}}",

"capture_paths": ["{{OPTIONAL_SCREENSHOT_OR_VIDEO_PATH}}"],

"steps": ["{{REAL_STEP_1}}", "{{REAL_STEP_2}}", "{{REAL_STEP_3}}"]

},

"audio": {

"voice": "clear, conversational, assured",

"voice_id": "{{OPTIONAL_VOICE_ID}}",

"music": "minimal electronic pulse with forward motion",

"captions": true

}

}

```

Never invent commands, UI behavior, integrations, performance claims, customer counts, or business outcomes. If a critical product fact cannot be verified from the user’s material or the live product, flag the placeholder before final render.

Use brand colors as tokens throughout the composition; do not hard-code brand values inside individual scenes. Preserve at least WCAG AA contrast for ordinary text. When no brand system exists, use the neutral defaults above and one primary plus one accent color.

## Write the six-beat narrative

Default to six scenes and exactly one idea per scene. Scale the times proportionally when the requested duration differs from 30 seconds.

| Beat | 30-second timing | Purpose | Required visual |

| --- | ---: | --- | --- |

| Trust gap | 0.0–4.5s | State the business problem before naming the product | Large kinetic headline plus one small status signal |

| Cost | 4.5–8.5s | Show what the missing proof, context, or visibility prevents | One consequence chain or failed loop |

| Easy start | 8.5–14.3s | Reveal the product and make adoption feel immediate | Literal command, action, or three-step setup |

| Work | 14.3–18.2s | Show the product operating across the real workflow | Real product footage framed inside a designed stage |

| Proof loop | 18.2–25.0s | Show the reviewable artifact and how feedback improves the next run | Evidence surface, milestone, annotation, or before/after loop |

| Positioning | 25.0–30.0s | Give the category shortcut and one CTA | Product lockup, category line, CTA, URL |

Lead with the pain, not the logo. Mention the product for the first time when the solution appears. Earn the category line with the preceding demonstration.

Write 60–80 narration words for a 30-second film. Favor short declarative sentences, concrete nouns, and spoken rhythm. Use this semantic template without copying its wording:

```text

{{AUDIENCE_OR_WORK}} happens quickly. But when {{STATUS_QUO}}, {{TRUST_GAP_QUESTION}}?

Without {{PROOF_OBJECT}}, there is no {{CONTEXT}} and no way to {{IMPROVEMENT}}.

{{PRODUCT_NAME}} changes that. {{SETUP_ACTION}}.

Now it can {{WORK_SHOWN}}.

Every run becomes {{PROOF_OBJECT}}, so {{AUDIENCE}} can {{REVIEW_ACTION}} and improve what happens next.

{{CATEGORY_POSITIONING}}. {{CTA_LABEL}} at {{SITE_URL}}.

```

Rewrite every line for the actual product. Do not use filler such as “revolutionary,” “seamless,” “game-changing,” or “next-generation.”

## Design the visual system

Create a bespoke composition from the variable contract rather than recoloring an existing brand.

- Use a restrained 70/20/10 color hierarchy: background, ink, accents.

- Use one display sans, one text sans, and one mono face only when code or technical status is meaningful.

- Make the headline the visual anchor; keep supporting copy short enough to read in one glance.

- Build terminal, browser, dashboard, or device frames as designed stages around real product material.

- Use an editorial grid, generous margins, crisp rules, compact labels, and deliberate asymmetry.

- Keep logos subordinate until the solution reveal and final lockup.

- Show real product truth whenever possible. Stylize the frame, not the evidence.

- Place captions in a consistent safe-area band with high contrast and no collision with the primary message.

Avoid glossy 3D blobs, generic gradients, random glass cards, fake analytics, decorative charts, and excessive UI chrome unless the user’s brand explicitly calls for them.

## Animate with purpose

Use motion to explain cause and effect.

- Animate headlines by phrase or semantic unit, not letter-by-letter by default.

- Keep entrances fast and exits clean; allow enough still time to read every important claim.

- Use one primary motion idea per scene: reveal, squeeze, handoff, scan, zoom-through, or push.

- Map transitions to meaning: squeeze for constraint, zoom-through for solution reveal, push for workflow progress, crossfade for synthesis.

- Maintain subtle ambient motion in long holds without making the frame restless.

- Make captions seek-safe and synchronize them to narration in one- to four-word groups.

- Author all animation deterministically so any frame can be rendered directly.

- Respect reduced-motion behavior in browser previews when the composition is reused on the web.

Do not hide weak messaging behind constant movement. If a frame fails as a still, fix its hierarchy before adding animation.

## Build product proof

Use real footage or screenshots for the Work and Proof Loop beats. Capture the shortest sequence that proves the claim.

1. Show the initiating action.
2. Show the product doing the relevant work.
3. Show the reviewable result or evidence.
4. Show the feedback, annotation, approval, or changed next outcome when applicable.

Crop intentionally around the active UI. Magnify details when full-screen footage would be unreadable. Use milestones, cursor focus, or callouts only when they clarify the sequence. Never imply a feature exists through animation alone.

When the product uses a command or install step, show the exact literal command in a terminal scene and keep it readable for at least two seconds. Pair it with the resulting browser or product state when that state can be shown truthfully.

## Direct and master audio

Make narration the priority. Use an assured, conversational performance rather than an announcer read.

- Target roughly 145–165 spoken words per minute.

- Use sparse music that supports momentum without competing with speech.

- Add restrained interface ticks, impacts, or transition sounds only on meaningful events.

- Duck music under narration and leave space before the final category line.

- Deliver final integrated loudness near `-16 LUFS` with true peak at or below `-1.5 dBFS` for web playback.

- End music and narration intentionally; do not leave an abrupt cut or accidental silent tail.

## Produce and review

Create these artifacts before rendering:

1. `video-brief.json` with the resolved variable contract.
2. `SCRIPT.md` with narration and on-screen copy.
3. `STORYBOARD.md` with scene timings, visual proof, motion, audio, and transitions.
4. The editable HyperFrames composition and locally frozen media.

Run the HyperFrames lint, runtime, layout, contrast, duration, and media checks. Snapshot every scene midpoint plus both sides of every transition. Inspect the contact sheet for hierarchy, repetition, unreadable UI, caption collisions, blank frames, and unsupported claims.

Start the interactive HyperFrames preview and give the user the Studio project URL. Summarize the creative choices and any unresolved factual placeholders. Wait for explicit approval before the high-quality render.

## Render and verify

After approval, render the high-quality master. Then verify the final file itself:

- Confirm H.264 MP4, expected dimensions, exact intended duration, frame rate, AAC stereo audio, and fast-start metadata.

- Decode the complete file with no errors.

- Measure integrated loudness and true peak.

- Generate and visually inspect a contact sheet from the final MP4.

- Provide the embedded local video and a clickable absolute-path download link.

Keep the editable source, approved master, and any derived social cut clearly named. Never overwrite a user-approved render without preserving the prior file.

## Acceptance criteria

Do not call the film finished unless all of the following are true:

- The business problem is understandable before the product appears.

- Setup feels concrete and easy because the viewer can see the real first action.

- Product footage proves the central claim.

- The proof or feedback loop connects to a better next outcome.

- The category sentence is accurate, memorable, and earned.

- The CTA names one next step.

- Every brand-specific value comes from the variable contract.

- Every visible product claim is supported by supplied or captured evidence.

- The preview passed technical and visual QA and the user approved it.

- The final MP4 passed duration, decode, picture, and audio verification.

Source