一键导入
add-prompt
Scaffold a new MCP prompt template. Use when the user asks to add a prompt, create a reusable message template, or define a prompt for LLM interactions.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Scaffold a new MCP prompt template. Use when the user asks to add a prompt, create a reusable message template, or define a prompt for LLM interactions.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | add-prompt |
| description | Scaffold a new MCP prompt template. Use when the user asks to add a prompt, create a reusable message template, or define a prompt for LLM interactions. |
| metadata | {"author":"cyanheads","version":"1.3","audience":"external","type":"reference"} |
Prompts use the prompt() builder from @cyanheads/mcp-ts-core. Each prompt lives in src/mcp-server/prompts/definitions/ with a .prompt.ts suffix. The standard registration pattern uses a definitions/index.ts barrel that collects all prompts into an allPromptDefinitions array for createApp(). Fresh scaffolds start with direct imports in src/index.ts — the barrel is introduced as definitions grow. Match the pattern already used by the project you're editing.
Prompts are pure message templates — no Context, no auth, no side effects. generate can be sync or async (returns PromptMessage[] | Promise<PromptMessage[]>).
src/mcp-server/prompts/definitions/{{prompt-name}}.prompt.tscreateApp() prompt list (directly in src/index.ts for fresh scaffolds, or via a barrel if the repo already has one)bun run devcheck to verify/**
* @fileoverview {{PROMPT_DESCRIPTION}}
* @module mcp-server/prompts/definitions/{{PROMPT_NAME}}
*/
import { completable, prompt, z } from '@cyanheads/mcp-ts-core';
export const {{PROMPT_EXPORT}} = prompt('{{prompt_name}}', {
description: '{{PROMPT_DESCRIPTION}}',
// title is optional — human-readable display name surfaced in prompts/list.
// title: '{{PROMPT_DISPLAY_TITLE}}',
// args is optional — omit entirely for prompts with no parameters.
// When present, all fields need .describe(). Only JSON-Schema-serializable types allowed.
// Wrap any field with completable() to enable argument autocompletion.
args: z.object({
// All fields need .describe()
// language: completable(z.string().describe('Language'), async (partial) => matchingLanguages(partial)),
}),
generate: (args) => [
{
role: 'user',
content: {
type: 'text',
text: `{{PROMPT_TEMPLATE_TEXT}}`,
},
},
],
});
generate: (args) => [
{
role: 'user',
content: {
type: 'text',
text: `Here is the ${args.type} to review:\n\n${args.content}`,
},
},
{
role: 'assistant',
content: {
type: 'text',
text: 'I will analyze this carefully. Let me start with...',
},
},
],
// src/index.ts (fresh scaffold default)
import { createApp } from '@cyanheads/mcp-ts-core';
import { {{PROMPT_EXPORT}} } from './mcp-server/prompts/definitions/{{prompt-name}}.prompt.js';
await createApp({
tools: [/* existing tools */],
resources: [/* existing resources */],
prompts: [{{PROMPT_EXPORT}}],
});
If the repo already uses src/mcp-server/prompts/definitions/index.ts, add the export to that barrel instead:
export { {{PROMPT_EXPORT}} } from './{{prompt-name}}.prompt.js';
Wrap any args field with completable() (re-exported from @cyanheads/mcp-ts-core) to enable argument autocompletion. The SDK auto-installs completion/complete handling and advertises the completions capability when any registered prompt has a completable argument — no other changes are needed.
import { completable, prompt, z } from '@cyanheads/mcp-ts-core';
export const codeReview = prompt('code_review', {
description: 'Review code for issues.',
title: 'Code Review',
args: z.object({
language: completable(
z.string().describe('Programming language'),
async (partial) => ['typescript', 'python', 'rust'].filter((l) => l.startsWith(partial)),
),
code: z.string().describe('Code to review'),
}),
generate: (args) => [
{ role: 'user', content: { type: 'text', text: `Review this ${args.language} code:\n${args.code}` } },
],
});
completable() is transparent to the linter — it does not affect describe-on-fields or schema-serializable rules. All completable-wrapped fields still require .describe() on the underlying schema.
src/mcp-server/prompts/definitions/{{prompt-name}}.prompt.tsprompt() uses snake_casedescription field set (lint warns if absent, but devcheck won't hard-fail — verify it's present)title field set if a human-readable display name is needed in prompts/listargs fields have .describe() annotations — or args omitted entirely for no-parameter promptsargs fields use only JSON-Schema-serializable Zod types (no z.date(), z.transform(), z.bigint(), z.symbol(), z.custom(), etc.)completable(), the underlying schema still has .describe() on each wrapped field@fileoverview and @module header presentgenerate function present and returns at least one { role, content: { type: 'text', text } } messagecreateApp() prompt list (directly or via barrel)bun run devcheck passesScaffold a new MCP tool definition. Use when the user asks to add a tool, create a new tool, or implement a new capability for the server.
Authentication, authorization, and multi-tenancy patterns for `@cyanheads/mcp-ts-core`. Use when implementing auth scopes on tools/resources, configuring auth modes (none/jwt/oauth), working with JWT/OAuth env vars, or understanding how tenantId flows through ctx.state.
DataCanvas primitive reference — a Tier 3 SQL/analytical workspace for tabular MCP servers, backed by DuckDB. Use when registering tables from upstream APIs, running ad-hoc SQL across them, and exporting results. Covers the acquire → register → query → export flow, per-table TTL, the token-sharing pattern for multi-agent collaboration, env config, and Cloudflare Workers fail-closed behavior.
Reference for core and server configuration in `@cyanheads/mcp-ts-core`. Covers env var tables with defaults, priority order, server-specific Zod schema pattern, and Workers lazy-parsing requirement.
Canonical reference for the unified `Context` object passed to every tool and resource handler in `@cyanheads/mcp-ts-core`. Covers the full interface, all sub-APIs (`ctx.log`, `ctx.state`, `ctx.elicit`, `ctx.progress`, `ctx.enrich`, `ctx.content`), and when to use each.
McpError constructor, JsonRpcErrorCode reference, and error handling patterns for `@cyanheads/mcp-ts-core`. Use when looking up error codes, understanding where errors should be thrown vs. caught, or using ErrorHandler.tryCatch in services.