OR Key
drop another .md file to compare - side-by-side diff against scheduling

scheduling

Sets up and manages your meetings.
description: "Triggers on prompt mention of 'scheduling'."
personal 2 files
Export

What it does for you

Sets up and manages your meetings.

What it produces

A recent result, so you can see the kind of work it returns.

loading…

How to get it

These run inside the Snappy workspace. Want this working in your business? I set skills like this up with you, in one focused week.

Work with me
For developers how this skill is built, graded, and how it runs

at a glance- the short version

actorExported functions in state/lib/scheduling.ts.
auditorNone wired yet - eval is manual (Robert review).
eval modeshape
categoryIntegrations
stages1
dependscalendar

what's inside - the parts that make up a skill 3/4 present

A skill is just a few plain-text files. Only the main one is required. The rest are optional, added as the work needs them. This is what the skill is made of; how it runs is just below.

The skill
state/skills/scheduling/SKILL.md present
the skill itself, in plain text
The main file. It says what the skill is and lays out the steps in plain English.
Code
state/lib/scheduling.ts present
code the skill can run
Reusable code this skill can call when it needs to.
Scripts
state/bin/scheduling/ not present
helper scripts
Optional. Added when a skill has a few commands to run.
Loader
state/skills/scheduling/AGENTS.md present
what the AI loads on the fly
Loaded automatically the moment this skill is needed. Kept short on purpose.

how it's graded - what counts as a good run 4 criteria · 3 deterministic · 1 judge

Each row is one thing a good run has to get right. deterministic means a quick check decides, pass or fail. judge means the AI reads the result and rates it. Grading each piece on its own (instead of one overall score) shows exactly where a run fell short, so the fix is obvious.

name
kind
check
list_events_returns_nonzero
deterministic
listEvents() returns an array with length > 0 (at least one event, not empty or null).
create_event_succeeds
deterministic
createEvent(input) returns {success: true, event_id, ...} and the event is readable via a subsequent listEvents() call.
check_availability_responds
deterministic
checkAvailability(timerange) returns {available_slots: [...]} with length > 0 (at least one slot found, not empty).
event_data_integrity
judge
Created event has correct title, time, attendees matching input. Retrieved events have valid start/end times and descriptions.

how it runs - the shared frame every skill uses 4/5 present

Every skill runs the same way. One part does the work, a separate part checks it, and a short loader hands the AI exactly what it needs for the job. Anything this skill doesn't use shows a one-line note saying why, on purpose, not by accident.

makes the work The worker
present
Exported functions in state/lib/scheduling.ts. the worker
Does the actual work. Whatever it produces is what gets checked next.
checks the work The reviewer
present
None wired yet - eval is manual (Robert review). the checker
A separate checker grades the work, so the part that made it can't approve its own work.
frame
learns Self-correction
not present

This skill doesn't fix its own gaps yet.

tidies up Background fixes
present
queued for rewrite runs in the background
Bigger fixes that can't be made on the spot get queued and rewritten in the background later.
remembers Run history
present
state/log/pending-eval.ndjson pending runs
Every run is written down here, then reviewed by hand each week.
Critical rules the things this skill must not get wrong
  1. ALWAYS prefer proposeSlots() over hand-rolling availability windows - the lib understands working-hours and timezone.
  2. ALWAYS scope-only first (listEvents / checkAvailability). createEvent() is the apply path; verify with an independent calendar fetch after creation.

what it has learned - fixes written back in over time sample

When a run hits something this skill didn't handle, the fix gets written back into the skill so it doesn't happen again. FIXED means it was corrected on the spot. LOGGED means it's queued for a bigger rewrite. Either way, the skill gets a little better and never makes the same mistake twice.

  1. Loading feedback rows…

how the work flows- who makes it, who checks it

inputs calendar
actor Exported functions in state/lib/scheduling.ts.
auditor None wired yet - eval is manual (Robert review).
1 data
eval log
`state/log/pending-eval.ndjson` (skill: "scheduling") - manual until auditor wired
+ eval for this step

SKILL.md- the skill, written out in plain English

scheduling

Meeting scheduling for all snappy-* skills.

Ported from kernel snappy-scheduling in Phase 0.5. See state/lib/scheduling.ts for the full API surface.

Steps

  • listEvents() - see state/lib/scheduling.ts
  • createEvent() - see state/lib/scheduling.ts
  • checkAvailability() - see state/lib/scheduling.ts
  • proposeSlots() - see state/lib/scheduling.ts
  • listContacts() - see state/lib/scheduling.ts

Eval

Actor: the exported functions in state/lib/scheduling.ts. Auditor: none wired yet - eval is manual (Robert review). File a state/log/pending-eval.ndjson row on each run.

Score convention:

OutcomeScore
Pass on first try1.0
Failed first, auto-fix applied, re-check passed0.5
Still failing or unrecoverable0.0

Gotchas

via the Phase 0.5 driver. Only these rewrites were applied: already in state/lib/)

  1. realpathSync(process.argv[1]) CLI guard wrapped in try/catch
  • See the kernel SKILL.md for the original long-form guidance if you need it

