Kind: skill

Compiles MUST/NEVER/CHECKLIST rules from skaile-development SKILL.md files into fast, deterministic Python validators. Generates a validator.py alongside each SKILL.md. Replaces slow LLM-based validation with sub-second structural checks. Run after editing any skill in ai-assets/skaile-development/skills/.

[skaile-development] Scaffold a new dynamic web component for the Agent App Protocol. Generates COMPONENT.md, web component JS, agent-usage.md, and test harness in the components directory.

Use when a concept has no _concept/brief.md yet, or the user wants to redefine one. Writes the pitch (with its comparables), the goals — the two root files everything downstream reads — and the first feature ideas in the roster. Triggers on 'I have an app idea', 'new project', 'start from scratch', 'redo the brief'.

Use when the product's words are not pinned yet, when another skill has appended proposed terms, or when a concept has no term. Derives the domain vocabulary and its light ontology from what exists, settles the gaps with the user, and writes the glossary every journey, feature, screen, model and test then names things from — in `_concept/glossary.md`, with the definitions in the project's own `CONTEXT.md` when it keeps one. Triggers on 'pin the vocabulary', 'what do we call this', 'write the glossary', 'we use two words for the same thing'.

Use at the start of a project to capture what the pipeline needs and the user already knows — technology preferences, an existing brand, the material they are bringing with them. Also when they say 'I have existing docs', 'use these files', or an answer needs someone who is not in the room. Triggers on 'onboard', 'set up the project', 'ingest my seeds'.

Use when a decision needs grounding in something other than the room's opinion — the domain, the competitors, the audience, or the visual references screens will be designed against; run it once for the project and again beside any step that needs more. Triggers on 'research this', 'what do competitors do', 'find inspiration', 'who are the users really'.

Use when the code already holds a fact the concept needs, or a repository exists and the concept has to be extracted from it rather than designed. Reads the routes, screens, schema, stack, brand, interaction surfaces and docs of the requested scope, and writes what the code actually says as graded, freshness-stamped findings the owning skills seed from. Triggers on 'reverse engineer this project', 'extract the concept from this codebase', 'document this existing app', 're-read the screens from the code'.

Create, customize, batch-produce, or rebuild Skaile presentations as self-contained HTML and PDF with the installed @skaile/decks runtime. Use for pitch decks, consulting reports, reusable slide libraries, storyline-to-slide production, and edits to existing decks artifacts.

Integrated deep research skill that collects documents from multiple sources, stores them in organized folders, and synthesizes findings into a comprehensive research report with citations.

Use when the project has no visual identity yet, or the user wants to change it. Discovers a direction in plain language, extracts from reference sites, and writes the palette, tokens and brandbook; a brief sharpens it and is not required. Triggers on 'brand', 'colors', 'fonts', 'design tokens', 'make it look good'.

Maintains the human-readable _devlog of the standalone skaile repo a change landed in (workspaces: packages/workspaces/_devlog/). Writes short plain-language entry files to _devlog/entries/ after every meaningful change. Generates detailed reports in _devlog/reports/ when architectural concepts, shared contracts, or core patterns change. Run after completing any implementation work.

Use when writing new documentation, updating stale docs, auditing for gaps, or checking documentation status in the skaile-dev monorepo. Covers all five doc tiers: README.md, CLAUDE.md, Starlight docs, DOMAIN.md/SKILL.md, and _devlog.

Run, fix, or extend the Skaile platform e2e suite. Three modes: `run` executes the existing suite with pre-flight checks (stale-service guard for post-pull stale bundles, stale-deps guard for lockfile drift, seed sync, proxy slot health), failure-mode diagnosis, and auto-recovery (kill stale skaile-serve subprocesses, sync seed data, restart stuck proxy slots); `fix` triages each failing test as a stale test (the product changed on purpose) vs a real regression (the product broke), then repairs stale tests (rewrite to the new shape / delete a removed feature / skip with a reason) while STOPPING and escalating regressions to the human — never weakening an assertion to force green; `add` analyzes a git diff, proposes a test plan, waits for explicit user approval, lives-inspects the UI via chrome-devtools MCP, then writes new specs against the existing harness in the platform repo's `e2e/` directory. Use when the user says "run e2e tests", "fix the failing e2e tests", "the e2e suite is red", "add e2e coverage for <feature>", "write e2e tests for my PR", or similar.

