secondme-dev-assistant

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

SecondMe Dev Assistant

SecondMe开发助手

This skill turns a local project into a live SecondMe integration. It scans the repository to infer MCP-backed integration fields, identifies suitable functions to expose as tools if no MCP server exists yet, helps the user define and implement the MCP-facing surface, handles the CLI OAuth flow, and calls the official save and release APIs.

该Skill可将本地项目转换为可用的SecondMe集成。它会扫描代码仓库以推断基于MCP的集成字段；若当前无MCP服务器，会识别适合作为工具开放的函数；帮助用户定义并实现面向MCP的交互层；处理CLI OAuth流程，并调用官方的保存和发布API。

Use This Skill For

适用场景

Creating or updating integrations from local code and configuration
Analyzing whether an existing project is suitable for MCP exposure
Building a draft manifest and submitting it to SecondMe Develop after the user confirms it
Helping teammates fill complex integration fields without hand-writing JSON manifests

Do not use this skill to guess production secrets, invent missing configurations without user confirmation, or bypass the user's explicit approval for risky fields.

从本地代码和配置创建或更新集成
分析现有项目是否适合通过MCP开放能力
生成清单草稿，经用户确认后提交至SecondMe Develop
帮助团队成员填写复杂的集成字段，无需手动编写JSON清单

请勿使用该Skill猜测生产环境密钥、在未获用户确认的情况下自行补充缺失配置，或绕过用户明确审批处理高风险字段。

Invocation Defaults

调用默认值

Display name:
```
SecondMe Builder Skill
```

Short description:

Find MCP code in a project, help expose missing MCP capabilities, then save the integration

Default prompt:

Use $secondme-dev-assistant to scan this project, infer MCP fields, help expose any missing MCP capabilities, save the integration, then ask whether to release it for SecondMe review.

Implicit invocation: Allowed

显示名称：
```
SecondMe Builder Skill
```

简短描述：

在项目中查找MCP代码，帮助开放缺失的MCP能力，然后保存集成

默认提示词：

使用$secondme-dev-assistant扫描此项目，推断MCP字段，帮助开放任何缺失的MCP能力，保存集成，然后询问是否提交发布供SecondMe审核。

隐式调用：允许

Workflow

工作流程

1. Scan The Current Project

1. 扫描当前项目

Read only the files necessary to infer the integration or analyze MCP suitability.

Search order:

metadata:

README*

package.json

pyproject.toml

Cargo.toml

MCP config:
```
mcp.json
```
,
```
*.mcp.*
```
, server configs, deployment manifests
tool registration: entrypoints, decorators, router registrations, SDK setup
auth and env:
```
.env*
```
, example envs, secret templates, auth middleware
existing artifacts: manifest JSON, skill docs, previous release payloads
live integration list results after OAuth, when local code does not already identify the update target
live external app list results after OAuth, when OAuth is required

Prefer targeted searches such as

rg "tool_name|registerTool|FastMCP|Authorization|Bearer|app_id|scope|endpoint"

over broad file dumps.

Categorize findings as:

confirmed: directly present in code or config
inferred: likely correct but not explicit
missing: must be supplied by the user

Never silently invent

mcp.endpoint

, the release MCP endpoint,

oauth.appId

, tool mappings, or secrets.

仅读取推断集成或分析MCP适配性所需的文件。

搜索顺序：

元数据：

README*

package.json

pyproject.toml

Cargo.toml

MCP配置：
```
mcp.json
```
,
```
*.mcp.*
```
, 服务器配置、部署清单
工具注册：入口文件、装饰器、路由注册、SDK设置
认证与环境配置：
```
.env*
```
, 环境示例、密钥模板、认证中间件
现有产物：清单JSON、Skill文档、历史发布负载
OAuth完成后的在线集成列表结果（当本地代码未指定更新目标时）
OAuth完成后的在线外部应用列表结果（当需要OAuth时）

优先使用针对性搜索，例如

rg "tool_name|registerTool|FastMCP|Authorization|Bearer|app_id|scope|endpoint"

，而非全量文件导出。

将搜索结果分类：

已确认：代码或配置中直接存在的内容
推断：大概率正确但未明确声明的内容
缺失：必须由用户提供的内容

切勿自行生成

mcp.endpoint

、发布环境MCP端点、