(read-only reference at the kernel path above).

Graduation

This skill is prose. Graduate by defining a deterministic auditor and flipping eval: auto.

Rubric

criteria:
  - name: list_events_returns_nonzero
    kind: deterministic
    check: "listEvents() returns an array with length > 0 (at least one event, not empty or null)."
  - name: create_event_succeeds
    kind: deterministic
    check: "createEvent(input) returns {success: true, event_id, ...} and the event is readable via a subsequent listEvents() call."
  - name: check_availability_responds
    kind: deterministic
    check: "checkAvailability(timerange) returns {available_slots: [...]} with length > 0 (at least one slot found, not empty)."
  - name: event_data_integrity
    kind: judge
    check: "Created event has correct title, time, attendees matching input. Retrieved events have valid start/end times and descriptions."

AGENTS.md- what the AI loads when this skill comes up

scheduling - loader

Per-turn rules for the scheduling skill. Full reference: state/skills/scheduling/SKILL.md.

Critical Rules

_(no failures recorded yet - this skill has not produced hard-won rules. It is a Phase 0.5 port from kernel snappy-scheduling. Read state/lib/scheduling.ts for the actual API surface before invoking.)_

  • ALWAYS prefer proposeSlots() over hand-rolling availability windows - the lib understands working-hours and timezone.
  • ALWAYS scope-only first (listEvents / checkAvailability). createEvent() is the apply path; verify with an independent calendar fetch after creation.

Commands

| ui model | live composition via compose_inline, persisted as artifact lang_body, reopened with OpenArtifact | |invoke (TS): import { listEvents, createEvent, checkAvailability, proposeSlots, listContacts } from "../lib/scheduling.ts" |eval log: state/log/pending-eval.ndjson (skill: "scheduling") - manual until auditor wired

Known Pitfalls

  • Phase 0.5 port stub. Real behavior in state/lib/scheduling.ts.
  • Calendar write APIs return 200 with the event payload - that is NOT independent evidence. Fetch the event by ID from a different session before claiming success (actor != auditor).

Self-Test

An agent reading this should correctly:

  1. [ ] Use proposeSlots() instead of hand-rolling windows
  2. [ ] Verify createEvent() with a separate fetch by ID
  3. [ ] Treat listEvents / checkAvailability as scope-only

Found a gap? Edit this file. <!-- footer-injection-point -->

api.ts- the code it can call

#!/usr/bin/env npx tsx
/**
 * snappy-scheduling/api.ts -- Meeting scheduling for all snappy-* skills.
 *
 * Re-exports from calendar and knowledge. Adds slot-finding logic
 * that respects Robert's scheduling preferences.
 *
 * Usage:
 *   npx tsx api.ts available           # free/busy for today
 *   npx tsx api.ts propose 3           # propose free 30-min slots for next 3 days
 *
 * Or import as module:
 *   import { listEvents, createEvent, checkAvailability, proposeSlots } from "./scheduling.ts";
 */

// --- Re-exports from child skills ---
// proposeSlots is owned by snappy-calendar (single source of truth for
// slot-finding logic). snappy-scheduling re-exports it so agents can get
// everything through one import surface.

export { listEvents, createEvent, checkAvailability, proposeSlots } from "./calendar.ts";
export { listContacts } from "./knowledge.ts";

import { proposeSlots } from "./calendar.ts";

// --- CLI ---

if (import.meta.url === `file://${process.argv[1]}`) {
  (async () => {
    const { checkAvailability } = await import("./calendar.ts");

    const [, , cmd, ...args] = process.argv;

    switch (cmd) {
      case "available": {
        const data = await checkAvailability(1);
        console.log(JSON.stringify(data, null, 2));
        break;
      }
      case "propose": {
        const days = args[0] ? parseInt(args[0], 10) : 3;
        const duration = args[1] ? parseInt(args[1], 10) : 30;
        const slots = await proposeSlots(days, duration);
        if (slots.length) {
          console.log(`Found ${slots.length} available ${duration}-min slots (next ${days} days):\n`);
          for (const s of slots.slice(0, 10)) {
            const d = new Date(s.start);
            const day = d.toLocaleDateString("en-US", { weekday: "short", month: "short", day: "numeric" });
            const time = d.toLocaleTimeString("en-US", { hour: "numeric", minute: "2-digit" });
            console.log(`  ${s.preferred ? "*" : " "} ${day} ${time}${s.preferred ? " (preferred)" : ""}`);
          }
          if (slots.length > 10) console.log(`  ... and ${slots.length - 10} more`);
        } else {
          console.log("No available slots found.");
        }
        break;
      }
      default:
        console.log("Usage: npx tsx api.ts [available|propose] ...");
    }
  })();
}

scripts- helper scripts it can run

prose-only skill - 1 inline code block live in SKILL.md above (no state/bin/ sidecar yet).

how we check it- the checks, plus the last 10 runs

rubric shape schema-shape check (no inline rubric)
recent no runs actor/auditor: unverifiable
deps calendar

no recent runs logged - the eval contract is declared but nothing has been graded yet