swyxio/skills

# Accelevents API — Speaker Management

## API Endpoints

- **Base URL:** `https://api.accelevents.com/rest/host/event/{eventUrl}/speaker`
- **Event URL for Europe:** `ai-engineer-europe-2026`
- **API Key:** stored as `ACCELEVENTS_API_KEY` secret

### Authentication

[Credential-related source omitted]
[Credential-related source omitted]

### GET speakers list

# Accelevents Speaker & Session Sync

Whenever you update speaker data OR session/schedule details on the website, you MUST also push those changes to the corresponding profiles and sessions in Accelevents.

## When This Applies

### Speaker changes
- Adding or replacing a speaker photo
- Updating speaker name, role, company, bio, or social links
- Any change to `src/pages/europe/source/schedule.json` that affects speaker metadata

### Session/schedule changes
- Changing session start time, end time, or day
- Changing session room, track, or format

# Cloudflare Agents SDK

Use current Cloudflare documentation and the installed `agents` package as the
contract. APIs in this SDK evolve quickly; do not trust remembered signatures or
examples without checking the relevant version.

## Inspect first

1. Read the project's package version, Wrangler configuration, Agent exports,
   routing entrypoint, and generated binding types.
2. Retrieve the current docs for the feature being changed.
3. Inspect installed exports and `.d.ts` files before adding casts or adapters.
4. Identify the Agent instance name and who is authorized to select it. Instance
   naming is a state-partition and access-control decision, not just a URL detail.

# AI Devblog

Write a technical story that changes what a particular reader understands,
believes, or can do. Keep the empirical honesty of a good engineering report,
but make comprehension and human interest the organizing priorities.

Use this order of attention:

> route the genre → align with the reader → choose the angle → explain →
> support with evidence → edit → review → present → publish

Apply `swyx-writing` as the shared voice and editing layer. For substantial
public technical writing, read its
[technical-writer influences](../swyx-writing/references/technical-writer-influences.md)

# AI Engineering

Use enough structure to make a model workflow explainable and recoverable without
turning every prototype into an operations project. This skill owns request
validation, retry/cache behavior, rate-aware fan-out, and measurement. Pair it
with `live-ai-pipelines` only when a run needs live progress or durable resume.

For provider-specific API behavior, read [provider operation notes](references/provider-operation-notes.md) when the adapter is OpenAI, Anthropic, or OpenRouter, then verify volatile details in current provider docs. For image/video generation or FAL model fan-outs, read [image, video, and FAL operation notes](references/image-video-fal.md).

## Useful defaults

- Improve the established workflow before introducing another path. Do not turn implementation choices or temporary exceptions into user requirements.
- Do not publish a malformed, partial, or schema-invalid result as complete.
- For a machine-consumed structured artifact, use the selected model provider's documented native structured-output API with an explicit schema. Do **not** treat a free-form completion prompted with “return JSON” plus local `JSON.parse` as structured output.

# AI README

Write a repository-native explanation that earns trust by working. Lead with
what the project is, who it helps, and the shortest verified path to an
observable result. Then reveal the mechanism, tradeoffs, diagnostics, and
internals at the reader's pace.

Combine two complementary habits:

- use an executable, progressive spine: one stable example, working commands,
  expected results, controlled variants, visible failure modes, and a reference
  path when correctness or quality can vary;
- write like a public technical notebook: begin from a real task or curiosity,
  show the decisive artifact near the claim, explain what happened in ordinary

# Align Me

Pause before the long autonomous run and surface the choices that could materially change the outcome.

**Output contract:** The deliverable is a self-contained questionnaire in the final answer: every numbered question, every lettered option with its consequence, and every recommendation. A tool call or a summary of decisions is not the deliverable.

## Prepare

1. Inspect available context and perform lightweight, read-only discovery first.
2. Do not ask for facts that can be discovered safely or decisions whose answer would not affect the work.
3. Identify ambiguities involving scope, product behavior, destructive changes, architecture, migration, rollout, safety, cost, or verification.

## Ask the batch

# Annotated video production

Make the conversation easier to follow with visuals that earn their place.
Resume from the current cut, timebase, cue selections, saved assets and feedback.
Use the existing project record; preserve source footage and review versions.
Revisit only work affected by a changed cut or asset.

This skill owns editorial treatment and review. Use `transcribe-anything` for
missing ASR, `podcast-publishing-assistant` for copy/chapters/release handoff, and
`latent-space-thumbnail-director` for LS thumbnails. Use source-specific download
skills for acquisition and upload/API skills for publication. Retain the existing
renderer; use `hyperframes`/`general-video` only when that engine fits the work.
Pass the exact media version, edit map, decisions and authorized scope at handoff.

# Antislop Codebase

Use this skill to reduce demonstrated maintenance cost while keeping current behavior essentially as-is. Do not impose a universal "product-shaped" architecture.

## Boundary

This skill is for demonstrated structural maintainability problems such as unclear ownership, harmful coupling, repeated logic, or repository-wide migration debt.

Do not expand the scope into a full production-readiness initiative. Observability/logging programs, security reviews, compliance, incident response, SLOs, runbooks, secrets posture, penetration testing, and deep reliability engineering belong in separate follow-on skills unless the user explicitly asks to include a small enabling change.

## Operating Principles

- Preserve behavior first. Improve architecture in thin, reversible slices.
- Ground every decision in repo facts: file sizes, dependency graph, tests, runtime shape, API surfaces, user workflows, deployment limits, and current dirty worktree.

# App UX: keyboard shortcuts and common paradigms

## User preference

**Match desktop-app and modern web conventions by default.** Users should not need to hunt for close affordances or discover shortcuts only by accident.

Apply only the patterns relevant to the interaction being built or reviewed.
This skill does not authorize unrelated UI changes, and its tables are defaults,
not a product-wide acceptance checklist. Accessibility, prevention of unintended
destructive action, and avoiding silent data loss remain blocking where the
touched interaction creates those risks. Stop when the requested interaction
works in its relevant input and state variants; report adjacent consistency
improvements as follow-ups.

# Auto Review

Review the completed change as a closeout check. Use the review capability available in the current environment; do not make completion depend on a particular helper, model, service, or installation.

## Select the real change

- For dirty work, review the staged, unstaged, and relevant untracked diff.
- For a commit, review that commit and its immediate context.
- For branch or pull-request work, compare against the actual base branch.
- Do not push, rewrite history, or manufacture a diff merely to make review possible.

## Review priorities

Inspect the changed code and adjacent ownership boundaries for:

# Babysit Runs

Operate existing runners toward the authorized outcome at the agreed quality. Prefer targeted repairs over a new scheduler or pipeline rewrite. Use the selected provider/runtime skill when invocation or access needs troubleshooting; use `live-ai-pipelines` only when recovery architecture needs implementation.

## Choose the operating mode

**Completion mode:** finish the authorized workload using the established implementation, repairing defects as needed.

**Pilot-and-improve mode:** exercise an existing or modified workflow on representative inputs, inspect execution and output quality, and make bounded improvements before broader rollout. State what is being tested, the quality baseline, resource/spending limits and the completion boundary. A pilot is complete when the requested behavior is demonstrated and material findings are resolved or clearly reported; optional optimization ideas do not keep it running indefinitely.