oauth.appId

、工具映射或密钥。

MCP Suitability Analysis

MCP适配性分析

If no existing MCP server is detected, scan for public functions, API routes, or logic blocks that would be valuable as AI tools. Suggest a small candidate tool list to the user.

Do not stop at "this project has no MCP." Continue by proposing the MCP-facing shape the project should adopt:

recommend the smallest useful tool set, usually 2-5 tools
for each candidate tool, specify:
- proposed
```
toolName
```
- user-facing purpose
- input shape
- output shape
- auth requirement
- backing code path or route
recommend whether the project should expose:
- an HTTP MCP endpoint in the existing app, or
- a small dedicated MCP server that calls the existing app over HTTP
prefer
```
authMode = bearer_token
```
for user-scoped integrations that need a runtime bearer token
keep
```
actions[].toolName
```
and
```
mcp.toolAllow
```
identical to the real MCP tool names

After the user approves the direction, continue with the appropriate planning or implementation work so those candidate capabilities are exposed as a real MCP server in the project's codebase before returning to the integration payload and save flow.

若未检测到现有MCP服务器，需扫描可作为AI工具开放的公共函数、API路由或逻辑模块。向用户推荐少量候选工具列表。

不要仅停留在「该项目无MCP」的结论，需继续建议项目应采用的MCP交互形态：

推荐最小可用工具集，通常为2-5个工具
针对每个候选工具，明确：
- 建议的
```
toolName
```
- 面向用户的用途
- 输入结构
- 输出结构
- 认证要求
- 对应的代码路径或路由
建议项目应采用的部署方式：
- 在现有应用中暴露HTTP MCP端点，或
- 搭建小型独立MCP服务器，通过HTTP调用现有应用
对于需要运行时Bearer令牌的用户级集成，优先使用
```
authMode = bearer_token
```
确保
```
actions[].toolName
```
与
```
mcp.toolAllow
```
和实际MCP工具名称完全一致

获得用户确认后，继续开展规划或开发工作，确保这些候选能力在项目代码库中以真实MCP服务器的形式开放，再回到集成负载与保存流程。

MCP Runtime Auth And User Resolution

MCP运行时认证与用户解析

When SecondMe invokes an MCP endpoint for a user-scoped integration, it passes the current user's access token through the

Authorization

header.

Treat this token as the runtime user context for the MCP request, not as a static app credential.

Implementation rules for MCP services:

read
```
Authorization: Bearer <accessToken>
```
from the incoming MCP request
reject missing or malformed bearer tokens immediately
use that access token to call the upstream user info endpoint, or an equivalent identity endpoint, to identify the current SecondMe user
map that upstream user identity to the app's local user model, typically through
```
oauth_id
```
or an equivalent stable external id
if the local user does not exist yet, upsert it before running the business logic
execute MCP-backed business logic with the resolved local user id, not with an anonymous or global app context
return
```
401
```
for missing or invalid tokens,
```
403
```
for resources not owned by the resolved user, and
```
404
```
only for truly missing resources

Architecture guidance based on

SemeCompat

prefer keeping token parsing and local-user resolution in the app's own HTTP API layer
let the standalone MCP server or transport layer forward the bearer token, but not own user persistence
keep MCP tools thin: they should call app routes that already enforce bearer auth and user ownership
if the MCP server calls internal app APIs over HTTP, forward the same
```
Authorization
```
header unchanged

当SecondMe调用用户级集成的MCP端点时，会通过

Authorization

头传递当前用户的访问令牌。

需将该令牌视为MCP请求的运行时用户上下文，而非静态应用凭证。

MCP服务实现规则：

从传入的MCP请求中读取
```
Authorization: Bearer <accessToken>
```
立即拒绝缺失或格式错误的Bearer令牌
使用该访问令牌调用上游用户信息端点或等效身份端点，识别当前SecondMe用户
将上游用户身份映射到应用的本地用户模型，通常通过
```
oauth_id
```
或等效的稳定外部ID
若本地用户不存在，先执行新增或更新操作，再执行业务逻辑
使用解析后的本地用户ID执行基于MCP的业务逻辑，而非匿名或全局应用上下文
缺失或无效令牌返回
```
401
```
，资源不属于解析用户返回
```
403
```
，仅当资源确实不存在时返回
```
404
```

