Agent skill

Temps Best Practices

by gotempsh in gotempsh/temps

Best-practices reference for preparing and instrumenting applications on Temps.

Apache-2.0Auto-check passedDevOps & Cloud

Install Temps Best Practices

skills CLI
$ npx skills add gotempsh/temps --skill temps-best-practices -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install gotempsh/temps temps-best-practices --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/gotempsh/temps.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/temps-best-practices .claude/skills/temps-best-practices && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
temps-best-practices
GitHub stars
828
Token cost
~2.9k tokens
SKILL.md length
1,269 words
Files
9 (incl. references)
Skills in repo
15
Repo updated
First seen
Licence
Apache-2.0

At a glance

Best-practices reference for preparing and instrumenting applications on Temps.

  • Works in 5 steps: For any deployable application, read… → When any telemetry or replay is enabled,… → Read only the reference for each… → …
  • Reviewing an app for Temps
  • SKILL.md covers Required workflow, Runtime contract summary, Observability and Quickstart: wire up any app…, plus 5 more sections
  • Calls bunx; needs TEMPS_API_TOKEN

What it does

Temps Best Practices is an agent skill from gotempsh/temps. Best-practices reference for preparing and instrumenting applications on Temps. Covers the app runtime contract (.temps.yaml health, HOST/PORT, readiness, SIGTERM, replicas, migrations) and production observability (errors, traces, metrics, logs, analytics, privacy, sampling, cardinality, credential boundaries). Use whenever building or reviewing an app for Temps, configuring health checks, adding telemetry, diagnosing missing/noisy signals, or checking OTLP/Sentry/analytics ingestion. Triggers include "temps…

Its SKILL.md is about 2.9k tokens, which your agent loads only when the skill is triggered. The skill folder holds 10 other files, including reference files (for example `evals/evals.json`, `references/analytics.md` and `references/error-tracking.md`).

It sits in DevOps & Cloud, covering Observability and Deployment. It works with OpenTelemetry, Sentry, Docker and PostHog. The repository describes itself as: AI-native open-source alternative to Vercel + Sentry + PostHog + Pingdom + Resend + E2B. 440+ CLI operations with drop-in skills for Claude Code, Codex & OpenCode — deployments… The licence is Apache-2.0.

When your agent uses it

  • Reviewing an app for Temps
  • Configuring health checks
  • Adding telemetry
  • Diagnosing missing/noisy signals

Example prompts

  • “temps best practices”
  • “prepare this app for Temps”
  • “.temps.yaml health”
  • “/temps-best-practices”

Requirements

  • Docker
  • A credential in TEMPS_API_TOKEN

Workflow steps

5 steps, taken from the first numbered list in SKILL.md.

  1. For any deployable application, read references/runtime-contract.md.
  2. When any telemetry or replay is enabled, read references/telemetry-hygiene.md.
  3. Read only the reference for each observability pillar in scope.
  4. Determine the deployment source. For repository builds, inspect and merge .temps.yaml; for image/static deployments, inspect the…
  5. Run the runtime and telemetry verification checklists before considering the work complete.

What it can do on your machine

Read from SKILL.md and the folder at commit 5a3994f. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • bunx

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use bunx, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names these keys or tokens, usually read from environment variables:

    • TEMPS_API_TOKEN

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Temps Best Practices loads about 2.9k tokens when it runs, and up to ~17k if it reads all its reference files. Until then it costs about 214 tokens; SKILL.md has 1,269 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~214
When it runs · the whole SKILL.md, loaded when a task matches
~2.9k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~17k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from gotempsh/temps at commit 5a3994f, republished under its Apache-2.0 licence (© gotempsh). 1,269 words, ~2,860 tokens.

