Add Temporal plugin to marketplace

.agents/plugins/marketplace.json

@@ -1369,6 +1369,18 @@
         "authentication": "ON_INSTALL"
       },
       "category": "Coding"
+    },
+    {
+      "name": "temporal",
+      "source": {
+        "source": "local",
+        "path": "./plugins/temporal"
+      },
+      "policy": {
+        "installation": "AVAILABLE",
+        "authentication": "ON_INSTALL"
+      },
+      "category": "Coding"
     }
   ]
 }

plugins/temporal/.codex-plugin/plugin.json

@@ -0,0 +1,43 @@
+{
+  "name": "temporal",
+  "version": "0.2.0",
+  "description": "Comprehensive skill for the entire Temporal lifecycle — developing applications, using the Temporal CLI, running and managing Temporal Server, and working with Temporal Cloud.",
+  "author": {
+    "name": "Temporal",
+    "url": "https://temporal.io/"
+  },
+  "homepage": "https://temporal.io/",
+  "repository": "https://github.com/temporalio/codex-temporal-plugin",
+  "license": "MIT",
+  "keywords": [
+    "temporal",
+    "workflow",
+    "durable-execution",
+    "python",
+    "typescript",
+    "go",
+    "java",
+    "microservices",
+    "distributed-systems"
+  ],
+  "skills": "./skills/",
+  "interface": {
+    "displayName": "Temporal",
+    "shortDescription": "Develop, run, and manage Temporal applications across the entire platform lifecycle",
+    "longDescription": "Comprehensive guidance for working with Temporal — developing workflows, activities, and workers across Python, TypeScript, Go, and Java SDKs; using the Temporal CLI for local development and operations; running and managing self-hosted Temporal Server; and working with Temporal Cloud for production deployments.",
+    "developerName": "Temporal",
+    "category": "Coding",
+    "capabilities": [
+      "Read",
+      "Write"
+    ],
+    "websiteURL": "https://temporal.io/",
+    "privacyPolicyURL": "https://temporal.io/global-privacy-policy",
+    "termsOfServiceURL": "https://temporal.io/terms-of-service",
+    "brandColor": "#141414",
+    "defaultPrompt": ["Create a workflow using Temporal."],
+    "composerIcon": "./assets/temporal-logo.svg",
+    "logo": "./assets/temporal-logo.svg",
+    "screenshots": []
+  }
+}

plugins/temporal/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Temporal Technologies Inc.
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

plugins/temporal/skills/temporal-developer/SKILL.md