基于

SemeCompat

的架构指导：

优先在应用自身的HTTP API层处理令牌解析与本地用户解析
独立MCP服务器或传输层仅负责转发Bearer令牌，不处理用户持久化
保持MCP工具轻量化：应调用已强制实施Bearer认证和用户所有权校验的应用路由
若MCP服务器通过HTTP调用内部应用API，需原样转发相同的
```
Authorization
```
头

2. Draft The Integration Payload

2. 生成集成负载草稿

Build a candidate payload with:

```
manifest.skill
```
```
manifest.prompts
```
```
manifest.actions
```
```
manifest.mcp
```
```
manifest.oauth
```
when user-level auth is required
```
manifest.envBindings.release
```
```
envSecrets.release.values
```
for actual placeholders only

Inference rules:

Key: prefer an existing integration key; otherwise derive from the repo name in kebab-case
Display name and description: derive from README or package metadata
Prompts: infer from usage examples, prompt files, skill docs, or README; if signal is low, draft conservative prompts and mark them inferred
Actions: map directly to real MCP tools; keep
```
toolName
```
identical to the registration

MCP auth: if the MCP requires

Authorization: Bearer {{token}}

, set

authMode

bearer_token

for
```
bearer_token
```
, assume the runtime token represents the current SecondMe user and the service must resolve that user server-side
If custom placeholder headers are required, set
```
authMode
```
to
```
header_template
```
If no auth is required, use
```
none
```

Additional rules:

```
skill.key
```
is blocking; if two plausible keys exist, ask the user
If the user explicitly asks for a new key, such as
```
foo-v2
```
, treat that as a new integration candidate and do not auto-convert it into an update of the old key
Do not finalize
```
oauth.appId
```
from code discovery alone
Never infer a release MCP endpoint from local code alone; it must be user-confirmed
```
envSecrets.release.values
```
must only contain placeholders actually needed by templates or deployment config
If
```
authMode
```
is
```
bearer_token
```
, do not default to a manual
```
Authorization
```
header template; prefer leaving
```
headersTemplate
```
empty unless a real custom header template is required
for user-scoped tools, do not design the MCP service around a shared service account; the request must run as the user identified by the runtime access token

For OAuth:

After CLI OAuth succeeds, query the external app list and rank likely
```
oauth.appId
```
candidates from the project name and
```
skill.key
```
If one candidate is clearly best, present it to the user for confirmation
If multiple candidates are close, show a short ranked list and ask the user to choose
If no candidate is plausible, ask the user to provide
```
oauth.appId
```
manually

Before deciding whether this is

create

update

If the repo already contains an integration id, treat it as an update candidate
Otherwise use the integration list API to look for an existing integration owned by the same user
Compare by stable fields such as
```
skill.key
```
and confirmed project identity
If exactly one strong match exists, treat it as an update candidate
If there is no match, prepare a create payload
If there are multiple plausible matches, stop and ask which integration to update
If the user explicitly asked for a new integration key, only use the list to detect exact key collisions and avoid duplicates; do not silently overwrite a different integration

构建候选负载，包含：

```
manifest.skill
```
```
manifest.prompts
```
```
manifest.actions
```
```
manifest.mcp
```
当需要用户级认证时的
```
manifest.oauth
```
```
manifest.envBindings.release
```
```
envSecrets.release.values
```
（仅用于实际占位符）

推断规则：

Key：优先使用现有集成Key；否则从仓库名称派生，采用短横线分隔格式（kebab-case）
显示名称与描述：从README或包元数据派生
提示词：从使用示例、提示词文件、Skill文档或README推断；若信号不足，生成保守的提示词并标记为「推断」
动作：直接映射到真实MCP工具；确保
```
toolName
```
与注册名称完全一致

MCP认证：若MCP要求

Authorization: Bearer {{token}}

，将

authMode

设为

bearer_token

对于
```
bearer_token
```
模式，默认运行时令牌代表当前SecondMe用户，服务需在服务端解析该用户
若需要自定义占位符头，将
```
authMode
```
设为
```
header_template
```
无需认证时使用
```
none
```

附加规则：

