ワンクリックでManusで任意のスキルを実行

validate-configs

スター17

フォーク5

更新日2026年7月14日 12:40

Use when you touch Tale file-based org config or its guards — builtin-configs/, e2e fixture config trees, CONFIG_DOMAINS, Zod schemas under lib/shared/schemas/, app bundles under builtin-configs/apps/, or a red builtin-configs, builtin-apps, email-parity, fixture-drift, or migrations:check gate. Owns which gate proves what, validator registration, enforcement postures, and the snapshot-vs-migration ritual. Run the matching gate before shipping; never duplicate a shape a shared schema already owns. For tests use test-code; for failing behaviour use fix-bug.

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

tale-project

tale-project/tale

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

関連職種SOC

SOC 職業分類に基づく

ソフトウェア開発者コンピュータ・数学職·SOC 15-1252

ファイルエクスプローラー

2 ファイル

SKILL.md

readonly

このリポジトリの他の Skills

同じリポジトリ

produce-video

tale-project/tale

Use this skill whenever you produce, re-record, or localize a docs tutorial video — a new episode, a new locale of an existing one, a narration or choreography change, a voice/TTS change, or a red `videos` gate in services/docs/tests. It owns the production discipline end to end — storyboard-first authoring under services/platform/tests/docs-videos/episodes/, the billed ElevenLabs TTS stage and its cache, the planned-timeline recorder and its ±100 ms drift gate, the shared demo-org contract, the docs embed set (mp4+vtt+poster ×3 locales), and the watch-it QA gate. Load it before touching services/platform/tests/docs-videos/ or anything under services/docs/public/videos/. Never hand-record, hand-edit, or hand-place a video — every committed asset comes out of `bun run docs:videos`. For still screenshots use write-docs (its SCREENSHOTS.md); for the docs pages around the video use write-docs; for de/fr narration follow write-translations.

2026-07-1917

write-automation

tale-project/tale

Use this skill whenever you create or update an automation in a Tale organization — the installable bundle that groups workflows, agents, views, integrations, and configuration behind one manifest. Triggers include: "build an automation", "package these workflows and agents", "add a view or config field to an automation", or "make X installable". Never author a bundle without it — and never create one before listing the existing automations and ruling out extending one. For the pieces inside the bundle, use write-workflow, write-agent, write-skill, and write-integration.

2026-07-1417

write-workflow

tale-project/tale

Use this skill whenever you create or update a workflow in a Tale organization — a trigger→steps definition that runs on an event, on a schedule, or on demand. Triggers include: "automate this task", "build or edit a workflow", "run X every morning", "when Y happens, do Z", or an automation that needs a new process. Never author a workflow definition without it — and never create one before listing the existing workflows and ruling out reuse. The installable bundle a workflow lives in is an "automation" — for the bundle use write-automation; for the agents acting inside a step use write-agent.

2026-07-1417

pptx

tale-project/tale

Use this skill any time a .pptx file is involved in any way — as input, output, or both. This includes: creating slide decks, pitch decks, or presentations; reading, parsing, or extracting text from any .pptx file (even if the extracted content will be used elsewhere, like in an email or summary); editing, modifying, or updating existing presentations; combining or splitting slide files; working with templates, layouts, speaker notes, or comments. Trigger whenever the user mentions "deck," "slides," "presentation," or references a .pptx filename, regardless of what they plan to do with the content afterward. If a .pptx file needs to be opened, created, or touched, use this skill.

2026-07-1317

author-skill

tale-project/tale

Use this skill whenever you author, edit, rewrite, split, merge, or move a skill — a Tale-specific repo-dev guide under .agents/skills/, a generic workflow skill whose source of truth is builtin-configs/skills/ and is projected into .agents/skills/, or a product-only skill under builtin-configs/skills/. It covers the description-as-invocation rule, the canonical SKILL.md skeleton, progressive disclosure, the five failure modes to prune against, leading words, which home a skill belongs in, and the AGENTS.md index + PROJECTED_SKILLS allowlist + sync every skill ships with. Load it before touching any SKILL.md, and never hand-edit a generated .claude/skills mirror or a projected .agents/skills copy.

2026-07-1317

visual-aspect-analyzer

tale-project/tale

Run this as the FINAL review step once you have finished a UI change you can load in a browser — it is the visual-regression gate, run once at the end (not after every edit), and the change is not done until it reports `score: 100`. It drives a real browser over the page, auto-detects its relevant elements (no selectors), labels each by ARIA role + accessible name, and reports which changed the rendered frame, what each is anchored to (screen/page/ancestor), and what transition defects (layout-shift, flicker, jank, dithering) occurred, with a 0–100 score. Run `bun src/analyze-cli.ts <url>` for a lean JSON report (`--full` for the faithful record). Also read before resolving what an element is anchored to, or editing the instrument, analysis, or element auto-detection in this directory.

2026-07-1317

name

validate-configs

description

validate-configs

Per-org configuration is JSON files under $TALE_CONFIG_DIR/<org>/<domain>/, seeded from the builtin-configs/ catalog and validated by one shared Zod schema per domain in lib/shared/schemas/. This skill owns running and extending those guards. Editing a skill bundle's content is author-skill; writing tests generically is test-code.

When this applies

Editing or adding any file under builtin-configs/ or the fixture org trees services/platform/tests/e2e/fixtures/config/{default,qa-guides-org}/.
Adding a domain to CONFIG_DOMAINS (lib/shared/config/registry.ts) or editing any schema under lib/shared/schemas/.
Authoring or refreshing an app bundle under builtin-configs/apps/<slug>/.
A red gate — the universal suite, builtin_apps, email_bundle_parity, fixture_bundle_drift, or migrations:check.

