temps-plugin

Featured

Design, build, test, and distribute external Temps plugins with TypeScript/Bun; provide development and local-testing guidance for existing Rust plugins. Use for creating a plugin, adding an embedded console UI or deployment-event automation, testing host permissions and AI, installing from GitHub, or submitting a plugin to the public catalog. End-to-end publishing covers TypeScript GitHub-source plugins, not Rust native-package releases or in-process TempsPlugin backend crates.

DevOps & Infrastructure 791 stars 63 forks Updated today Apache-2.0

Install

View on GitHub

Quality Score: 92/100

Stars 20%
97
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# Create and ship a Temps plugin For TypeScript/Bun, deliver a working external plugin, an installable source repository, and evidence of what was verified. Continue an existing project when provided; preserve its identity, storage, and user changes. Publishing is a separate outcome from building or installing. Rust support here is limited to development and local simulator testing. Rust distribution requires the separate signed native npm-package/catalog pipeline, which this skill does not teach. Do not route a Cargo repository through the TypeScript GitHub installer or suggest copying/symlinking a binary into the host plugin directory. If Rust publication is requested, establish the supported native release procedure before claiming an end-to-end plan; do not silently change the user's implementation language. ## 1. Establish the contract Record the plugin's purpose, intended user, entry point in Temps, input/output, persisted data, required host permissions, resource limits, and supported host/SDK versions. Resolve only missing decisions that affect the implementation. Prefer TypeScript + Bun for a new GitHub-installable plugin; retain Rust for existing Rust plugins or an explicit choice. Read applicable repository instructions. Inspect the installed CLI's `plugin --help` and the SDK's exports instead of assuming commands from another release exist. The canonical TypeScript starter is [gotempsh/temps-plugin-template](https://github.com/gotempsh/temps-plugin-template)....

Details

Author
gotempsh
Repository
gotempsh/temps
Created
11 months ago
Last Updated
today
Language
Rust
License
Apache-2.0

Integrates with

Similar Skills

Semantically similar based on skill content — not just same category

DevOps & Infrastructure Featured

temps

Manage, deploy, operate, and instrument applications with Temps. Use this skill whenever the user mentions Temps, `@temps-sdk/cli@0.1.36`, deploying or migrating an app to Temps, projects, environments, services, domains, backups, logs, monitoring, analytics, browser Performance Insights/Core Web Vitals, observability, error tracking, OpenTelemetry, tracing, session replay, or Temps Cloud. Also use it when preparing an application for production on Temps even if the user does not explicitly ask for the CLI. Route to focused references, proactively detect missing observability during create/link/deploy journeys, and use pinned `bunx` or `npx` CLI invocations with explicit target contexts.

791 Updated today
gotempsh
DevOps & Infrastructure Featured

temps-cli

Operate Temps through the pinned `@temps-sdk/cli` package with bunx or npx. Use when the user mentions Temps CLI, `@temps-sdk/cli`, a CLI command, or asks to deploy, configure, inspect, automate, or administer Temps from a terminal. Covers contexts, projects, deployments, environments, services, domains, monitoring, backups, telemetry, browser Performance Insights/Core Web Vitals, Cloud, platform administration, and read-only managed-data browsing. Apply the target-context, secret-handling, confirmation, and verification rules for every agentic CLI operation.

791 Updated today
gotempsh
DevOps & Infrastructure Featured

start-temps

Start (or restart) a local Temps control plane built from this checkout, and the web dev server (`bun dev`) in `<checkout>/web`. Invoke when the user says "start temps", "restart temps", "launch the server", "kill and restart temps", or asks to bring the local server up after backend changes. Ports, database and data dir are allocated PER CHECKOUT (a "slot") so several worktrees/branches run side by side without killing each other or corrupting each other's schema — the first checkout you start in claims slot 0 (the familiar `:8080` / `:3000`); every other worktree gets its own slot and its own `temps_s<N>` database. Uses the `fast` cargo profile (release semantics, no debug symbols, parallel codegen) for quick rebuilds. Pass `split` (e.g. "start temps split", "/start-temps split") to launch the two-process proxy/console topology for testing that feature.

791 Updated today
gotempsh