```
skill.key
```
为必填项；若存在两个合理的Key，需询问用户
若用户明确要求新Key（如
```
foo-v2
```
），需将其视为新集成候选，不得自动转换为对旧Key集成的更新
不得仅通过代码发现确定
```
oauth.appId
```
不得仅通过本地代码推断发布环境MCP端点，必须经用户确认
```
envSecrets.release.values
```
仅包含模板或部署配置实际需要的占位符
若
```
authMode
```
为
```
bearer_token
```
，默认不手动设置
```
Authorization
```
头模板；除非确实需要自定义头模板，否则保持
```
headersTemplate
```
为空
对于用户级工具，不得围绕共享服务账号设计MCP服务；请求必须以运行时访问令牌对应的用户身份执行

3. Confirm Blocking Fields Before Any Write

OAuth相关处理

Before calling create, update, or release, show a compact summary and explicitly confirm:

```
skill.key
```
```
skill.displayName
```
```
skill.description
```
```
prompts.activationShort
```
```
prompts.activationLong
```
```
prompts.systemSummary
```
```
mcp.endpoint
```
the online release endpoint
```
oauth.appId
```
if applicable
the matched existing integration, if one was found
operation type:
```
create
```
or
```
update
```
immediate release choice

Stop and ask if:

the endpoint is localhost or still inferred
the online MCP endpoint is missing
the prompts are still inferred and have not been shown to the user
actions or tool mapping are ambiguous
the matched integration is not explicitly confirmed
required secrets are missing
release binding is incomplete

Do not release without explicit user confirmation in the current conversation.

CLI OAuth成功后，查询外部应用列表，根据项目名称和
```
skill.key
```
排序并推荐
```
oauth.appId
```
候选
若存在明显最优候选，提交给用户确认
若多个候选差异不大，展示排序后的短列表并请用户选择
若无合理候选，请求用户手动提供
```
oauth.appId
```

在确定是「创建」还是「更新」操作前：

若仓库已包含集成ID，将其视为更新候选
否则调用集成列表API，查找同一用户名下的现有集成
通过
```
skill.key
```
等稳定字段和已确认的项目身份进行匹配
若存在唯一强匹配，视为更新候选
若无匹配，准备创建负载
若存在多个合理匹配，暂停并询问用户需更新哪个集成
若用户明确要求新集成Key，仅通过列表检测是否存在完全重复的Key以避免冲突，不得静默覆盖其他集成

4. Run CLI OAuth

3. 写入前确认必填字段

Use the gateway API base:

```
https://app.mindos.com/gate/lab/api
```

Do not assume

https://develop.second.me/api

is a working API base.

Process:

Create a CLI auth session

Show the user:

the auth URL:

https://develop.second.me/auth/cli?session={sessionId}

the
```
userCode
```

Tell the user that if the page asks for a code manually, they should paste
```
userCode
```
Poll until authorized or expired
Validate which token form actually works in the current environment
Fetch the external app list to rank and confirm
```
oauth.appId
```

CLI auth endpoints:

```
POST /auth/cli/session
```
```
GET /auth/cli/session/{sessionId}/poll
```

optional:

POST /auth/cli/session/{sessionId}/authorize

POST /auth/cli/session/authorize-by-code

Path rule:

These routes are relative to the gateway base
```
https://app.mindos.com/gate/lab/api
```
Do not prepend an extra
```
/api
```
If these routes return
```
404
```
, first check whether you accidentally called
```
.../gate/lab/api/api/...
```

Expected session response shape:

json

{
  "code": 0,
  "data": {
    "sessionId": "uuid",
    "userCode": "ABCD-1234",
    "expiresAt": "2026-03-18T12:00:00Z"
  }
}

Poll outcomes:

```
pending
```
: keep polling until expiry
```
authorized
```
: extract the token from
```
data.token
```
```
expired
```
: stop and ask whether to create a new session

Token validation rule:

Start with the token exactly as returned by CLI auth
First try
```
Authorization: Bearer <token>
```
If the token contains
```
|suffix
```
and the full token returns
```
401
```
, retry once with the substring before
```
|
```
Use the first working form for the rest of the session
Do not ask the user whether to strip the suffix; validate it directly
Surface which form worked if it materially affects follow-up debugging

Integration and external app routes:

GET /applications/external/list?page=1&page_size=20

GET /integrations/list?page=1&pageSize=20