## Adopt, detach and schedule

Inspect actual processes, owners, logs and retained results. Adopt a matching live run rather than launch a duplicate. Discover routine facts from existing metadata and task history instead of re-interviewing the user.

# Blog System Design

Build a dense, readable technical publication rather than a marketing landing
page. Treat the index, post shell, navigation, typography, and explanatory
components as one reusable reading system.

## Keep the boundary clear

Use `ai-devblog` for choosing an article angle, writing and editing the prose,
selecting article-specific evidence, and publishing a post. Use this skill when
that work requires a new or changed shared layout, navigation model, taxonomy,
search behavior, or reusable component.

One article must not silently redesign the blog. Audit the existing system

# Cassandra Creator

Create a durable independent dissent function, not a generic contrarian persona or one-off review. Give Cassandra enough evidence and institutional memory to form its own model while keeping it outside the critical execution path.

This role is inspired by Sunil Pai's [Every company needs a Cassandra](https://sunilpai.dev/posts/every-company-needs-a-cassandra/).

Read [references/cassandra-charter.md](references/cassandra-charter.md) before writing the created agent's durable brief.

## Discover the organization first

Inspect the project before establishing the role:

- Resolve the relevant product, repositories, environments, current stage, and major commitments.
- Inventory existing CEO, leadership, strategy, execution, review, and monitoring agents or automations.

# CEO Creator

Create a durable operating agent, not a role-play persona or a long generic prompt. Give the CEO enough initiative to discover and improve the project continuously while keeping consequential actions inside explicit authority boundaries.

## Discover the project first

Inspect what is available before asking questions or changing state:

- Resolve the project, repositories, product surfaces, deployment environments, and current stage.
- Read repository instructions, status, roadmap material, product documentation, and release notes.
- Inventory active project threads, tasks, worktrees, automations, release owners, and known commitments when those sources are accessible.
- Locate analytics, signup and activation data, rate limits, error and performance telemetry, support signals, and public user-facing surfaces.
- Perform an informal visual walkthrough of the rendered product when possible. Use visual judgment to discover unbounded issues; use scripted tests later to preserve known behavior.
- Distinguish verified facts, reasonable inferences, and unknowns.

# Claude Session Introspect

Claude Code persists every conversation as a JSONL file on disk. This skill is the recipe for opening one and pulling out the numbers you actually want — token usage, prompt counts, compaction events, tool calls — without guessing.

## Where sessions live

```
~/.claude/projects/<encoded-cwd>/<session-uuid>.jsonl
```

`<encoded-cwd>` is the absolute path of the project's working directory with `/` replaced by `-` and a leading `-`. Example: `/Users/swyx/Work/foo` → `-Users-swyx-Work-foo`.

Each line is one event. The interesting `type` values:

# CLI UX

Design one CLI with two deliberate modes:

- optimize interactive use for discoverability, concise defaults, and safe recovery;
- optimize automated use for predictability, bounded context, explicit contracts, and defense in depth.

Keep the CLI self-contained. Do not require an MCP server or companion agent skill. Make the installed CLI capable of describing and safely exercising its own exact-version contract.

Apply this skill proportionally. The requested CLI outcome and concrete risks
created by the changed command define the blocking criteria. The remaining
sections are design options and review lenses, not a demand to redesign every
CLI surface. Stop when the named contract is corrected and focused process or
contract tests prove it; report adjacent improvements as follow-ups.

# Cloudflare Platform Router

Choose the smallest relevant product surface, then use current first-party
documentation or a narrower skill. This router is not a local copy of the
Cloudflare product manuals.

## Retrieve current facts