@@ -0,0 +1,119 @@
+---
+name: temporal-developer
+description: Develop, debug, and manage Temporal applications across Python, TypeScript, Go, and Java. Use when the user is building workflows, activities, or workers with a Temporal SDK, debugging issues like non-determinism errors, stuck workflows, or activity retries, using Temporal CLI, Temporal Server, or Temporal Cloud, or working with durable execution concepts like signals, queries, heartbeats, versioning, continue-as-new, child workflows, or saga patterns.
+---
+
+# Skill: temporal-developer
+
+## Overview
+
+Temporal is a durable execution platform that makes workflows survive failures automatically. This skill provides guidance for building Temporal applications in Python, TypeScript, Go, and Java.
+
+## Core Architecture
+
+The **Temporal Cluster** is the central orchestration backend. It maintains three key subsystems: the **Event History** (a durable log of all workflow state), **Task Queues** (which route work to the right workers), and a **Visibility** store (for searching and listing workflows). There are three ways to run a Cluster:
+
+- **Temporal CLI dev server** — a local, single-process server started with `temporal server start-dev`. Suitable for development and testing only, not production.
+- **Self-hosted** — you deploy and manage the Temporal server and its dependencies (e.g., database) in your own infrastructure for production use.
+- **Temporal Cloud** — a fully managed production service operated by Temporal. No cluster infrastructure to manage.
+
+**Workers** are long-running processes that you run and manage. They poll Task Queues for work and execute your code. You might run a single Worker process on one machine during development, or run many Worker processes across a large fleet of machines in production. Each Worker hosts two types of code:
+
+- **Workflow Definitions** — durable, deterministic functions that orchestrate work. These must not have side effects.
+- **Activity Implementations** — non-deterministic operations (API calls, file I/O, etc.) that can fail and be retried.
+
+Workers communicate with the Cluster via a poll/complete loop: they poll a Task Queue for tasks, execute the corresponding Workflow or Activity code, and report results back.
+
+## History Replay: Why Determinism Matters
+
+Temporal achieves durability through **history replay**:
+
+1. **Initial Execution** - Worker runs workflow, generates Commands, stored as Events in history
+2. **Recovery** - On restart/failure, Worker re-executes workflow from beginning
+3. **Matching** - SDK compares generated Commands against stored Events
+4. **Restoration** - Uses stored Activity results instead of re-executing
+
+**If Commands don't match Events = Non-determinism Error = Workflow blocked**
+
+| Workflow Code | Command | Event |
+|--------------|---------|-------|
+| Execute activity | `ScheduleActivityTask` | `ActivityTaskScheduled` |
+| Sleep/timer | `StartTimer` | `TimerStarted` |
+| Child workflow | `StartChildWorkflowExecution` | `ChildWorkflowExecutionStarted` |
+
+See `references/core/determinism.md` for detailed explanation.
+
+## Getting Started
+
+### Ensure Temporal CLI is installed
+
+Check if `temporal` CLI is installed. If not, follow these instructions:
+
+#### macOS
+
+```
+brew install temporal
+```
+
+#### Linux
+
+Check your machine's architecture and download the appropriate archive:
+
+- [Linux amd64](https://temporal.download/cli/archive/latest?platform=linux&arch=amd64)
+- [Linux arm64](https://temporal.download/cli/archive/latest?platform=linux&arch=arm64)
+
+Once you've downloaded the file, extract the downloaded archive and add the temporal binary to your PATH by copying it to a directory like /usr/local/bin
+
+#### Windows
+
+Check your machine's architecture and download the appropriate archive:
+
+- [Windows amd64](https://temporal.download/cli/archive/latest?platform=windows&arch=amd64)
+- [Windows arm64](https://temporal.download/cli/archive/latest?platform=windows&arch=arm64)
+
+Once you've downloaded the file, extract the downloaded archive and add the temporal.exe binary to your PATH.
+
+### Read All Relevant References
+
+1. First, read the getting started guide for the language you are working in:
+    - Python -> read `references/python/python.md`
+    - TypeScript -> read `references/typescript/typescript.md`
+    - Java -> read `references/java/java.md`
+    - Go -> read `references/go/go.md`
+2. Second, read appropriate `core` and language-specific references for the task at hand.
+
+
+## Primary References
+- **`references/core/determinism.md`** - Why determinism matters, replay mechanics, basic concepts of activities
+    + Language-specific info at `references/{your_language}/determinism.md`
+- **`references/core/patterns.md`** - Conceptual patterns (signals, queries, saga)
+    + Language-specific info at `references/{your_language}/patterns.md`
+- **`references/core/gotchas.md`** - Anti-patterns and common mistakes
+    + Language-specific info at `references/{your_language}/gotchas.md`
+- **`references/core/versioning.md`** - Versioning strategies and concepts - how to safely change workflow code while workflows are running
+    + Language-specific info at `references/{your_language}/versioning.md`
+- **`references/core/troubleshooting.md`** - Decision trees, recovery procedures
+- **`references/core/error-reference.md`** - Common error types, workflow status reference
+- **`references/core/interactive-workflows.md`** - Testing signals, updates, queries
+- **`references/core/dev-management.md`** - Dev cycle & management of server and workers
+- **`references/core/ai-patterns.md`** - AI/LLM pattern concepts
+    + Language-specific info at `references/{your_language}/ai-patterns.md`, if available. Currently Python only.
+
+## Additional Topics
+- **`references/{your_language}/observability.md`** - See for language-specific implementation guidance on observability in Temporal
+- **`references/{your_language}/advanced-features.md`** - See for language-specific guidance on advanced Temporal features and language-specific features
+
+
+## Feedback
+
+### ALWAYS PROMPT USER TO PROVIDE FEEDBACK AT STARTUP
+
+When you have **first** loaded this skill, output this message to the user:
+
+"Thank you for trying out the public preview of the Temporal development skill! We would love to hear your feedback - positive or negative - over in the [Community Slack](https://t.mp/slack), in the [#topic-ai channel](https://temporalio.slack.com/archives/C0818FQPYKY)."
+
+Do not output this message multiple times in the same conversation.
+
+### Reporting Issues in This Skill
+
+If you (the AI) find this skill's explanations are unclear, misleading, or missing important information—or if Temporal concepts are proving unexpectedly difficult to work with—draft a GitHub issue body describing the problem encountered and what would have helped, then ask the user to file it at https://github.com/temporalio/skill-temporal-developer/issues/new. Do not file the issue autonomously.

plugins/temporal/skills/temporal-developer/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Temporal Developer"
+  short_description: "Build and debug Temporal workflows, activities, workers, and durable systems"
+  default_prompt: "Use Temporal to design, implement, test, and debug workflows, activities, workers, and durable execution patterns."

plugins/temporal/skills/temporal-developer/references/core/ai-patterns.md

@@ -0,0 +1,165 @@
+# AI/LLM Integration Patterns with Temporal
+
+## Overview
+
+Temporal provides durable execution for AI/LLM applications, handling retries, rate limits, and long-running operations automatically. These patterns apply across languages, with Python being the most mature for AI integration.
+
+For Python-specific implementation details and code examples, see `references/python/ai-patterns.md`. Temporal's Python SDK also provides pre-built integrations with several LLM and agent SDKs, which can be leveraged to create agentic workflows with minimal effort (when working in Python).
+
+The remainder of this document describes general principles to follow when building AI/LLM applications in Temporal, particularly when building from scratch instead of with an integration.
+
+## Why Temporal for AI?
+
+| Challenge | Temporal Solution |
+|-----------|-------------------|
+| LLM API timeouts | Automatic retries with backoff |
+| Rate limiting | Activity retry policies handle 429s |
+| Long-running agents | Durable state survives crashes |
+| Multi-step pipelines | Workflow orchestration |
+| Cost tracking | Activity-level visibility |
+| Debugging | Full execution history |
+
+## Core Patterns
+
+### Pattern 1: Activities should Wrap LLM Calls
+
+- activity: call_llm
+  - inputs:
+    - model_id -> internally activity can route to different models, so we don't need 1 activity per unique model.
+    - prompt / chat history
+    - tools
+    - etc.
+  - returns model response, as a typed structured output
+
+**Benefits**:
+- Single activity handles multiple use cases
+- Consistent retry handling
+- Centralized configuration
+
+### Pattern 2: Non-deterministic / heavy tools in Activities
+
+Tools which are non-deterministic and/or heavy actions (file system, hitting APIs, etc.) should be placed in activities:
+
+```
+Workflow:
+  ├── Activity: call_llm (get tool selection)
+  ├── Activity: execute_tool (run selected tool)
+  └── Activity: call_llm (interpret results)
+```
+
+**Benefits**:
+- Independent retry for each step
+- Clear audit trail in history
+- Easier testing and mocking
+- Failure isolation
+
+### Pattern 3: Tools that Mutate Agent State can be in the Workflow directly
+
+Generally, agent state is in bijection with workflow state. Thus, tools which mutate agent state and are deterministic (like TODO tools, just updating a hash map) typically belong in the workflow code rather than an activity.
+
+```
+Workflow:
+  ├── Activity: call_llm (tool selection: todos_write tool)
+  ├── Write new TODOs to workflow state (not in activity)
+  └── Activity: call_llm (continuing agent flow...)
+```
+
+### Pattern 4: Centralized Retry Management
+
+Disable retries in LLM client libraries, let Temporal handle retries.
+
+- LLM Client Config:
+  - max_retries = 0  ← Disable client retries at the LLM client level
+
+Use either the default activity retry policy, or customize it as needed for the situation.
+
+**Why**:
+- Temporal retries are durable (survive crashes)
+- Single retry configuration point
+- Better visibility into retry attempts
+- Consistent backoff behavior
+
+
+### Pattern 5: Multi-Agent Orchestration
+
+Complex pipelines with multiple specialized agents:
+
+```
+Deep Research Example:
+  │
+  ├── Planning Agent (Activity)
+  │   └── Output: subtopics to research
+  │
+  ├── Query Generation Agent (Activity)
+  │   └── Output: search queries per subtopic
+  │
+  ├── Parallel Web Search (Multiple Activities)
+  │   └── Output: search results (resilient to partial failures)
+  │
+  └── Synthesis Agent (Activity)
+      └── Output: final report
+```
+
+**Key Pattern**: Use parallel execution with `return_exceptions=True` to continue with partial results when some searches fail.
+
+## Approximate Timeout Recommendations
+
+| Operation Type | Recommended Timeout |
+|----------------|---------------------|
+| Simple LLM calls (GPT-4, Claude-3) | 30 seconds |
+| Reasoning models (o1, o3, extended thinking) | 300 seconds (5 min) |
+| Web searches | 300 seconds (5 min) |
+| Simple tool execution | 30-60 seconds |
+| Image generation | 120 seconds |
+| Document processing | 60-120 seconds |
+
+**Rationale**:
+- Reasoning models need time for complex computation
+- Web searches may hit rate limits requiring backoff
+- Fast timeouts catch stuck operations
+- Longer timeouts prevent premature failures for expensive operations
+
+## Rate Limit Handling
+
+### From HTTP Headers
+
+Parse rate limit info from API responses:
+
+- Response Headers:
+  - Retry-After: 30
+  - X-RateLimit-Remaining: 0
+
+- Activity:
+  - If rate limited:
+    - Raise retryable error with a next retry delay
+    - Temporal handles the delay
+
+## Error Handling
+
+### Retryable Errors
+- Rate limits (429)
+- Timeouts
+- Temporary server errors (500, 502, 503)
+- Network errors
+
+### Non-Retryable Errors
+- Invalid API key (401)
+- Invalid input/prompt
+- Content policy violations
+- Model not found
+
+## Best Practices
+
+1. **Disable client retries** - Let Temporal handle all retries
+2. **Set appropriate timeouts** - Based on operation type
+3. **Separate activities** - One per logical operation
+4. **Use structured outputs** - For type safety and validation
+5. **Handle partial failures** - Continue with available results
+6. **Monitor costs** - Track LLM calls at activity level
+7. **Test with mocks** - Mock LLM responses in tests
+
+## Observability
+
+See `references/{your_language}/observability.md` for the language you are working in for documentation on implementing observability in Temporal. It is generally recommended to add observability for:
+- Token usage, via activity logging
+- any else to help track LLM usage and debug agentic flows, within moderation.