```
GET /integrations/{integrationId}
```
```
POST /integrations/create
```

POST /integrations/{integrationId}/update

POST /integrations/{integrationId}/release

Route debugging rule:

If integration or external app routes return

, verify that you are calling

https://app.mindos.com/gate/lab/api/...

and not

https://app.mindos.com/gate/lab/api/api/...

Do not conclude that the backend is missing the feature until the duplicated-path possibility has been ruled out

If the environment does not expose the CLI auth endpoints, stop and tell the user the backend branch or deployment is missing the required OAuth support.

在调用创建、更新或发布API前，展示简洁摘要并明确确认以下内容：

```
skill.key
```
```
skill.displayName
```
```
skill.description
```
```
prompts.activationShort
```
```
prompts.activationLong
```
```
prompts.systemSummary
```
```
mcp.endpoint
```
线上发布端点
（如适用）
```
oauth.appId
```
已匹配的现有集成（若存在）
操作类型：
```
create
```
或
```
update
```
是否立即发布

出现以下情况时，暂停并询问用户：

端点为localhost或仍为推断值
线上MCP端点缺失
提示词仍为推断值且未展示给用户
动作或工具映射存在歧义
已匹配的集成未得到用户明确确认
必要密钥缺失
发布绑定不完整

在当前对话中，若无用户明确确认，不得执行发布操作。

5. Save The Integration

4. 执行CLI OAuth

Update: if an existing integration id is confirmed
Create: if no matching integration is found after list lookup

After save:

surface the
```
integrationId
```
report the saved version
fetch integration detail if needed to verify the saved state
do not print raw secret values in the summary
if the user only asked to save or create, stop after reporting the saved state instead of continuing into release automatically

使用网关API基础地址：

```
https://app.mindos.com/gate/lab/api
```

请勿默认

https://develop.second.me/api

为可用API地址。

流程：

创建CLI认证会话

向用户展示：

认证URL：

https://develop.second.me/auth/cli?session={sessionId}

```
userCode
```

告知用户：若页面手动要求输入代码，需粘贴
```
userCode
```
轮询直到认证通过或会话过期
验证哪种令牌格式在当前环境中可用
获取外部应用列表，排序并确认
```
oauth.appId
```

CLI认证端点：

```
POST /auth/cli/session
```
```
GET /auth/cli/session/{sessionId}/poll
```

可选：

POST /auth/cli/session/{sessionId}/authorize

POST /auth/cli/session/authorize-by-code

路径规则：

这些路由基于网关基础地址
```
https://app.mindos.com/gate/lab/api
```
请勿额外添加
```
/api
```
前缀
若这些路由返回
```
404
```
，首先检查是否误调用了
```
.../gate/lab/api/api/...
```
格式的路径

预期会话响应结构：

json

{
  "code": 0,
  "data": {
    "sessionId": "uuid",
    "userCode": "ABCD-1234",
    "expiresAt": "2026-03-18T12:00:00Z"
  }
}

轮询结果处理：

```
pending
```
：继续轮询直到过期
```
authorized
```
：从
```
data.token
```
中提取令牌
```
expired
```
：暂停并询问用户是否创建新会话

令牌验证规则：

直接使用CLI认证返回的原始令牌
首先尝试
```
Authorization: Bearer <token>
```
格式
若令牌包含
```
|suffix
```
且完整令牌返回
```
401
```
，重试一次仅使用
```
|
```
前的子串
将首个可用的格式用于后续会话
无需询问用户是否去除后缀，直接自动验证
若格式选择对后续调试有实质影响，需告知用户最终使用的格式

集成与外部应用路由：

GET /applications/external/list?page=1&page_size=20

GET /integrations/list?page=1&pageSize=20

```
GET /integrations/{integrationId}
```
```
POST /integrations/create
```

POST /integrations/{integrationId}/update

POST /integrations/{integrationId}/release

路由调试规则：

若集成或外部应用路由返回

，需确认调用的是

https://app.mindos.com/gate/lab/api/...

而非

https://app.mindos.com/gate/lab/api/api/...

在排除路径重复的可能性前，不得判定后端缺失该功能

若当前环境未暴露CLI认证端点，需暂停并告知用户：后端分支或部署缺失所需的OAuth支持。

6. Release The Integration

5. 保存集成

