← all publishers

pipelex

@pipelex source repo

32 published skills

  1. Pipelex Edit 2 · pipelex
    Edit an existing MTHDS method bundle (.mthds files). Use when the user says "change this pipe", "update the prompt", "rename this concept", "rename this pipe", "change the model", "tweak the instructions", "modify the method", "add a step", "remove this pipe", "refactor this pipeline", or wants any modification to an existing .mthds bundle. Applies contract-preserving edits directly and routes structural or contract changes to /pipelex-design.
    0
    installs
  2. Pipelex Edit 3 · pipelex
    Edit an existing MTHDS method bundle (.mthds files). Use when the user says "change this pipe", "update the prompt", "rename this concept", "rename this pipe", "change the model", "tweak the instructions", "modify the method", "add a step", "remove this pipe", "refactor this pipeline", or wants any modification to an existing .mthds bundle. Applies contract-preserving edits directly and routes structural or contract changes to /pipelex-design.
    0
    installs
  3. Pipelex Design 2 · pipelex bundle
    Design a MTHDS method bundle top-down with a construction workflow matched to its complexity — build a fully understood shallow graph directly as a coherent runnable bundle, or use validated signature-driven stepwise refinement for deep, uncertain, staged, or resumable work. Re-enters existing methods with the same adaptive choice for structural and contract changes.
    0
    installs
  4. Pipelex Inputs 2 · pipelex
    Prepare inputs for MTHDS methods. Use when user says "prepare inputs", "create inputs", "use my files", "generate test data", "template", "synthesize inputs", "mock inputs", "I have a PDF/image/document to use", "make sample data", or wants to create inputs.json for running a .mthds pipeline. Works from a local .mthds bundle or from a registered method's catalog id (mt_…) — also use when the user names a method id, e.g. "prepare inputs for mt_abc123" or "run method mt_abc123". Handles user-provided files, synthetic data generation, placeholder templates, and mixed approaches. Defaults to automatic mode.
    0
    installs
  5. Pipelex Design 3 · pipelex bundle
    Design a MTHDS method bundle top-down with a construction workflow matched to its complexity — build a fully understood shallow graph directly as a coherent runnable bundle, or use validated signature-driven stepwise refinement for deep, uncertain, staged, or resumable work. Re-enters existing methods with the same adaptive choice for structural and contract changes.
    0
    installs
  6. Pipelex Inputs 3 · pipelex
    Prepare inputs for MTHDS methods. Use when user says "prepare inputs", "create inputs", "use my files", "generate test data", "template", "synthesize inputs", "mock inputs", "I have a PDF/image/document to use", "make sample data", or wants to create inputs.json for running a .mthds pipeline. Works from a local .mthds bundle or from a registered method's catalog id (mt_…) — also use when the user names a method id, e.g. "prepare inputs for mt_abc123" or "run method mt_abc123". Handles user-provided files, synthetic data generation, placeholder templates, and mixed approaches. Defaults to automatic mode.
    0
    installs
  7. Pipelex Organize 2 · pipelex
    Reorganize a designed method bundle into a clear, browsable layout. Use when signature-driven construction left one .mthds file per refinement, when any existing layout needs regrouping into coherent modules (or one simple file), or when the user says "organize the bundle", "organize the method", "regroup the files", "clean up the bundle layout". Automatically follows converged /pipelex-design runs only when their construction-shaped layout needs it. Pure reorganization — never changes what the method does.
    0
    installs
  8. Pipelex Organize 3 · pipelex
    Reorganize a designed method bundle into a clear, browsable layout. Use when signature-driven construction left one .mthds file per refinement, when any existing layout needs regrouping into coherent modules (or one simple file), or when the user says "organize the bundle", "organize the method", "regroup the files", "clean up the bundle layout". Automatically follows converged /pipelex-design runs only when their construction-shaped layout needs it. Pure reorganization — never changes what the method does.
    0
    installs
  9. Skybridge · pipelex bundle
    Guide developers through creating and updating ChatGPT and MCP apps. Covers the full lifecycle: brainstorming ideas against UX guidelines, bootstrapping projects, implementing tools/views, debugging, running dev servers, deploying and connecting apps to ChatGPT. Use when a user wants to create or update a ChatGPT app, MCP app, MCP server or use the Skybridge framework.
    0
    installs
  10. Bump Sdks · pipelex
    Bump this repo's two @pipelex npm dependencies — @pipelex/sdk and @pipelex/mthds-ui — to their latest published versions (or to versions the user names). Reads each package's CHANGELOG for the versions in between, maps every breaking bullet onto the client seams and view casts this repo actually declares, applies the bump through the Makefile, runs the checks, offers a live run against the real API, and prepares a reviewable commit. Use this whenever the user says "bump the sdk", "bump the sdks", "bump @pipelex/sdk", "bump mthds-ui", "update the pipelex sdk", "upgrade the sdks", "is there a new sdk version", "are we behind on the sdk", or asks to pull in a newer @pipelex/sdk or @pipelex/mthds-ui release. Also use it when a tool fails at runtime against the live API while `make all` passes — that pattern usually means the installed SDK is behind the API.
    0
    installs
  11. Bump Mthds Form · pipelex
    Bump the @pipelex/mthds-form dependency in mthds-ui to a newer published version. Reads the form kernel's CHANGELOG.md for the versions in between, checks each change against the seams this library consumes (the gate in src/form/runGate.ts, the controls in RunPanel.tsx, the tsup externals, the Storybook styling lane, the generated contracts fixtures), moves the single dependencies range, runs check/test/smoke-pack, and prepares a reviewable commit. Use whenever the user says "bump mthds-form", "bump the form kernel", "update @pipelex/mthds-form", "upgrade the form package", "is there a new mthds-form version", "pull in the new kernel", or asks to move this repo onto a newer form-kernel release — and reach for it too when someone asks whether RunPanel is on the latest kernel.
    0
    installs
  12. Add Pipeline Story · pipelex
    Add a new pipeline example to the Storybook from a .mthds bundle file. Generates both dry-run and live-run GraphSpecs via pipelex CLI, creates the data directory, spec file, wires it into mockGraphSpec.ts, and creates the story file. Use when user says "add example", "add pipeline", "new storybook story", "add a graph", "new pipeline example", or provides a .mthds file to visualize.
    0
    installs
  13. Bump Pipelex · pipelex bundle
    Moves this repo's `pipelex` dependency pin to the latest release on PyPI (or a version you name), re-locks, migrates `.pipelex/` config if the schema moved, runs the checks, and writes the CHANGELOG entry — stopping before the commit. Use whenever the user says "bump pipelex", "update pipelex", "upgrade pipelex", "pin pipelex to 0.48.0", "get us on the latest pipelex", "what's the latest pipelex", "is our pipelex out of date", "move off the git pin", or asks to build against a newly published pipelex release. Also use when a failure looks like a pipelex version mismatch — a `TypeError` about a missing keyword-only argument from the runtime, an `extra="forbid"` rejection, or a `StorageConfigError` at boot. This is about the **pipelex dependency**, not about releasing pipelex-api itself; releasing this package is the `release` skill.
    0
    installs
  14. Postman Bundle · pipelex bundle
    Turn a Pipelex MTHDS bundle into an API request against any bundle-shaped pipelex-api route — push it as a ready-to-run query into the live "Pipelex FastAPI" Postman collection, emit a curl command, execute it directly, or just preview the body. Covers the whole bundle surface: run (/v1/execute, /v1/start), dry-run validate (/v1/validate — no inference, no cost), crate resolution (/v1/resolve), typed codegen (/v1/codegen — ts-zod, python-pydantic, python-structures), and the per-pipe build projections (/v1/build/inputs, /v1/build/output, /v1/build/runner). Use this whenever the user points at a bundle directory or a .mthds file (often with an inputs.json) and wants to run, validate, resolve, codegen, or otherwise test it via the API — e.g. "make a Postman query for this bundle", "run the fashion_moodboard bundle against the API", "validate this bundle via the API", "resolve this bundle to a crate", "codegen this bundle", "generate the TypeScript types for this method over the API", "test /v1/resolve on this b
    0
    installs
  15. Bump Sdk · pipelex
    Bump the @pipelex/sdk dependency in pipelex-starter-js to a newer published version. Reads the SDK's CHANGELOG.md for the versions in between, calls out breaking changes, applies mechanical renames (e.g. an env var or option renamed X → Y) to this repo's own code, updates package.json/package-lock.json, runs the checks, and prepares a commit. Use when the user says "bump the sdk", "bump @pipelex/sdk", "update pipelex sdk", "upgrade the pipelex sdk", "is there a new sdk version", or asks to pull in a newer @pipelex/sdk release.
    0
    installs
  16. Bootstrap · pipelex bundle
    Bootstrap this pipelex-starter-js template into a real project — replaces the template name (pipelex-starter-js / "Pipelex Starter") in package.json, README, CLAUDE.md, the app UI and the release skill, sets description, author, repo URL and license, resets the version and changelog, then syncs package-lock.json and runs the checks. Use this right after creating a repo from the template, or whenever the user says "bootstrap", "set up this template", "rename the project", "initialize the project", "replace the placeholders", "give this project a name", or "make this my own".
    0
    installs
  17. Contract Check · pipelex
    Detect interface-contract drift between @pipelex/sdk's client surface and the wire specs it implements (defaults to comparing against the last release tag, but the user can specify any tag or commit). Compares the PipelexApiClient request/response shapes against the protocol and validation specs in ../docs/specs/. Use when the user says "check the contract", "contract review", "contract check", "did we break the contract", "check interfaces", "API contract", "protocol drift", "compare to vX.Y.Z", or before shipping/releasing a version that touches the client wire surface. Also trigger automatically before the /release skill runs.
    0
    installs
  18. Check Min Versions · pipelex
    Show the minimum required version of the upstream dependency this SDK rests on — the `mthds` package (provider of the MTHDS protocol wire types via `mthds/protocol`). Read-only: reports the current floor without changing anything. Use when the user says "check min versions", "what's the min mthds version", "show required versions", "current version floor", or any variation of asking what the SDK's upstream minimum is. This is the read-only counterpart to the bump-mthds skill — if the user wants to *change* the floor, use that one instead.
    0
    installs
  19. Add Model · pipelex bundle
    Add a new AI model to the Pipelex inference system. Guides through all required steps: backend TOML configuration (OpenAI, Azure, Anthropic, Google, etc.), kit sync, test profile collections, and fixture regeneration. Use when the user says "add a model", "add GPT-X", "add Claude X", "new model", "register a model", "add Gemini X", "support model X", "add model to backend", or any variation of introducing a new AI model to the inference configuration. Also use when the user mentions a model name that doesn't exist in the backend configs yet and wants to add it.
    0
    installs
  20. Bump Mthds · pipelex bundle
    Move this repo's exact `mthds` dependency pin to the latest release on PyPI (or a version you name), re-lock, adapt the engine source to whatever the new release broke, run the checks, and write the CHANGELOG entry — stopping before the commit. Use whenever the user says "bump mthds", "update mthds", "upgrade mthds", "move to mthds 0.10.0", "get us on the latest mthds", "is our mthds pin stale", "is our mthds floor stale", "what's the latest mthds", or asks to build against a newly published `mthds` release. Also use when a failure looks like an mthds version mismatch — a pyright `reportAttributeAccessIssue` on something under `mthds.protocol`, an ImportError for a name that used to be there, a pydantic `Extra inputs are not permitted` from a protocol model, or a `uv lock` saying mthds is unsatisfiable. This is the **`mthds` PyPI package** (the MTHDS standard's Python client, from the sibling `mthds-python` repo) — not the MTHDS standard's spec pages, and not releasing pipelex itself, which is the `release` s
    0
    installs
  21. Test Model · pipelex
    Test an AI model on a specific backend using the Pipelex inference test infrastructure. Handles test profile creation, fixture regeneration, and running the right test class for the model type (LLM, image gen, extract, search). Use when the user says "test model X", "test gpt-5.4 on openai", "test model on gateway", "run inference test for model", "try model X on backend Y", "verify model X works", or any variation of running inference tests against a specific model on a specific backend. Also use when the user mentions testing a model after adding it, or wants to verify a model works end-to-end with real API calls.
    0
    installs
  22. Bump Kajson · pipelex bundle
    Move this repo's exact `kajson` dependency pin to the latest release on PyPI (or a version you name), re-lock, adapt the engine to whatever the new release changed, retire any workaround the release makes unnecessary, run the checks, and write the CHANGELOG entry — stopping before the commit. Use whenever the user says "bump kajson", "update kajson", "upgrade kajson", "move to kajson 0.8.0", "get us on the latest kajson", "is our kajson pin stale", "what's the latest kajson", or asks to build against a newly published `kajson` release. Also use when a failure smells like a kajson version mismatch — a `KajsonDecoderError` or `UnijsonEncoderError` on a payload that used to round-trip, a `ClassRegistryNotFoundError` after an upstream change, a pyright `reportAttributeAccessIssue` on something under `kajson.`, or a `uv lock` reporting kajson unsatisfiable. This is the **`kajson` PyPI package** (the universal JSON encoder/decoder from the sibling `kajson` repo, which is the serialization layer this engine is built
    0
    installs
  23. Drift Review · pipelex
    Resolve open drift contracts — the review obligations between code and docs declared in drift.toml. Use whenever `make drift-check` (or the `make agent-check` / `make check` aggregates, or the CI lint-drift job) fails with open contracts, when the user says "drift check failed", "resolve the drift contract", "ack the drift", "run drift plan", or after any change that touches drift trigger files (the config model / pipelex.toml, CLI code, the keyword-only guard). Also use when recording a drift dogfood observation. Performs the review for real, records an honest ack, and logs the dogfood observation the pilot phase depends on.
    0
    installs
  24. Add Migration · pipelex
    Write a migration ledger entry for a configuration schema change in pipelex, so that a user's existing file can be repaired instead of thrown away. Use when `make check-migration-schemas` (alias `cmig`) or `make check-ledger` (alias `cl`) refuses a change, when the user says "add a migration", "write the ledger entry", "the coverage gate is failing", "bump the schema version", "migration entry", "the migration gate won't let me", "account for this schema change", or after any edit to a configuration model that removed a key, renamed one, moved one, retired an enum member, or tightened what a value may be. This is the only skill that writes a ledger.
    0
    installs
  25. Update Graph UI · pipelex
    Bump the pinned `@pipelex/mthds-ui` (and `elkjs`) version that the generated ReactFlow HTML loads from jsDelivr. Re-fetches the bundle, recomputes SRI hashes, and updates the Python constants in `standalone_assets.py`. Use when user says "update graph ui", "bump mthds-ui", "update graph viewer", "new version of mthds-ui", or any variation of updating the CDN-pinned graph viewer assets.
    0
    installs
  26. Pipelex Edit · pipelex
    Edit an existing MTHDS method bundle (.mthds files). Use when the user says "change this pipe", "update the prompt", "rename this concept", "rename this pipe", "change the model", "tweak the instructions", "modify the method", "add a step", "remove this pipe", "refactor this pipeline", or wants any modification to an existing .mthds bundle. Applies contract-preserving edits directly and routes structural or contract changes to /pipelex-design.
    0
    installs
  27. Pipelex Design · pipelex bundle
    Design a MTHDS method bundle top-down with a construction workflow matched to its complexity — build a fully understood shallow graph directly as a coherent runnable bundle, or use validated signature-driven stepwise refinement for deep, uncertain, staged, or resumable work. Re-enters existing methods with the same adaptive choice for structural and contract changes.
    0
    installs
  28. Pipelex Inputs · pipelex
    Prepare inputs for MTHDS methods. Use when user says "prepare inputs", "create inputs", "use my files", "generate test data", "template", "synthesize inputs", "mock inputs", "I have a PDF/image/document to use", "make sample data", or wants to create inputs.json for running a .mthds pipeline. Works from a local .mthds bundle or from a registered method's catalog id (mt_…) — also use when the user names a method id, e.g. "prepare inputs for mt_abc123" or "run method mt_abc123". Handles user-provided files, synthetic data generation, placeholder templates, and mixed approaches. Defaults to automatic mode.
    0
    installs
  29. Pipelex Explain · pipelex
    Explain and document MTHDS bundles. Use when user says "what does this pipeline do?", "explain this workflow", "explain this method", "walk me through this .mthds file", "describe the flow", "document this pipeline", "how does this work?", or wants to understand an existing MTHDS method bundle.
    0
    installs
  30. Pipelex Organize · pipelex
    Reorganize a designed method bundle into a clear, browsable layout. Use when signature-driven construction left one .mthds file per refinement, when any existing layout needs regrouping into coherent modules (or one simple file), or when the user says "organize the bundle", "organize the method", "regroup the files", "clean up the bundle layout". Automatically follows converged /pipelex-design runs only when their construction-shaped layout needs it. Pure reorganization — never changes what the method does.
    0
    installs
  31. Pipelex MCP Source · pipelex
    Inspects and switches which `pipelex-mcp` build the plugin's declared MCP server spawns — npm `@latest`, a pinned npm version, or a local `../pipelex-mcp` checkout — and reports which version each deployment actually serves (npm, the local build, and the hosted Alpic console). Use this skill whenever the user says "bump pipelex-mcp", "which MCP version am I using", "switch the MCP source", "test against my local pipelex-mcp", "pin the MCP version", "point the plugin at the local workshop", "go back to the released MCP", "is the console up to date", or mentions the hosted console / Alpic deployment / `@pipelex/mcp` npm package in the context of versions. Also use it after `pipelex-mcp` ships a release, when an MCP-backed skill (`pipelex-design`, `pipelex-organize`, `pipelex-edit`, `pipelex-inputs`) behaves unexpectedly and the server version is suspect, or before committing, to check that no temporary dev switch leaked into the tree.
    0
    installs
  32. Release · pipelex
    Automates the kajson release workflow: bumps the version in pyproject.toml, finalizes the CHANGELOG.md Unreleased section, runs quality checks, creates a release/vX.Y.Z branch, commits, pushes, and opens a PR to main. Use when user says "release", "cut a release", "bump version", "prepare a release", "make a release", "ship it", "create release branch", or any variation of shipping a new version of kajson. The user can optionally provide changelog content inline when invoking the skill (e.g. "/release Added new encoder feature"), which will be used as the changelog entry for this version.
    0
    installs