- [Cloudflare documentation](https://developers.cloudflare.com/) for supported
  behavior, limits, pricing, and product maturity.
- [Cloudflare changelog](https://developers.cloudflare.com/changelog/) for recent
  launches and breaking changes.
- The installed Wrangler configuration schema and package `.d.ts` files for the
  project's actual build contract.

# Cloudflare DO Turn-Based Multiplayer

Model each room as one server-authoritative state machine. Keep the deterministic
game reducer independent from Cloudflare transport so rules and concurrency can
be tested without Wrangler.

## Establish authority

Before editing, identify:

- the room's deterministic Durable Object ID;
- the public room code and any private invite credential;
- how a device resumes and which seats it owns;
- the persisted room revision and action identity; and

# Cloudflare Email Service

Retrieve current Cloudflare documentation and installed Workers types before
using API signatures, limits, pricing, or CLI commands. Email Service is evolving
and the Workers binding, REST API, SMTP, and Email Routing have distinct
contracts.

## Choose the surface

| Need | Use | Reference |
| --- | --- | --- |
| Send from a Worker | Email binding | [sending.md](references/sending.md) |
| Send from outside Workers | REST API or SMTP | [rest-api.md](references/rest-api.md) |
| Receive, forward, reject, or parse mail | Email Routing `email()` handler | [routing.md](references/routing.md) |

# Cloudflare One

Before citing limits, settings, API fields, category IDs, or exact UI paths, retrieve current information from the [Cloudflare One docs](https://developers.cloudflare.com/cloudflare-one/), the Cloudflare docs MCP server, or the Cloudflare API schema.

## Workflow

1. Classify the ask: architecture, configuration, troubleshooting, migration, or review.
2. Gather context: account ID, users/sites/apps, identity provider, SCIM/group sync, device management, traffic path, compliance constraints, and rollout blast radius.
3. Retrieve only the current docs needed for the products involved: Access, Gateway, WARP/device client, Tunnel/Mesh, Cloudflare WAN, DLP, CASB, device posture, or identity.
4. If account access is available, inspect existing resources before proposing or making changes: Access apps/policies/groups/IdPs, Gateway rules/lists/categories, device profiles/posture checks, tunnels/routes, DNS/resolver settings, and locations/sites.
5. Propose the change set with prerequisites, validation, and rollback. For risky changes, stage disabled or scoped to a pilot group/site unless the user explicitly asks otherwise.

## Assessment Prompts

# Cloudflare One Migrations

Retrieve current Cloudflare docs, Cloudflare API schemas, and source-vendor export docs before generating exact configuration.

## Workflow

1. Identify the source stack: Zscaler ZIA, Zscaler ZPA, Palo Alto NGFW/Prisma/GlobalProtect, legacy VPN/SWG/SD-WAN, or other.
2. Request exports and logs before mapping. Prefer structured exports over screenshots or prose summaries.
3. Build an inventory: identities, groups, apps, destinations, connectors/tunnels, DNS/URL/firewall/DLP/TLS policies, objects/lists, locations/sites, exceptions, hit counts, and compliance logging.
4. Produce a mapping plan: source object, Cloudflare One target resource, confidence, prerequisites, unsupported/partial mappings, and manual decisions.
5. Create dependencies first: identity/[SCIM](https://developers.cloudflare.com/cloudflare-one/team-and-resources/users/scim/), connectors/on-ramps, routes/DNS, lists/objects, TLS bypasses, Access apps/policies, Gateway policies, DLP/CASB, logging.
6. Stage safely: use a migration prefix, create disabled/audit-mode rules by default, pilot with small groups/sites, compare logs, then expand rollout.
7. Account for every source rule. Each rule must map to a Cloudflare object or an explicit Not Migrated row with reason and security impact.

# Cloudflare Production Builder

Apply this guidance proportionally. It is a production reasoning aid, not a
mandatory ceremony layer. Stay within the user's requested operation and do not
turn a diagnosis or recovery into an architecture program.

## Choose the operating mode

- **Answer or diagnose:** inspect only the evidence needed to explain the
  behavior. Do not mutate or design a replacement unless asked.
- **Recover:** restore a known-good capability with the smallest supported,
  reversible operation. Preserve evidence and defer refactoring.
- **Change or migrate:** design compatibility, durability, rollout, verification,
  and rollback for the surfaces actually affected.

# Conference Developer & AI Endpoints — General Pattern

This skill documents the available pattern for developer/AI-facing conference
data. Treat the sections as a surface catalog, not an all-or-nothing acceptance
checklist. For one endpoint, change and validate that endpoint plus its shared
public-data boundary; do not add MCP, CLI, documentation pages, agent skills, or
unrelated endpoints. Stripping private and internal fields is an invariant for
every public surface. Stop when the requested surface is usable and its privacy
contract is verified.

## Surface catalog for a full conference endpoint suite

For a conference at route `/{conf}`, create the following:

# Conference Transcribe

Input: a YouTube URL with chapter timestamps or another multi-talk recording.

Transcribe a multi-talk conference livestream into individual, cleaned-up per-talk markdown files with key takeaways and frequent timestamps.

## Lessons Learned (from AIE Europe Day 1, April 2026)

This skill was born from a real transcription session. Here's what worked and what didn't:

### What Worked

1. **YouTube auto-captions as primary source** -- YouTube's English auto-captions (VTT) are surprisingly good and *instant*. No download wait, no model download, no GPU needed. Prefer this over Whisper for YouTube videos that have captions available.
2. **`yt-dlp --write-sub --write-auto-sub --sub-lang en`** to grab captions directly, then parse the VTT file.

# Coordinate

Do the main work yourself, using Luna for scouting or bounded tasks and Astra for advice. Keep small tasks and narrow lookups local. Delegate only when a concrete assignment saves enough time to justify coordination and you can continue useful independent work.

## Luna: `gpt-6-luna`, high

Use Luna for well-defined work or substantial investigations that require synthesizing information across sources. For scouting, give it a concrete question and sources; ask for concise findings with evidence. Use the findings directly and send gaps back to Luna instead of repeating its reads or searches. For changes, specify the owned files, expected behavior, and relevant checks; have Luna implement and verify them. Tell Luna not to spawn agents.

## Astra: `gpt-6-astra`, high

Consult Astra when the approach is unclear, repeated attempts fail, or the task needs cross-cutting design or aesthetic judgment. Share the question, relevant findings, constraints, and what you have tried. Request advice, then use its guidance to continue implementation. Tell Astra not to spawn agents.

## Coordinate

# Data chatbots

Copilots over **authoritative structured state** (schedules, CRMs, configs) should **draft** changes and **apply** only after explicit human approval. Treat the model as a planner, not a writer.

Apply this guidance to the requested copilot surface and the data risks it
creates. Draft-before-apply, apply-equals-review, authorization, and prevention
of silent destructive replacement are invariants when the workflow can mutate
authoritative data. The remaining incidents, layers, telemetry, caching, email,
and advanced harness patterns are risk-triggered guidance or opportunities, not
a mandate to implement the entire platform. Stop when the requested workflow is
correctly proposed/applied and focused tests cover its plausible integrity
failure; report unrelated hardening as follow-up.

## Battle scars (select those matching the touched risk)

# Data Visualization Quality

Create visualizations that answer the requested analytical question. A valid
chart specification is not automatically publishable.

## Decide before designing

Establish four things before choosing a visual:

1. **Claim:** the comparison, trend, distribution, composition, relationship,
   or decision the user wants to understand.
2. **Required evidence:** the dimensions, measures, units, denominators, time
   windows, and comparable populations needed to support that claim.
3. **Coverage:** which required fields and entities are complete, partial,

# Deep Trajectory Analysis

Determine not merely whether a candidate scored better, but what it changed, whether the named
mechanism fired, how the environment replied, and whether the benefit survived to the final
outcome.

Read [references/evidence-contract.md](references/evidence-contract.md) before defining metrics or
building the report. Run [scripts/validate-report.mjs](scripts/validate-report.mjs) on a
machine-readable result that follows that contract.

## Establish the causal question

Write one sentence for each intended effect before inspecting favorable examples:

# Design Apps with ImageGen

Explore composition and interaction through images, implement the chosen direction, and compare the actual product against it.

## 1. Establish scope

Inspect the affected screens, real content, capabilities, state owners, and responsive behavior. Separate existing contracts from proposed changes. Preserve scoped functionality and data unless the user authorizes changes; generated controls and text are proposals, not product truth.

Retain applicable navigation, account controls, and workspace access through loading and recovery states. Follow [design-preferences](../design-preferences/SKILL.md); shell replacement must be in scope. Report unrelated layout gaps rather than expanding the redesign.

## 2. Research and explore

Read [imagegen-workflow](references/imagegen-workflow.md). Use Chrome computer use to search free Mobbin before ideation, then generate four distinct ImageGen directions including a purposeful wildcard. Give each its own creative brief and reference set. Differences must include composition or interaction, not just palettes and corner radii.

# Design preferences

These are the user's defaults, not universal design rules. Follow an explicit visual reference or request when it overrides them. Apply them to the requested surface; do not expand a small task into a site redesign.

- **No decorative thin accent strips on cards.** Avoid colored or gradient top borders, ribbons, and `::before` lines added just to make repeated panels look designed. Functional table rules, chart marks, focus rings, and active-navigation indicators are fine.
- **Choose the layout for the information.** Use aligned rows or tables for repeated comparisons, and place a finding beside its evidence. Use cards when items genuinely form independent units, not as the automatic wrapper for every paragraph or statistic. Avoid nested cards.
- **Density comes from composition, not tiny text.** Start around 17–18px for reading text on desktop and 16–17px on mobile. Keep secondary labels legible. Shorten repetitive copy, align related facts, and reduce container padding before shrinking type. Recompose mobile comparisons rather than scaling down a desktop table.
- **Make whitespace earn its place.** Use space to distinguish sections and establish hierarchy. Avoid oversized introductory regions, tall rows around two numbers, and equal-height panels full of emptiness. Put repeated caveats once at the relevant section level while retaining essential denominators beside the data.
- **Use brand color confidently and purposefully.** Prefer meaningful series colors, selected states, or a substantial focal region over ornamental gradients repeated everywhere. Preserve strong text contrast on colored surfaces. Follow the actual brand assets and palette; do not invent a substitute logo. A dark masthead and a broad gradient can work when appropriate, but are not mandatory.

## Shared application layout

- **Signed-in pages inherit the shared app shell.** Reuse the existing navigation, account controls, and workspace switcher where the app has one. Include workspace selection, settings, creation/editing, and detail pages; do not build detached page-specific chrome. The shell must also work before a workspace is selected.
- **Keep context through every state.** Loading, empty, error, expired-session, and permission states retain applicable navigation and account or sign-in controls, with useful recovery actions. A missing workspace must not strand the user without a way to switch accounts or sign out.

# DIY Netlify

Deliver the reviewer loop people expect from hosted deploy previews without
recreating a deployment platform:

> Open a PR, wait for the preview link, review it, merge when green, and let the
> exact merge commit deploy to production.

## Preview contract

For each eligible PR:

1. Detect affected deployable targets conservatively, including shared code and
   lockfile changes.

# Download Video

This skill downloads embedded videos from web pages by inspecting the page source, identifying the video hosting service and embed URL, then using yt-dlp to download the video file.

## Why This Skill Exists

Many event replays, webinars, and talks are embedded on pages using private/unlisted video hosting (especially Vimeo). The direct video URL often returns 404 because the video is only accessible through the embed player with the correct referer. This skill handles that automatically.

## Prerequisites

Ensure yt-dlp is installed and up to date (older versions hit different errors):

```bash
which yt-dlp || brew install yt-dlp

# Download X/Twitter Video

Download video from X/Twitter posts via yt-dlp.

## Prerequisites

- `yt-dlp`: `brew install yt-dlp`

## Usage

```bash
python3 scripts/download_x_video.py "https://x.com/user/status/123/video/1" [/output/dir]
```

# Durable Objects

Use Durable Objects when one named object should serialize access to its own
state. Retrieve current Cloudflare documentation for APIs, bindings, storage,
class lifecycle, limits, and pricing.

Load only the relevant reference:

- [rules.md](references/rules.md) for partitioning, storage, concurrency, RPC,
  alarms, and WebSockets.
- [testing.md](references/testing.md) for Workers Vitest and alarm tests.
- [workers.md](references/workers.md) for bindings, lifecycle configuration,
  generated types, and observability.

# Europe Developer & AI Endpoints

AI Engineer Europe 2026 exposes several developer-friendly endpoints for building apps, AI integrations, and tools on top of conference data.

## Available Endpoints

All endpoints are relative to `https://ai.engineer`:

| Endpoint | Description |
|---|---|
| `/europe/llms.txt` | Basic conference info + schedule overview (plain text) |
| `/europe/llms-full.txt` | Full details: all talks, descriptions, and speakers (plain text) |
| `/europe/sessions.json` | All sessions (talks + workshops) as JSON (no sensitive data) |
| `/europe/speakers.json` | All speakers as JSON (no sensitive data) |

# Face Matching

Match real faces to the right people while preserving uncertainty, consent, source boundaries, and existing correct assignments. Keep the ordinary path simple for people who already have a good reference; spend additional retrieval and inference only on unresolved cases.

Read supporting material only when it helps the task:

- [references/resources-and-source-strategies.md](references/resources-and-source-strategies.md): inventory of usable person records, LinkedIn/X/GitHub, employer/personal pages, public search, existing photo collections, video, transcripts, timestamps, browser access, and relevant installed skills/tools.
- [references/worldsfair-2026-journey.md](references/worldsfair-2026-journey.md): detailed real-world case study, concrete incorrect matches, identity corrections, production counts, failed hypotheses, and eight benchmarked padding recoveries.
- [references/implementation-and-operations.md](references/implementation-and-operations.md): existing SCRFD/SFace implementation, image-quality gates, operational commands, repository paths, regression checks, and release verification.

## Distinguish the five problems

1. **Identity coverage:** Do we even know that this person belongs in the searchable population? The source might be a customer directory, employee roster, contact list, event program, cast list, photo metadata, video title, caption, or prior human review.
2. **Person identity:** Does a profile, document, media item, or candidate name actually refer to the right individual? Similar names, employers, public aliases, organizations, and historical affiliations are evidence, not identity by themselves.

# Forge

Forge has two surfaces over Cloudflare:

- **Repositories:** Git hosting, issues, pull requests, Actions, transcripts,
  and repository agents.
- **Deploy / Sites:** an exact pushed SHA becomes a preview and can later become
  the production application.

Cloudflare remains the runtime/provider. Do not substitute another Git or
hosting product when Forge is the requested destination, and do not assume a
hosted app inherits Forge or Cloudflare Access authentication.

## Keep the task scoped

# Future Only

Treat the intended future behavior as the only supported contract.

- Proactively find and remove compatibility shims, deprecated routes, fallback fields, adapters, aliases, dual-write paths, adoption logic, and tests that exist only for obsolete behavior.
- Prefer one canonical API, schema, configuration, and implementation. Update all in-repository callers together.
- Treat preproduction data as disposable. Prefer a fresh baseline, reset, or seed path over backfills, upgrade ladders, historical migration replay, or parallel schemas.
- Delete obsolete coverage only after distinguishing it from tests that still prove current authorization, correctness, security, or user-visible behavior.
- Update active documentation and tooling so they describe only the surviving contract. Historical records may remain clearly historical.
- Do not add a compatibility layer merely to reduce the diff or make old tests pass.

This skill authorizes breaking code, API, schema, configuration, fixture, and test changes within the requested scope. It does not authorize destroying confirmed production or third-party user data. If such data actually exists, stop before irreversible loss and request the smallest explicit approval; otherwise do not preserve hypothetical compatibility.

# Generalize

Surface meaningful improvements at multiple levels and recommend the option that best fits the user's intent and impact-versus-effort tradeoff.

1. Establish the user's actual goal, authorized scope, observed examples, and underlying failure mechanism.
2. Inspect the current conversation, established workflow, and relevant code, data, tests, or logs. Reuse existing parsers, contracts, and resume mechanisms before proposing another path. Search available agent session history only when past decisions or recurrence could change the conclusion; target exact repository names, errors, or phrases, bound the search, and avoid secrets or unrelated private content.
3. Find sibling cases and counterexamples. Generalize only the verified cause; do not turn a local defect into new policy, requirements, or architecture without supporting evidence. Distinguish a one-off symptom, repeated pattern, missing invariant, unreliable input, and architectural constraint; quantify affected cases when practical.
4. Offer only useful levels of intervention:
   - Fix the immediate instance.
   - Repair other cases sharing the same verified cause.
   - Correct the shared data, contract, abstraction, or workflow.
   - Add a test, guardrail, monitoring, or safe automation.
   - Capture a reusable process, skill, or architectural improvement.
5. Compare expected impact, confidence, effort, risk, reversibility, and dependencies. Recommend based on the user's overall intent; favor simplicity when outcomes are comparable, but surface higher-impact options that become worthwhile with broader scope or authorization. Mark speculation and unresolved cases explicitly.

# G Suite Setup

Configure Google Workspace through the authenticated Admin Console while changing only settings that differ from the requested baseline.

## Required workflow

1. Use the user's authenticated Chrome session. If Chrome automation is blocked by browser UI, use the Computer Use skill to dismiss or work around the obstruction without leaving Chrome.
2. Verify the active Google account, organization, and organizational unit before editing. For Latent Space, target the root `Latent Space` organizational unit unless the user specifies a narrower scope.
3. Read [references/openness-baseline.md](references/openness-baseline.md) before auditing or applying the baseline.
4. Inspect each relevant setting before editing. Skip settings already matching the baseline and report them separately from actual changes.
5. Apply one coherent product area at a time and wait for Google's saved confirmation before moving on.
6. Re-open or re-snapshot changed sections to verify the persisted state. Treat propagation notices as pending, not proof of immediate user-visible behavior.
7. Report three categories: changed, already correct, and unavailable or per-user-only.

# Keep It Simple

Find the simplest implementation that meets the actual requirements. Ask what
concrete requirement justifies each additional mechanism. Simplicity includes
runtime behavior and operational burden, not just source length.

## Review the requested surface

Establish the intended behavior, explicit constraints, and demonstrated failure
modes. Distinguish these from hypothetical future needs and conventions inherited
from templates or other skills. Inspect the relevant callers and execution path;
do not turn a focused review into a repository cleanup.

Trace what a reader must understand and what the system must execute. Look for:

# Latent Space Thumbnail Director

Use `$imagegen` for raster artwork. Read [preferences](references/preferences.md); consult [resources](references/resource-index.md) for assets and [examples](references/example-index.md) for relevant approved work. Apply the FDE template only when that series is requested.

1. Ground ideas in the episode. Review several recent thumbnails on the target channel or series, and compare their composition, type, scale and imagery; distinguish observed patterns from a rigid template.
2. Offer at least four distinct title-and-hook pairs in a table, recommend one, and briefly challenge each. Favor specific, thoughtful sentence-case hooks. Verify any claim, number, guest post, role or milestone. Honor existing choices instead of asking again.
3. For the chosen hook, show distinct visual directions in context alongside recent channel examples, with their tradeoffs. A choice of title or words is not a choice of artwork: obtain visual selection before applying it unless the user explicitly asks you to choose. Independent packaging and private preparation can continue.
4. Build for the episode: one clear idea and a meaningful visual, not generic decorative tech. Show each requested guest and company once, with no unrequested host. Prefer real photo or video-frame cutouts for faces; disclose generated likenesses and inspect fidelity. Use official brand assets, not recreated logos. FDE branding is for FDE episodes only.
5. Inspect full size and at about 320 × 180, including against the channel grid. Check legibility, resemblance, headline, company and guest coverage, contrast, branding, and clearance for YouTube’s bottom-right duration badge. Repair defects; export a 16:9 master and 1280 × 720 JPG.

# Live AI Pipelines

Use this skill when people need to inspect useful work while later work is still running, or reopen a run after interruption. It owns logical stages, artifacts, progress, recovery, and publication—not a particular queue, database, or provider SDK.

Pair with `ai-engineering` when model request/retry/rate-limit behavior is itself the problem. Pair with a provider/runtime skill only for that platform’s current API behavior.

## Useful defaults

- Keep canonical complete artifacts separate from provisional previews.
- Give artifacts and independently resumable items stable IDs.
- Make the UI a projection of stored results and events, not the source of workflow truth.
- Publish a complete new snapshot rather than exposing a half-rendered site.
- Let core output publish with optional enrichment visibly pending unless the user makes that enrichment a completion requirement.

# Location input

Make a location field easy to complete while preserving the person's intended answer. Infer the required precision from the product: “Where are you based?” normally needs a city or country, and current device location may differ from home. Implement only the requested controls; this skill does not authorize deployment or changes to unrelated forms.

## Choose data and controls

- Prefer an editable combobox with manual selection. Keep custom text valid unless the product explicitly requires a canonical place. Do not silently expand an abbreviation or replace text on blur.
- Reuse the project's accessible combobox when suitable. Inspect its current documentation and types before introducing another dependency. React Aria supports `allowsCustomValue`; its async collections can need `allowsEmptyCollection` and an empty/loading renderer so typing before data arrives still opens suggestions.
- For broad city coverage without per-query costs, consider a lazy-loaded local index from GeoNames cities15000 plus countryInfo and administrative-region names. Measure payload size and search responsiveness; avoid bundling the full dataset into initial application JavaScript. A remote service is appropriate when coverage, localization, or geographic precision justifies it.
- Keep the dataset reproducible and attributed under its actual license. A population-filtered list omits small towns and is not a complete geography database. Retain free text for missing locations.
- Build a small explicit alias layer against stable place IDs: SF → San Francisco, NYC → New York City, Bangalore → Bengaluru, UK → United Kingdom. Do not infer arbitrary acronyms or silently map a metro area to its central city. Add alternate names/local scripts when required by the audience.

## Search and selection

# Long-Running Operation UX

Match the solution to the actual user problem. Preserve accumulated workflow
lessons and the preferred stack without making advanced architecture mandatory.

## Activation

Apply this skill when creating or materially changing a user-facing action
that launches noticeable asynchronous work, including batch size, concurrency,
reruns and result handoff. Do not wait for the user to report that it looks
stuck. A backend change affecting a visible operation is in scope; a model
call with no user-facing wait is not sufficient by itself.

## Maturity profiles

# Media Heavy Workflows

Apply only the patterns required by the requested product; a media operation is
not automatically a media studio.

## Behavioral core

1. Inspect the existing media entrypoint, ownership, provider route, and final
   insertion path. Preserve working behavior and the requested interaction.
2. Distinguish saved references from references actually sent to a model. Honor
   the selected endpoint's supported tasks, input schema, and reference limits.
3. When users compare multiple generated candidates, keep batches and selection
   with their owning artifact; snapshot the prompt, model, and references needed
   to explain each result.

# Media to wiki pipeline

Preserve accepted content, update affected entities, publish once, and verify the release at the required coverage. Use this existing workflow for written and mixed-media corpora too; neither a conference archive nor a particular site's output is a prerequisite.

Read the references relevant to the task:

- [Page contracts and quality](references/page-contracts.md) before selecting page types, drafting or accepting a new corpus. It supplies portable editorial defaults, including organization and topic pages; examples illustrate quality rather than substitute for these criteria.
- [Source adapters](references/source-adapters.md) when selecting or normalizing sources. Recording clocks and media recovery apply only to recorded input.
- [Stage and release contracts](references/pipeline-contract.md) when implementing, operating, resuming or refreshing a corpus. Map actual project drivers before repairing them; intended behavior is not proof of implementation.

## Decisions that govern progression

- Freeze source IDs and versions per batch or subset refresh; queue later arrivals separately.
- Resolve identities early, then let source readers, person, organization and topic work proceed independently where their dependencies permit.

# Media Transform

Generic orchestrator for media transformation pipelines. Chains atomic skills based on source and destination, with stage-by-stage checkpoints.

## Architecture

Each pipeline stage is handled by a dedicated atomic skill. This orchestrator provides:

1. **Stage selection** — which steps to run based on source/destination
2. **Preferences** — battle-tested defaults and known gotchas
3. **Learnings** — what worked, what didn't, what to avoid
4. **Checkpoints** — present plan, get confirmation, then execute

## Atomic Skills

# Mobile Native

Native UX, implementation pitfalls, delivery, and playtesting belong together.
Platform operations here cover iOS/iPadOS; Android procedures are not established.

## Selective references

- UI/product choices: [preferences](references/preferences.md) and
  [native UX](references/native-ux.md). General aesthetics live in
  [design-preferences](../design-preferences/SKILL.md).
- Generated configuration, signing, install, launch:
  [iOS/iPadOS delivery](references/ios-ipados-delivery.md).
- Device QA, XCTest, accessibility findings, screenshots:
  [verification](references/verification.md).

# Mobile Web-App UX

Treat the phone as a distinct task surface, not a narrower desktop canvas. Preserve the desktop contract unless the requested behavior genuinely differs.

Apply this skill to the requested mobile loop and the responsive states closest
to it. The patterns below are recommendations unless accessibility, reachability
of the primary action, or prevention of data loss makes one blocking. A mobile
review is read-only unless implementation was requested. Stop when the named
loop works at the agreed narrow viewport and its existing desktop counterpart;
report unrelated redesign opportunities separately.

## Start with the mobile task loop

Identify the smallest repeated loop the user needs to complete: inspect → decide → act; scan → filter → open; compose → send. Make that loop dominant in the first viewport.

# Multimodal Extraction

## Overview

This skill composes the existing video workflows into one artifact:

- `download-video` for URL inputs
- `thumbnail-extraction` for slide frames and key screenshots
- `transcribe-anything` for transcript strategy

The implementation is intentionally speed-first:

1. Download only when the input is a URL
2. Reuse the fast slide/key-frame heuristics from `thumbnail-extraction`

# New Mac Setup

This skill generates and runs a complete, idempotent Mac setup for fullstack web development and AI engineering. It produces 8 shell scripts that can be run individually or via a master runner, plus dotfiles and macOS preference automation.

The scripts are designed to be re-runnable — they check whether each tool is already installed before attempting installation, so you can safely run them again if something fails partway through.

## Philosophy

The setup is opinionated. The core opinions:

- **Terminal**: Ghostty (fast, GPU-accelerated, Zig) + cmux (vertical tabs, split panes, socket API for AI agents). cmux reads Ghostty's config, so one config file serves both.
- **Shell**: ZSH with Oh-My-ZSH, powerlevel10k theme, zsh-autosuggestions, zsh-syntax-highlighting
- **Node**: fnm (not nvm — fnm is faster), pnpm and bun for package management/runtime
- **Python**: uv from Astral (not pyenv, not pip, not conda — uv is dramatically faster and handles both venvs and package installs)

# Next Steps

Do the useful thinking before presenting the menu. Help the user discover and choose opportunities, not merely maintain a task queue. Lead with a point of view about the outcome and what could move it forward.

## Orient without reciting the conversation

Use the available context to recover the user's outcome, corrections, accepted choices, constraints, and unresolved questions. Newer decisions supersede older proposals. Do not reactivate abandoned work or ask the user to reconfirm settled preferences.

Keep completed work, user-reported changes, verified live state, proposals, and blockers distinct. Put routine operational status in a short line or expandable detail; let it dominate only when it genuinely blocks progress or presents material risk. Avoid ritual intent/confidence statements and repeated recaps.

## Discover before recommending

Do a bounded read-only evidence pass when it could change the options or their ranking. Inspect readily available project data; browse relevant current primary sources, credible practitioner examples, or competing approaches where useful. Bring back an actual finding, example, or comparison instead of turning every answer into a proposal to research later.

# Observability Hardening

Use this skill when the product works but failures are opaque. The output should make production behavior explainable without leaking private data.

## Counterweight: questions before telemetry

- Start with the operator or user question that cannot currently be answered. Add no signal without a named consumer and decision.
- Inspect provider-native logs, metrics, traces, request IDs, and dashboards before building parallel telemetry.
- Choose the cheapest sufficient signal. Do not add logs, metrics, traces, dashboards, alerts, analytics, and user-visible state as a bundle.
- Instrument ownership boundaries and material state transitions, not every function or phase.
- Prefer a saved query or clearer existing event over a new pipeline, schema, SDK, collector, or dashboard.
- Budget cardinality, volume, retention, latency, privacy, and on-call noise. More telemetry can make diagnosis worse.
- Add an alert only when someone owns a concrete response. Add user-visible progress only when users must wait or act.
- Do not turn a local debugging gap into a repository-wide observability program or product analytics redesign.

# Person profile writing

Produce an accurate account of a person and why their work matters. Apply
`research-grounded-writing` to the evidence and `swyx-writing` to the prose.
This skill owns the identity and biography-specific decisions.

## Establish who the subject is

Build an evidence packet when important facts remain uncertain:

- Start with the person's own site and verified profiles, official employer or
  founder pages, company announcements, owned repositories, authored work,
  recorded talks, and available transcripts.
- Use substantive posts from independently verified accounts when they clarify

# Podcast publishing assistant

Resume the existing episode and requested deliverables, reusing approved media,
copy, transcripts and overlay sources. Preserve user edits. Keep the current
master/version, edit map, approved angle/cover, destination IDs and release states
in the existing episode record, not a second tracking system.

Use `swyx-writing` for editorial copy, not verbatim transcripts or speaker labels.
Route missing ASR to `transcribe-anything`, edits and annotations to
`annotated-video-production`, and LS artwork to `latent-space-thumbnail-director`.
Prefer source audio; captions serve an explicitly requested rough pass. Anonymous
ASR labels do not establish named identities. Publishing consumes the approved
edit; it does not silently introduce editorial cuts.

# Productionize App With Services

Use this skill when a working prototype needs a specific, user-selected set of product services. Productization is not a checklist of everything a mature SaaS might contain.

Use this skill to coordinate several named product-service gaps. For one narrow capability, use ordinary implementation or the corresponding narrower skill.

## Counterweight: earn every service

- Start from users, callers, incidents, and operating constraints. Name the concrete need before adding a service or control.
- Prefer the repository's existing stack and provider capabilities. Do not introduce Postgres, hand-rolled auth, PostHog, OpenAPI, API keys, feature flags, audit logs, admin UI, dashboards, or a public agent guide by default.
- Add the smallest service that closes the named gap. Avoid building extension points, bulk APIs, role systems, or management surfaces for hypothetical consumers.
- Use one authoritative identity and action path where practical, but do not create a shared action layer merely to satisfy the pattern.
- Prefer deletion, configuration, or a provider-native feature over a new subsystem.
- Do not treat security, observability, auditability, API access, and agent friendliness as inseparable. Select only the requested dimensions.

# Programmatic Agents

Run the user-requested model through its selected coding-agent CLI without silently substituting another model. Treat coding-agent login, subscription access, and provider API access as separate authorization surfaces.

Special preview model identifiers must be supplied by the user for the current task. Do not name, suggest, hardcode, or infer preview identifiers from prior sessions or local availability. Keep reusable examples generic, using placeholders such as `$MODEL_ID`.

This skill covers agent invocation and execution mechanics. When building an orchestrator with multiple stages, shared resources, batch joins, or durable resume, also consult [live-ai-pipelines](../live-ai-pipelines/SKILL.md); consult [ai-engineering](../ai-engineering/SKILL.md) for admission, retries, concurrency, and timing. Provider adapters do not substitute for workflow dependency design.

## Choose the execution surface

Use the coding-agent CLI selected by the user or existing workflow. Check its
installed capabilities, authentication, permissions, and output format; do not
silently substitute another CLI or model.

# Provision model keys

Make the requested app work using its own named key and the approved starter allowance.

## Saved authority

Read [authorization.md](references/authorization.md). A matching active grant permits complete setup without further approval: provider project/workspace, key, secret installation, app permissions, a small synthetic paid test, budget warnings and runtime enablement. Rotation/repair stays within the same scope and allowance. Future apps qualify only when the user requests them under the approved repository owner, provider accounts and destination templates.

Default proposal: **USD 5 per app per month, USD 50 aggregate per month**. Once granted, renewal and small spending within that allowance require no new authorization. Budget raises, credit purchases and auto-recharge require explicit approval. Trust the user-approved private grant record; revisit its source only if provenance or scope is unclear. Current user restrictions override it.

## Names, permissions and storage

Use `<app>-<env>-<provider>`, e.g. `notes-dev-openai`. Add purpose when it distinguishes multiple keys; add owner when identity would otherwise be ambiguous. Keep repository, provider account, project/workspace and key IDs in metadata; names do not enforce scope.

# Public Q&A Chatbot - Best Practices

A comprehensive skill for building unauthenticated, public-facing Q&A chatbot widgets on marketing sites, conference pages, documentation portals, and similar contexts where you need to serve anonymous visitors while controlling cost and abuse.

Use this as a design and review catalog, not a requirement to add every listed
service or subsystem. Select controls for the public exposure, cost, privacy,
and UX risks created by the requested change. Server-side secret isolation,
server-authoritative enforcement of abuse limits, and safe handling of user
content are invariants where those boundaries are touched. Caching, vector
search, tracing, virtualization, voice, and multi-layer infrastructure are
recommendations or opportunities unless the requested scale or failure mode
makes one necessary. Stop when the named widget behavior is usable and its
concrete public-abuse/cost risks are bounded; report adjacent improvements as
follow-ups.

# Pulp Fiction Writing

Use this skill to make a story difficult to put down without making it shallow. Favor clarity, velocity, emotional legibility, and consequential turns over ornamental prose.

## Core contract

- Open with a person wanting something now.
- Put pressure on that want within the first scene.
- Make every scene change the situation, the relationship, or the reader's understanding.
- Keep the prose transparent enough that the reader never loses the action.
- End chapters with a changed question, a difficult choice, a reveal, or a new problem.
- Prefer specific, concrete details over generalized description.

## Build the story engine

# Release Readiness Hardening

Use this skill to answer: can this ship safely, and what is the smallest sufficient proof? Treat every gate, identity, queue, receipt, and manual step as operational cost.

## Counterweight: simplify before adding

- Start from current callers, stored data, provider facts, and failure history. Do not preserve machinery merely because it exists.
- Inventory existing controls before proposing new ones. Delete, combine, or narrow controls that duplicate the same authority or fact.
- Add a gate only for a concrete material failure mode not already covered. Record why a cheaper existing signal is insufficient.
- When one trusted system builds, deploys, and observes production end to end, do not invent signatures, admission ceremonies, or proof handoffs between its internal stages.
- Prefer authoritative external facts—exact source, immutable provider version, traffic, health, and rollback target—over duplicated internal evidence.
- Do not create bookkeeping PRs, proof PRs, smoke commits, or known-impossible release attempts solely to exercise release machinery.
- For self-hosting CI/CD changes, validate with the currently trusted base configuration, then reload the merged configuration after merge. Do not require a new workflow to authorize the change that introduces it.
- A typed pre-mutation failure is a valid safe outcome. Stop, preserve the failure and unchanged production state, and identify the smallest real fix; do not manufacture source changes to obtain different evidence.

# Report Progress, ETA, and Analyze

Use existing plans, process state, logs, results and timing receipts to explain how close the authorized outcome is to completion. Refresh cheap, time-sensitive evidence when available; distinguish current observations, older receipts, estimates and unknowns. Reuse the existing run artifacts rather than introducing another ledger or telemetry system.

## Establish progress and remaining work

Report the state of the whole authorized outcome, not just the last command or heartbeat. Lead with what is complete, what remains and the current bottleneck. Distinguish generated, accepted, released and live-verified output. When work has separate deliverables, such as a code release and a content pilot, give each its own state and forecast. Counts of passing tests or completed model calls are supporting evidence, not a percentage of the whole task.

Name the completion boundary being forecast: for example, private review ready, approved release, or live verified. User validation time is separate from processing time. Label every remaining count with its stage and denominator: “writing 0 remaining; assembly 25/66 remaining; final QA pending.” Never show an unqualified “0 remaining” while required downstream work remains. Reused approvals count only for their qualified scope; an automated pass is not manual inspection.

## Use past runs as forecast data

Before the first forecast, make a bounded lookup of comparable past runs in existing timing reports, stage receipts and completion records. Refresh that lookup when the remaining bottleneck changes. Prior forecast text is not an actual duration: prefer timestamped stage transitions and verified completion receipts. If history is unavailable, say what was checked; do not silently substitute intuition when usable records exist.

# Research-grounded writing

Support substantive claims in the requested artifact. Keep research proportional
to what the reader needs to assess the conclusions.

## Build the evidence

- Prefer direct records and primary sources. Add independent sources when they
  supply relevant criticism, corroboration, or a competing explanation.
- Distinguish direct observation, source claims, user-supplied context, and
  inference. Label uncertainty that could change the conclusion.
- Include dates, versions, sample, and coverage when they limit what a source
  proves. Missing evidence is not a zero result or proof of absence.
- Consider contrary evidence when it could overturn a material claim; do not

# Reserved Handle Policy

Use this skill to protect a public handle namespace without turning a broad list into an unexplained permanent ban.

## Start with the policy model

Separate two kinds of restriction:

1. `hard_reserved`: platform routes, authority terms, security identities, and service names that users must never claim.
2. `manual_claim_required`: scarce or impersonation-prone names that an administrator may assign after identity review.

Do not report both as merely `taken`. A caller needs to distinguish an existing account, a permanent platform reservation, and a claim that can be reviewed.

Read [rationale.md](references/rationale.md) before changing the tiers or source cohorts. Load [reserved-handles.toml](references/reserved-handles.toml) only when implementing, auditing, or inspecting the concrete list; it is intentionally kept out of the default context because it contains thousands of names.

# Resilient Computer Use

Run UI automation as a repeated **observe → identify → act → re-observe → verify** loop. Never equate tool context with application reality: a lost binding, empty accessibility tree, or stale element index does not prove the app, window, tab, or user state disappeared.

## Chrome default: bind to a tab

The user keeps using Chrome while agents work and runs multiple Codex browser sessions concurrently. Default to tab-bound Chrome control by stable tab ID. Keep observations, screenshots, clicks, typing, navigation, and any network/CDP capture scoped to that tab handle. Do not use the frontmost Chrome window, active tab, window position, or global keyboard shortcuts as the target for ordinary browser work.

- Give each chat its own named browser session and dedicated tab; reuse that chat's binding throughout the task. Claim an existing tab only when it is the intended target and another chat is not operating it. Do not take over another chat's tab.
- A separate tab or window does not isolate cookies, login, or account state within the same Chrome profile. Coordinate account switches and sign-outs that could affect other work; do not change profiles silently.
- If the binding fails, refresh the tab inventory, recover the exact tab, and read the adapter's troubleshooting before switching to desktop control. A failed create-tab command does not prove existing tabs cannot be claimed.
- Native desktop control is a fallback for unsupported native dialogs or a binding that cannot be recovered. Before using it, explain that it requires shared focus and coordinate a brief exclusive interval with the user or other authorized chats. Stop if focus changes, then return to the tab handle as soon as possible. Do not repeatedly steal focus to continue a background task.

## Model the layers separately

# Review thread

Give a concise, candid assessment of progress toward the user's intended outcome. Keep reporting lightweight and continue authorized work.

## 1. Progress and direction

Infer what success means to the user; state consequential assumptions. Explain what now works, what remains, and what is verified. Distinguish implementation, passing tests, and actual user-visible success.

Assess whether we are fixing the right problem:
- What can we remove without weakening the outcome?
- What must we add to fully satisfy the use case?

Use independent judgment: do not invent scope problems to agree with the user. Recommend concrete corrections when warranted, and correct earlier claims plainly. Report outcomes rather than tool-call chronology.

# Cloudflare Sandbox SDK

Use current Cloudflare docs and the installed package as the API contract. The
SDK and its container topology evolve quickly; inspect package exports, types,
Wrangler schema, and generated configuration before coding.

## Establish the isolation contract

Identify:

- who chooses the sandbox ID and how it is scoped to a tenant or session;
- which code, files, environment variables, and network access are untrusted;
- what must survive container sleep or recreation;
- which operations need a shared session versus isolated execution; and

# Schedule Design Patterns

Lessons extracted from building the `/europe/schedule` page — a single-file (~2000 line) React component with a 2D room×time grid, 1D session list, modal detail view, multi-axis filtering, favorites, theming, and semantic search.

## Architecture

### Single-file component is fine for schedule pages
The entire page lives in one `.tsx` file. Sub-components (`TypeBadge`, `SpeakerPhoto`, `SessionModal`, `GridOverview`, `SessionCard`, `FilterPill`, `StarButton`) are defined in the same file. This avoids prop-drilling across module boundaries and keeps the schedule self-contained. Extract to separate files only when reuse is needed elsewhere.

### Build-time data extraction with `getStaticProps`
Raw JSON (with nullable/optional fields) is normalized at build time into clean `ScheduleSession` objects with guaranteed string fields (empty string, not null). This eliminates null checks throughout the render logic.

### Synthetic plenary sessions
Plenary/logistics sessions (breakfast, lunch, expo hours) are hardcoded as a `PLENARY_SESSIONS` array and merged with speaker sessions at build time. They get `id: 10000 + i` to avoid collisions.

# Security Hardening

Use this skill for pragmatic appsec work that produces prioritized fixes and residual-risk notes. Do not turn it into a compliance theater exercise.

## Counterweight: threat before control

- Start with assets, trust boundaries, attacker capability, exposure, and plausible abuse paths. Do not apply the checklist uniformly.
- Add or change a control only for a concrete reachable risk. Record when framework or provider defaults already cover it.
- Prefer removing exposure, privilege, data, or code over adding middleware, policy layers, scanners, and monitoring.
- Do not add rate limits, CORS/CSRF machinery, headers, runtime schemas, encryption, secret rotation, or dependency upgrades where the threat model does not require them.
- Preserve one authorization source of truth; do not duplicate permission checks across artificial layers.
- Avoid speculative findings based only on pattern matches. Confirm actual callers, deployment topology, and runtime behavior.
- Keep fixes focused. Do not turn one vulnerability into a repo-wide security program, compliance project, dependency refresh, or release ceremony.
- A scoped review may correctly conclude that no code change is needed. Report accepted and out-of-scope risk plainly.

# Sessionize Automation

Use this skill for Sessionize organizer tasks where there is no supported public
API and the useful write surface is the authenticated web app.

## When To Use

- Bulk accept, decline, waitlist, queue, or nomination status changes.
- Tracing Sessionize organizer pages to discover private form or XHR endpoints.
- Automating speaker/session invite flows that only exist in the logged-in UI.
- Reconciling local review decisions against Sessionize session IDs.
- Verifying that Sessionize-side counters and row states changed correctly.

Do not claim Sessionize has an official organizer API unless you have verified a

# Skill Cutter

Reduce context cost and accidental activation without weakening the behavior the
skill exists to provide. Treat line count as evidence, not the objective.

## Choose the mode

- **Audit:** When asked to review, critique, or identify cuts, inspect and report
  without editing.
- **Cut:** An explicit request to cut, trim, shorten, simplify, or de-slop the
  skill authorizes local edits within that skill. It does not authorize commit,
  push, publication, or changes to consumers outside the requested scope.

## Find the behavioral core

# Slackbot Builder

Use this skill when creating or hardening Slack apps, Slack bots, agent-in-Slack
workflows, or production Slack integrations.

This skill has two routing modes:

- **Lifecycle work:** use the maturity ladder for greenfield builds, broad audits,
  or upgrades that change the bot's operating level.
- **Bounded capability work:** load only the reference for the named behavior and
  any lower-level contract the change actually touches. Do not read the whole
  maturity ladder for a search bug, rendering fix, or isolated tool integration.

## The one rule that survives every level

# Smart Entity Resolution

Resolve identities at the lowest level of effort that establishes a reliable answer. Escalate only when existing identifiers, mappings, or corroborating evidence are insufficient. This skill applies to genuinely ambiguous person and organization records, including competing profile or media candidates; ordinary image handling and deterministic ID joins do not require it.

## Core Principle

Treat entity resolution as a staged investigation, not a lookup. Exact search, slug lookup, popularity, and LLM judgment are all useful signals, but none should silently dominate the others.

Separate three questions:

- Coverage: did we enumerate all requested entities?
- Identity: does this candidate represent the requested person or organization?
- Utility: is this the best usable record for the task?

# Summarize Anything

Recursive map-reduce summarization for arbitrarily long text, with pluggable LLM backends and a wide variety of output formats.

When the requested output is reader-facing prose or publishing copy for swyx,
apply `swyx-writing` after the factual reduction step. Keep extractive summaries,
quotations, timestamps, and structured data faithful to the source rather than
rewriting them into a voice.

## Setup

### Required

```bash

# swyx writing

Write so a smart reader can understand the point once, remember the useful
model, and decide what to do next. Preserve the author's real judgment and the
messiness that earned it. Do not imitate a generic founder, marketer, or
technical-blog persona.

This skill owns voice, explanation, and editing. Pair it with the skill that
owns the facts or format:

- use `research-grounded-writing` when claims require external or primary
  evidence;
- use `ai-devblog` for technical story selection and publication;
- use `ai-readme` for executable repository documentation;

# Sync Accelevents Speaker Data (Europe)

Pulls speaker headshots and social data from the Accelevents API into the Europe conference schedule.

## Prerequisites

- `ACCELEVENTS_API_KEY` environment variable must be set (stored as a Devin secret)
- Python 3 with Pillow installed (`pip install Pillow`) for image optimization

## Steps

1. **Checkout a new branch**
   ```bash
   cd /home/ubuntu/repos/aiecode2025

# Sync URL to navigation and filter state

## User preference

**Always keep meaningful UI navigation and filtering state in the URL** (query params). Reloading, sharing, or opening a link should restore the same screen—not only the top-level route.

The user expects this by default on web apps unless they say otherwise.

## What to put in the URL

| State | Include when |
|-------|----------------|
| Active view / tab / mode | User can switch between distinct screens |
| Sub-navigation (sidebar table, nested tab) | Second-level nav exists |