Only release if the user explicitly requests it after a successful save.

Before release, verify:

the integration save succeeded
the release binding is enabled
the endpoint came explicitly from the user
the endpoint is not local-only unless the user explicitly wants local testing
for
```
bearer_token
```
integrations,
```
headersTemplate
```
does not manually render
```
Authorization: Bearer {{token}}
```
unless the release environment truly provides a matching secret placeholder

If release fails:

Fetch the integration detail immediately
Inspect the latest version's
```
validationReport
```
Report the exact failing environment, error text, and whether tool discovery succeeded
Fix the manifest or env secret cause before retrying

Common release failure pattern:

authMode = bearer_token

and

headersTemplate.Authorization = "Bearer {{token}}"

, release validation may fail with an empty rendered header such as

Bearer

In that case, prefer an empty
```
headersTemplate
```
and let bearer-token handling inject auth automatically
Only use
```
headersTemplate
```
or
```
envSecrets.release.values.token
```
when a real custom placeholder-based header is required

Implementation checklist before save or release:

the MCP endpoint accepts
```
Authorization: Bearer <accessToken>
```
the app resolves the upstream SecondMe user from that token
the app maps or upserts that user into the local user table before business logic runs
protected resources are checked against the resolved local user
the standalone MCP server forwards the incoming bearer token unchanged when calling internal app APIs
tests cover missing token, invalid token, existing-user resolution, new-user upsert, bearer-token forwarding, and resource-ownership failures

Release request body:

json

{}

Or for a specific version:

json

{
  "versionId": "ver_xxx"
}

Report the resulting state precisely, such as

pending_review

, instead of loosely saying it is live.

更新：若已确认存在现有集成ID
创建：若列表查询后未找到匹配集成

保存完成后：

展示
```
integrationId
```
报告保存的版本
若需要验证保存状态，可获取集成详情
摘要中不得打印原始密钥值
若用户仅要求保存或创建，报告保存状态后即停止，不得自动进入发布流程

Payload Schema

6. 发布集成

json

{
  "manifest": {
    "schemaVersion": "1",
    "skill": {
      "key": "example-skill",
      "displayName": "Example Skill",
      "description": "What the skill does",
      "keywords": ["example"]
    },
    "prompts": {
      "activationShort": "...",
      "activationLong": "...",
      "systemSummary": "..."
    },
    "actions": [
      {
        "name": "toolAlias",
        "description": "What the action does",
        "toolName": "real_mcp_tool_name",
        "payloadTemplate": {},
        "displayHint": "text"
      }
    ],
    "mcp": {
      "endpoint": "https://api.example.com/mcp",
      "timeoutMs": 12000,
      "toolAllow": ["real_mcp_tool_name"],
      "headersTemplate": {},
      "authMode": "bearer_token"
    },
    "oauth": {
      "appId": "app_xxx",
      "requiredScopes": ["profile:read"]
    },
    "envBindings": {
      "release": {
        "enabled": true,
        "endpoint": "https://api.example.com/mcp"
      }
    }
  },
  "envSecrets": {
    "release": null
  }
}

Field notes:

```
schemaVersion
```
is currently
```
"1"
```
```
toolName
```
must be the exact MCP tool name
```
headersTemplate
```
supports placeholders such as
```
{{token}}
```
, but do not use it by default for
```
bearer_token
```
```
authMode
```
is one of
```
none
```
,
```
bearer_token
```
, or
```
header_template
```
```
oauth.appId
```
must be user-confirmed before save or release
```
envBindings.release.endpoint
```
should use the user-provided online MCP endpoint
```
envSecrets
```
should only contain values actually needed to render release-time placeholders

仅在保存成功后，用户明确要求发布时执行此操作。

发布前需验证：

集成保存成功
发布绑定已启用
端点由用户明确提供
端点非仅本地可用（除非用户明确要求本地测试）
对于
```
bearer_token
```
集成，
```
headersTemplate
```
未手动设置
```
Authorization: Bearer {{token}}
```
（除非发布环境确实需要匹配的密钥占位符）

若发布失败：

立即获取集成详情
检查最新版本的
```
validationReport
```
报告具体失败环境、错误文本，以及工具发现是否成功
修复清单或环境密钥问题后重试

常见发布失败场景：

若

authMode = bearer_token