Use when an entity's lifecycle has enough states that prose stops being precise about it. Writes the state machines and rules the feature specs and the screens are built against. Triggers on 'state machine', 'behavioral rules', 'formalize the lifecycle', 'what states can this be in'.

Use when the app's interaction rules are not written down yet — navigation model, where information lives, one editor per object, inline vs dialog vs page, information tiers, saving, messages, popups, buttons, search and command palette — or when a code check has proposed changes to them. Adopts the rulebook's defaults with the user, decides what remains in batches and writes APP-DESIGN.md. Triggers on 'write the app design', 'APP-DESIGN.md', 'when do we use a modal', 'UI rules for this app', 'interaction decisions'.

Use when nothing has mapped what users actually do yet. Defines the personas and the staged story map that features are derived from; a brief or the code's routes ground it, and the user's description is enough. Triggers on 'map the journeys', 'user stories', 'what do users do', 'story map'.

Use when one screen needs specifying on its own — a screen already built in the code, a screen a feature needs, or a layout to try before anything is specified. Derives it from the findings or asks, picks the floorplan, posture and density, binds regions, records tier overrides and can show the layout early as a Storybook story. Triggers on 'describe this screen', 'spec the inbox screen', 'which layout fits this', 'show me this screen', 'try two layouts'.

Use when the app needs its frame — the shell frame, the navigation model it realises, the one list of destinations, and the layout patterns every screen reuses. Works with or without features and screens, from the code's own routes when they exist. Triggers on 'app shell', 'navigation structure', 'sidebar or top bar', 'what does the layout look like', 'design the frame'.

[skaile-development] Evaluates resolved questions about the skaile-dev monorepo for FAQ-worthiness and curates entries. Broadened to all monorepo packages.

Git operations for the standalone skaile repos (platform, workspaces, ai-assets, store, brand, …). Five modes: commit (structured commit messages), branch (create/switch feature branches), worktree (parallel work in isolated checkouts), pr (open a pull request), finish (merge/PR/keep/discard branch). The former sync and deploy modes served the retired skaile-dev shell and now stop with a pointer.

The morning startup ritual for skaile-dev — opens with a cheeky "what did Peter do last night" investigation of the repo state, syncs the shell repo + submodules (reattaching any that landed detached at origin/main), reinstalls workspace deps, and builds the platform backend so frontend + backend are ready to start. Does NOT launch dev servers — Peter starts those himself. Use when Peter says "good morning", "/good-morning", "let's start the day", "fire up the platform", "boot me up", or any other morning kick-off phrase.

Monorepo-aware implementation orchestrator for the skaile-dev codebase. Reads the affected package CLAUDE.md files, identifies the tech stack, routes to the right prog-experts, produces a plan, executes with supervised dispatch, then triggers test, doc, and devlog on completion. Use for any non-trivial change to the skaile-dev monorepo.

[skaile-development] The bar a ticket must clear to exist: six impact questions (user harm, money, stability, security, team drag, significant benefit), each answered with evidence. Use before filing an issue an agent found on its own (a ship follow-up, a review leftover, an audit finding), when triaging incoming issues, or when sweeping an existing backlog for tickets that can be closed. Returns KEEP / CLOSE / ASK per ticket with the evidence, and a ready-to-post close comment.

[skaile-development] Debug a recently failed Skaile deployment on Jenkins. Defaults to the `skaile_platform` job; pass `target=store` to debug the `skaile_store` job instead. Reads the job over the local SSH tunnel (http://localhost:8090, anonymous read), finds the relevant build (last failed by default, or current/explicit), extracts the failure region from the console log, cross-references recent commits in skaile-dev around the build timestamp, and reports a structured summary with a fix hypothesis. Use when the user says "why did the deploy fail", "debug the jenkins failure", "what broke on jenkins", "the platform deploy is red", "the store deploy is red", "check the last platform-deploy", or otherwise asks about a Jenkins deployment failure.