Download SKILL.mdSave it as .claude/skills/temps-best-practices/SKILL.md (or your agent's skills folder). This skill also uses 8 other files; get the full folder from GitHub.
name
temps-best-practices
description
Best-practices reference for preparing and instrumenting applications on Temps. Covers the app runtime contract (`.temps.yaml` health, HOST/PORT, readiness, SIGTERM, replicas, migrations) and production observability (errors, traces, metrics, logs, analytics, privacy, sampling, cardinality, credential boundaries). Use whenever building or reviewing an app for Temps, configuring health checks, adding telemetry, diagnosing missing/noisy signals, or checking OTLP/Sentry/analytics ingestion. Triggers include "temps best practices", "prepare this app for Temps", ".temps.yaml health", "temps health check", "ignore health checks in otel", "temps observability", "wire up telemetry", and "instrument this app for temps". Prefer focused setup skills for a single SDK. Use temps-cli for executing deploy and resource-management commands.

Temps Best Practices

Best practices for application code that runs on Temps. This skill owns the runtime contract and production observability; use temps-cli for platform operations.

Required workflow

  1. For any deployable application, read references/runtime-contract.md.
  2. When any telemetry or replay is enabled, read references/telemetry-hygiene.md.
  3. Read only the reference for each observability pillar in scope.
  4. Determine the deployment source. For repository builds, inspect and merge .temps.yaml; for image/static deployments, inspect the deployment health-path override because no repository config is available.
  5. Run the runtime and telemetry verification checklists before considering the work complete.

Runtime contract summary

Every web application should expose a dedicated health endpoint. Repository builds configure it in .temps.yaml under the project's effective Temps Root Directory / Docker build context:

yaml
health:
  path: /healthz

Use health.path; do not rely on the currently parsed-but-unapplied status, interval, timeout, or retries fields. If OpenTelemetry server tracing is enabled, exclude the exact health path from incoming spans and routine access-log/request-metric noise. Keep the route, .temps.yaml, and filters synchronized.

Image and static deployments cannot read .temps.yaml; set the same route through their deployment health_check_path / CLI --health-check-path override instead.

Also require the app to read PORT, bind to HOST/0.0.0.0, align a custom image's EXPOSE, handle SIGTERM, flush telemetry, and exit inside Temps' 10-second shutdown window. See the runtime reference for readiness semantics, scale-to-zero caveats, replicas, migrations, stdout/stderr, and cron authentication.

Observability

Temps replaces Sentry + Datadog/Honeycomb + PostHog with one ingestion surface. This section is the map across all five pillars — use it to decide which pillar a signal belongs in, and to find the concrete endpoint/auth/gotcha details for each. It complements, not replaces, the narrower setup skills:

  • add-error-tracking — step-by-step Sentry SDK init per language/framework
  • add-react-analytics — step-by-step @temps-sdk/react-analytics hook usage

Quickstart: wire up any app end to end

Goal: an app in any language gets runtime health, error tracking, and traces working safely.

Temps auto-injects exporter destinations and credentials; it does not install or initialize an SDK. Apps deployed through Temps receive these variables at Docker build time and container runtime, but application instrumentation still has to be installed, initialized, filtered, and verified:

Env varWhat it's forClient-safe?
SENTRY_DSNServer-side/generic error-tracking DSNServer by default
NEXT_PUBLIC_SENTRY_DSN / NUXT_PUBLIC_SENTRY_DSN / VITE_SENTRY_DSN / PUBLIC_SENTRY_DSN / REACT_APP_SENTRY_DSNFramework-specific public Sentry write keyYes
SENTRY_RELEASECommit SHA; leave release unset in Sentry.init() so the SDK reads itServer/build metadata
OTEL_EXPORTER_OTLP_ENDPOINT, OTEL_EXPORTER_OTLP_PROTOCOLOTLP destination and http/protobuf protocolEndpoint is non-secret
OTEL_EXPORTER_OTLP_HEADERSDeployment-token authorization for OTLPNo — server only
OTEL_SERVICE_NAME, OTEL_SERVICE_VERSIONStable service and release metadataNon-secret

Build-time availability does not make a server credential browser-safe. Never expose OTEL_EXPORTER_OTLP_HEADERS, TEMPS_API_TOKEN, dt_, or tk_ through a public-prefixed variable or client bundle. Browser/mobile OTLP must use an authenticated backend or collector; see references/telemetry-hygiene.md.

This auto-injection is scoped to apps deployed through Temps. It does not apply to: an app running elsewhere and only sending telemetry to a self-hosted Temps instance, or to Temps' own console/dashboard (which is built by its own CI, not through this deploy pipeline — self-referential, since Temps doesn't deploy itself as a project on itself). For those cases, get the real credential from the dashboard and wire it through whatever env var / build-arg / secrets mechanism that project's own build system already uses:

  • Error tracking DSN: Error Tracking → DSN & Setup (https://<public_key>@<temps-host>/<project_id>)
  • A server-side deployment token (dt_...) or API key (tk_...) for OTLP: Project Settings → API Keys

Never hardcode a token or endpoint into source, a Dockerfile, or CI config. Do not ask the user for a token so it can be committed. A Sentry DSN public key is designed for client writes, but should still come from the platform's supported configuration path.

Either way, the app-side steps are the same:

  1. Runtime: apply references/runtime-contract.md.
  2. Hygiene: establish credential boundaries, redaction, cardinality, batching, sampling, and shutdown using references/telemetry-hygiene.md.
  3. Error tracking: follow add-error-tracking, leaving release metadata environment-driven.
  4. Traces: install and initialize the official OpenTelemetry SDK/agent using references/opentelemetry-traces.md. Auto-injected env vars only configure export.
  5. Verify runtime and telemetry behavior before considering the app production-ready.

The five pillars

PillarWhat it's forReference
Error trackingUncaught exceptions, handled errors, stack traces, source mapsreferences/error-tracking.md
Traces (OTLP)Distributed request spans, AI/gen_ai call chains, latency breakdownsreferences/opentelemetry-traces.md
Metrics (OTLP)Counters/gauges/histograms — request rates, queue depth, custom business metricsreferences/metrics.md
Logs (OTLP)Structured log records correlated to tracesreferences/logs.md
AnalyticsPage views, custom product events, session replay, Web Vitalsreferences/analytics.md

Read the specific reference file(s) for the pillar(s) in play — don't load all five unless doing a full-stack instrumentation pass.

Cross-pillar production rules live in references/telemetry-hygiene.md, not duplicated in every pillar.

Show full SKILL.md (521 more words)Show less

Deciding which pillar a signal belongs in

  • "This threw/crashed" → error tracking, not a log line. Logs are for structured record-keeping, not exception capture.
  • "How long did this request/DB call/LLM call take, and what did it call downstream?" → traces. If it's a single number you want to alert on or chart over time (not per-request), that's a metric instead.
  • "I want to count/aggregate something over time" (requests/sec, cache hit rate, custom business counter) → metrics, not traces. Don't create a span just to record a number.
  • "A user did X in the product" → analytics event, not a log or a trace attribute.
  • "I need to debug what happened at a point in time, correlated to a trace" → OTEL logs with trace_id/span_id attributes set, so they join with the trace in the dashboard.

Shared ingestion facts across pillars

Temps OTLP ingestion shares a rate-limit/quota model, but token support differs by signal:

  • tk_ API key: server-side; needs X-Temps-Project-Id.
  • dt_ deployment token: server-side and project/environment scoped. Prefer the header-based endpoint so Temps resolves attribution from the token. Do not expose it to a browser.
  • si_ integration token: supported for infrastructure metrics ingestion, not general traces/logs.
  • Sentry-compatible ingestion: uses the DSN public key rather than these machine tokens.
  • Auth header: Authorization: Bearer <token> or X-Temps-Api-Key: <token>. Some OTLP exporters URL-encode the header as Bearer%20<token> — Temps accepts that too.
  • Rate limit: 1000 req/60s per token by default (TEMPS_OTEL_RATE_LIMIT, TEMPS_OTEL_RATE_LIMIT_WINDOW_SECS — server-side config, not something the app sets).
  • Storage quota: off by default; a self-hosted instance can opt in via TEMPS_OTEL_QUOTA_GB. If ingestion suddenly starts 413'ing, that's the likely cause.
  • Endpoint shape: prefer header-based POST /api/otel/v1/{traces|metrics|logs} with attribution resolved from the token. Path-based endpoints exist, but should not be used to override a deployment token's intended deployment attribution.

Definition of done

  1. Runtime: app listens on the injected port/interface; the health route is configured through .temps.yaml for repository builds or the deployment override for image/static deploys; SIGTERM drains and exits within 10 seconds.
  2. Health noise: repeated health requests succeed without routine server spans, access logs, or request metrics; a normal route remains observable.
  3. Error tracking: a deliberate test error appears in Error Tracking → Error Groups with the expected release and no sensitive data.
  4. Traces: a normal request appears in Observe → Traces, uses a route-template name, propagates context downstream, and has a sane duration_ms.
  5. Metrics: names and bounded labels pass validation; no user/session/request identifiers create cardinality explosions.
  6. Logs: a structured log inside an active span joins the correct trace and contains no secrets.
  7. Analytics: browser events are treated as untrusted; an authoritative test conversion comes from authenticated server code.
  8. Replay: recording is consent-gated, masked, path-restricted, and inspected with synthetic sensitive values.
  9. Client bundle: built assets contain no dt_, tk_, TEMPS_API_TOKEN, or OTLP authorization header.

If a signal never appears, check whether the SDK was actually initialized, then endpoint/protocol, token type/header, rate limit, and quota.

Everything else

Beyond the runtime health contract and observability guidance above, deployment, service/database provisioning, environment variables, domains, monitoring config, backups, and CI/CD automation are all reached through the Temps CLI (bunx @temps-sdk/cli). Use the temps-cli skill for those operations.

© gotempsh, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 8 other files (references) in skills/temps-best-practices of gotempsh/temps.

  • SKILL.md
  • evals/evals.json
  • references/analytics.md
  • references/error-tracking.md
  • references/logs.md
  • references/metrics.md
  • references/opentelemetry-traces.md
  • references/runtime-contract.md
  • references/telemetry-hygiene.md

Open the folder on GitHubat commit 5a3994f

Compare with similar skills

Temps Best Practices next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Temps Best Practices compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Temps Best Practices this skillgotempsh/temps828—~2.9kAutomated safety check: PassApache-2.0
Nextjs Deploymentgiuseppe-trisciuoglio/developer-kit356—~2.3kAutomated safety check: NotesMIT
Aspiremicrosoft/aspire.dev1964 repos~1.1kAutomated safety check: PassMIT
Aspire MonitoringCommunityToolkit/Aspire629—~3.5kAutomated safety check: PassMIT
Deploy Observabilityaliyun/alibabacloud-observability-mcp-server166—~2.6kAutomated safety check: NotesNone
Logfire Infrastructurepydantic/skills140—~1.8kAutomated safety check: PassMIT

Similar skills

  • Nextjs Deployment

    giuseppe-trisciuoglio/developer-kit

    Provides comprehensive patterns for deploying Next.js applications to production.

    356 GitHub stars~2.3k tokensUpdated 29 days ago
    DevOps & CloudAuto-check: notes
  • Aspire

    microsoft/aspire.dev

    Official

    Orchestrates Aspire distributed applications using the Aspire CLI for running, debugging, and managing distributed apps.

    196 GitHub starsUsed in 4 repos~1.1k tokens
    DevOps & CloudAuto-check passed
  • Aspire Monitoring

    CommunityToolkit/Aspire

    ANALYSIS SKILL - Observe Aspire apps: logs, traces, metrics, resource state, telemetry export, browser telemetry, and the standalone dashboard.

    629 GitHub stars~3.5k tokensUpdated yesterday
    DevOps & CloudAuto-check passed
  • Deploy Observability

    aliyun/alibabacloud-observability-mcp-server

    Deploy, start, and update the Alibaba Cloud Observability MCP Server (阿里云可观测 MCP Server).

    166 GitHub stars~2.6k tokensUpdated 1 mo ago
    DevOps & CloudAuto-check: notes
  • Logfire Infrastructure

    pydantic/skills

    Official

    Monitor hosts, Docker containers, Kubernetes clusters, database/queue/cache servers, and cloud-provider metrics with Pydantic Logfire — no application code required.

    140 GitHub stars~1.8k tokensUpdated 8 days ago
    DevOps & CloudAuto-check passed
  • Exploring Apm Traces

    PostHog/posthog

    Official

    Investigates distributed application performance using PostHog APM (OpenTelemetry span) data via MCP.

    40k GitHub stars~3.5k tokensUpdated today
    DevOps & CloudAuto-check passed

More from gotempsh/temps

All 15 skills in this repo
  • Temps

    gotempsh/temps

    Manage, deploy, operate, and instrument applications with Temps.

    828 GitHub stars~2k tokensUpdated today
    Auto-check passed
  • Add React Analytics

    gotempsh/temps

    Add Temps analytics to React applications with comprehensive tracking capabilities including page views, custom events, scroll tracking, engagement monitoring, session recording, and Web Vitals…

    828 GitHub stars~2.7k tokensUpdated today
    Auto-check passed
  • Temps CLI

    gotempsh/temps

    Operate Temps through the pinned @temps-sdk/cli package with bunx or npx.

    828 GitHub stars~2k tokensUpdated today
    Auto-check passed
  • Temps Plugin

    gotempsh/temps

    Design, build, test, and distribute external Temps plugins with TypeScript/Bun; provide development and local-testing guidance for existing Rust plugins.

    828 GitHub stars~1.8k tokensUpdated today
    Auto-check passed
  • Add Custom Domain

    gotempsh/temps

    Add a custom domain to a Temps project and provision an automatic SSL/TLS certificate via Let's Encrypt, driven entirely from the @temps-sdk/cli CLI.

    828 GitHub stars~988 tokensUpdated today
    Auto-check passed
  • Add Error Tracking

    gotempsh/temps

    Add Temps error tracking to applications using the Sentry-compatible SDK.

    828 GitHub stars~4.2k tokensUpdated today
    Auto-check: notes

Categories

Questions about Temps Best Practices

What does Temps Best Practices do?

Best-practices reference for preparing and instrumenting applications on Temps. Temps Best Practices is an agent skill from gotempsh/temps. Best-practices reference for preparing and instrumenting applications on Temps.

When should I use Temps Best Practices?

Temps Best Practices fits situations like: reviewing an app for Temps; configuring health checks; adding telemetry; diagnosing missing/noisy signals.

How do I install Temps Best Practices in Claude Code?

Run `npx skills add gotempsh/temps --skill temps-best-practices -a claude-code`. Or copy the skill folder (skills/temps-best-practices in gotempsh/temps) into .claude/skills/temps-best-practices in your project. Claude Code loads it when a task matches its description.

How do I install Temps Best Practices in Codex?

Run `npx skills add gotempsh/temps --skill temps-best-practices -a codex`. Or copy the skill folder (skills/temps-best-practices in gotempsh/temps) into .agents/skills/temps-best-practices in your project. Codex loads it when a task matches its description.

Can I use Temps Best Practices in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add gotempsh/temps --skill temps-best-practices -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/temps-best-practices, .gemini/skills/temps-best-practices, .github/skills/temps-best-practices and .opencode/skills/temps-best-practices in your project.

What does Temps Best Practices need to run?

Going by SKILL.md and its folder, Temps Best Practices needs the command-line tools its instructions call (bunx) and credentials named TEMPS_API_TOKEN. Our summary lists: Docker; A credential in TEMPS_API_TOKEN.

Does Temps Best Practices access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Temps Best Practices safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Temps Best Practices use?

Temps Best Practices is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Temps Best Practices use?

About 2.9k tokens (SKILL.md is roughly 11k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 14k tokens, read only when the agent opens those files.

What are the alternatives to Temps Best Practices?

Skills that share tags, products or a category with Temps Best Practices: Nextjs Deployment (giuseppe-trisciuoglio/developer-kit, 356 stars), Aspire (microsoft/aspire.dev, 196 stars), Aspire Monitoring (CommunityToolkit/Aspire, 629 stars) and Deploy Observability (aliyun/alibabacloud-observability-mcp-server, 166 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Temps Best Practices?

gotempsh (a GitHub organization) maintains it in gotempsh/temps, which has 828 GitHub stars. The repository holds 15 skills in this directory. The repository was last updated on October 9, 2026.

Source: gotempsh/temps on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.