且

headersTemplate.Authorization = "Bearer {{token}}"

，发布验证可能因渲染后的头为空（如

Bearer

）而失败

此时建议保持
```
headersTemplate
```
为空，由Bearer令牌处理逻辑自动注入认证信息
仅当确实需要基于占位符的自定义头时，才使用
```
headersTemplate
```
或
```
envSecrets.release.values.token
```

保存或发布前的实现检查清单：

MCP端点接受
```
Authorization: Bearer <accessToken>
```
应用可通过该令牌解析上游SecondMe用户
应用在执行业务逻辑前，会将该用户映射或新增到本地用户表
受保护资源会校验解析后的本地用户权限
独立MCP服务器在调用内部应用API时，会原样转发传入的Bearer令牌
测试覆盖以下场景：令牌缺失、令牌无效、已有用户解析、新用户新增、Bearer令牌转发、资源所有权校验失败

发布请求体：

json

{}

或针对特定版本：

json

{
  "versionId": "ver_xxx"
}

需准确报告最终状态，如

pending_review

，而非模糊表述为「已上线」。

Response Style

负载结构

Compact: use tables or bullet lists for summaries
Transparent: clearly distinguish between confirmed and inferred data
Precise: use exact API error messages if a step fails
Security-first: never repeat secret values back to the user

json

{
  "manifest": {
    "schemaVersion": "1",
    "skill": {
      "key": "example-skill",
      "displayName": "Example Skill",
      "description": "What the skill does",
      "keywords": ["example"]
    },
    "prompts": {
      "activationShort": "...",
      "activationLong": "...",
      "systemSummary": "..."
    },
    "actions": [
      {
        "name": "toolAlias",
        "description": "What the action does",
        "toolName": "real_mcp_tool_name",
        "payloadTemplate": {},
        "displayHint": "text"
      }
    ],
    "mcp": {
      "endpoint": "https://api.example.com/mcp",
      "timeoutMs": 12000,
      "toolAllow": ["real_mcp_tool_name"],
      "headersTemplate": {},
      "authMode": "bearer_token"
    },
    "oauth": {
      "appId": "app_xxx",
      "requiredScopes": ["profile:read"]
    },
    "envBindings": {
      "release": {
        "enabled": true,
        "endpoint": "https://api.example.com/mcp"
      }
    }
  },
  "envSecrets": {
    "release": null
  }
}

字段说明：

当前
```
schemaVersion
```
为
```
"1"
```
```
toolName
```
必须与实际MCP工具名称完全一致
```
headersTemplate
```
支持
```
{{token}}
```
等占位符，但
```
bearer_token
```
模式下默认不使用
```
authMode
```
可选值为
```
none
```
、
```
bearer_token
```
或
```
header_template
```
```
oauth.appId
```
必须经用户确认后才能保存或发布
```
envBindings.release.endpoint
```
应使用用户提供的线上MCP端点
```
envSecrets
```
仅包含渲染发布时占位符实际需要的值

Operational Rules

响应风格

Always list integrations before assuming
```
create
```
is needed
Always list external apps before asking for manual
```
appId
```
entry
Ensure the user provides the production MCP endpoint before any release attempt
If create or update fails, surface the API error and the manifest section most likely responsible
If release fails, return the exact review or validation state instead of summarizing loosely
If release fails, inspect
```
validationReport
```
before changing anything
When the project has no MCP server yet, do not stop at suitability analysis; provide a concrete MCP exposure recommendation and hand off to planning or implementation after user approval

简洁：使用表格或项目符号列表展示摘要
透明：明确区分已确认数据与推断数据
精准：若步骤失败，使用准确的API错误信息
安全优先：绝不向用户重复返回密钥值

—

操作规则

—

始终先查询集成列表，再决定是否需要执行
```
create
```
操作
始终先查询外部应用列表，再请求用户手动输入
```
appId
```
确保用户提供生产环境MCP端点后，再尝试发布
若创建或更新失败，需展示API错误及最可能出问题的清单章节
若发布失败，返回准确的审核或验证状态，而非模糊总结
若发布失败，需先检查
```
validationReport
```
再进行修改
若项目尚无MCP服务器，不要仅停留在适配性分析；需提供具体的MCP开放建议，获得用户确认后转至规划或开发环节