The gates — run what you changed

All vitest gates run from services/platform/; migrations:check from the repo root.

You changed…	Run
catalog / fixture JSON in any non-`apps` domain	`bunx vitest --run --project server lib/shared/config/builtin_configs_validation.test.ts`
an app bundle (manifest, views, messages, wf, agents)	`bunx vitest --run --project server convex/workflow_engine/helpers/validation/builtin_apps.test.ts convex/apps/email_bundle_parity.test.ts convex/apps/fixture_bundle_drift.test.ts`
any schema under `lib/shared/schemas/`	`bun run --filter @tale/platform migrations:check`

The universal suite is registry-driven — it walks every CONFIG_DOMAINS domain over builtin-configs/ plus both fixture org trees with the same schemas the platform load path uses. Its header doc carries the walker details; read it before touching it.

The same walk also runs as bun run --filter @tale/platform configs:validate (plain Bun, no vitest) — wired into the platform build script and a CI step in build.yml so a broken builtin catalog fails the image build, not just the test job — and, non-fatally, post-deploy via the validateBuiltinCatalog internal action (convex/lib/config_store/validate_builtin_catalog.ts), which walks the deployed $TALE_CONFIG_BUILTIN_DIR and logs any issue loudly without blocking boot.

The rules

One schema, every consumer. The loader (convex/<domain>/file_utils.ts), the write/publish path, and the CI gate all import the domain's schema from lib/shared/schemas/ — a hand-rolled twin drifts silently and validates nothing (reviewer-caught; inside the gates it's structural — they import the shared schemas).
Every domain declares a validator. A CONFIG_DOMAINS entry with no DOMAIN_VALIDATORS entry fails the suite with "add a validator" — new domains cannot ship an unvalidated catalog. The walkers + DOMAIN_VALIDATORS registry live in catalog_validator.ts (also driving the build-time configs:validate gate and the post-deploy runtime check); the vitest suite (builtin_configs_validation.test.ts) is a thin wrapper over it.
Enforcement posture follows the path. Publish/upload throws ConvexError codes — INVALID_VIEW, VIEW_BINDING_NOT_ALLOWED, VIEW_ROLE_UNKNOWN, INVALID_MANIFEST in convex/apps/bundle_parse.ts — so a broken file never reaches an org's disk. Discovery degrades visibly — warn+skip a bad manifest, surface a bad view as an { id, error } repair stub, never a silent drop and never a failed list (convex/apps/file_actions.ts). Match the posture of the path you're on.
Schema change ⇒ snapshot ritual. migrations:check fingerprints every schema against convex/migrations/config.snapshot.json. Data-safe growth (new optional field, widened enum, removed field) → refresh with bun run --filter @tale/platform migrations:snapshot. Data-incompatible (new required field, retype, narrowed enum/literal, optional→required, tightened constraint) → ship the versioned migration FIRST — scaffold with bun run gen:migration and follow convex-migrations (enforced by migrations:check).
Fixtures track builtins byte-for-byte. A builtin app-bundle refresh re-syncs its pinned copies in both fixture trees (enforced by convex/apps/fixture_bundle_drift.test.ts — its header documents the one allowed issue-desk-qa rename transform). The three email inbox bundles (outlook/sync-emails, gmail/sync-emails, imap-smtp/sync-emails) are one product per provider — an edit to one must hit all three (enforced by convex/apps/email_bundle_parity.test.ts).
Unknown-file posture matches the loaders. Flat/tree domains are STRICT — only *.json (+ *.secrets.json sidecars); any other file would be invisible at runtime, so the gate rejects it. Bundle items (skills/, integrations/<slug>/, apps/<slug>/) carry arbitrary assets; bundle roots hold only item directories.
Landmine — shipped workflows validate schema-only on the file path. About a dozen builtin workflows deliberately fail validateWorkflowDefinition's stricter reference/port lints while parsing fine with workflowJsonSchema; the lint runs only on the agent-tool create/save (publish) path. Don't "fix" the builtins to pass it and don't add the lint to the file gate. App-bundled workflows DO pass full definition validation in the builtin-apps gate.

Adding a config domain (the drift guard forces all of it)

Schema in lib/shared/schemas/<domain>.ts — the loader and the gate must share it.
Registry entry in CONFIG_DOMAINS — layout, readContext, dataModel, scaffoldKind; the list order is the org-scaffold seed order, keep it stable. The registry is pure (V8-importable); filesystem resolvers live in convex/lib/config_store/resolvers.ts — the registry header explains the layering.
Validator entry in DOMAIN_VALIDATORS — reuse the walker matching the layout (walkFlat / walkJsonTree / walkBundles), or external-gate with coveredBy pointing at a dedicated suite (the apps pattern; the suite then asserts your gate files keep existing).
Catalog-scaffolded (scaffoldKind set)? Ship builtin-configs/<domain>/ with at least one valid file — the catalog root asserts nonzero validated files.
Run migrations:check — a new schema module changes the fingerprint (see the snapshot ritual).

Before you call it done

Tick every box, or N/A with a reason; an unticked box means not done.

The gate matching each change ran green (per the table above) — output observed, not assumed.
No consumer re-declares a shape — every new parse imports from lib/shared/schemas/.
App-bundle edits — both fixture-tree copies re-synced and all three email siblings updated (drift + parity gates green), or N/A.
Schema edits — snapshot refreshed (data-safe) or a versioned migration shipped (data-incompatible), or N/A.
New domain — schema + registry entry + validator + builtin catalog dir all present, or N/A.