菜单
End-to-end orchestrator that creates a new connector from scratch, reviews the code, activates it in Kibana, tests it via an Agent Builder agent, iterates until quality is met, and delivers a polished result. Use when asked to build, develop, or implement a complete connector.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/elastic/kibana --skill build-connector命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Investigate Scout and FTR flaky test failures in Kibana. Use when triaging a failed-test issue, a Buildkite-reported failure, a test path that has been failing intermittently, or any time the user asks to look at a flaky test, deflake a test, or stabilize a test.
Scaffold a new LLM evaluation suite package with Playwright config, evaluate fixture, and package files. Use when creating a new eval suite, adding an evals package for a plugin, or setting up the boilerplate for offline LLM evaluations.
Migrate Kibana Cypress E2E tests (.cy.ts) to Scout (Playwright). Applies to any Kibana plugin or solution. Includes triage gates (duplicate detection, layer analysis, value assessment), Cypress-to-Scout pattern mapping, data cleanup audit, and PR workflow. Use when: (1) migrating a Cypress test to Scout, (2) converting .cy.ts to .spec.ts, (3) planning a Cypress-to-Scout migration batch, (4) rewriting Cypress screens/tasks as Scout page objects, (5) asked "how do I move this Cypress test to Scout/Playwright", (6) asked about differences between Cypress and Scout.
正在显示 SKILL.md
基于 SOC 职业分类
| name | build-connector |
| description | End-to-end orchestrator that creates a new connector from scratch, reviews the code, activates it in Kibana, tests it via an Agent Builder agent, iterates until quality is met, and delivers a polished result. Use when asked to build, develop, or implement a complete connector. |
| allowed-tools | Bash, Read, Glob, Grep, Write, Edit, Skill |
| argument-hint | ["3rd-party-service-name"] |
This skill orchestrates the full lifecycle of building a new connector for $ARGUMENTS. It chains together multiple skills and performs code review and quality verification between each stage.
This skill depends on skills from other plugins. Before starting, ensure they are loaded:
create-agent and chat-with-agent — from x-pack/platform/plugins/shared/agent_builder/.claude/skills/. Load them by reading the SKILL.md files at **/agent_builder/**/SKILL.md.If these skills are not available when needed (Tasks 6–7), the agent creation and chat testing steps will fail.
Use TaskCreate to create all of the following tasks up front so the user can see the full plan. Set all tasks to pending initially.
## Validated action-by-action table for the PR description"Set up dependencies: task 2 is blocked by 1, task 3 by 2, task 4 by 3, and so on sequentially.
Then begin working through the tasks in order.
It's tempting, when asked to build many connectors, to build the code for all of them first (Task 1-3)
and defer activation/live-testing (Tasks 4-11) until later. In practice this is where most real bugs
surface — disabled test buttons, ICU parse errors, endpoints that reject partial updates, query params
the vendor rejects, an optional modifier param silently sent to the wrong place (query string vs. body),
wrong auth scopes — none of which unit tests or a code-only review catch, because
they only show up when the spec is actually loaded and exercised in a running Kibana. If the user
explicitly asks to defer live testing for a batch, still run the self-review checklist from
create-connector's Step 4 ("Self-review before handing off") on every connector before considering it
code-complete, and flag to the user that the deferred connectors have not been runtime-verified and are
likely to need a fix-up pass once Tasks 4-11 finally run. Still produce the ## Validated table for each
connector's PR (Task 12) — every row will read ⚠️ Not validated — needs manual verification until live
testing happens, but the table itself is not optional; see
create-connector/reference/pr-validation-table.md.
Mark task 1 as in_progress.
Before generating code, research the vendor's real API docs for the actions you plan to implement —
specifically update semantics (partial vs. full-replace), array query-param encoding, per-action auth
scopes, and regional/self-hosted domain variants. See "Research the Vendor API Before Writing Any Code"
in create-connector/reference/custom-connector-setup.md. Bugs that trace back to skipping this (wrong
auth scope, 400s on partial updates, 404s on regional domains) are far cheaper to avoid up front than to
find during Task 7's live chat test or after the PR is open.
Invoke the create-connector skill with $ARGUMENTS as the argument:
Skill: create-connector
Args: $ARGUMENTS
This runs in a forked context and will generate:
src/platform/packages/shared/kbn-connector-specs/src/specs/)docs/reference/connectors-kibana/)When complete, mark task 1 as completed.
Mark task 2 as in_progress.
Review the files generated in Task 1 using the review-connector skill. Apply its checklist to the connector spec and docs.
List all issues found. If no issues are found, note that the code looks good.
Mark task 2 as completed.
Mark task 3 as in_progress.
If issues were found in Task 2, fix them using the Edit tool. After fixing, re-read the files and verify the fixes are correct.
If the fixes are significant, do another review pass. Repeat the review/edit cycle until you're satisfied with the quality — typically 1-2 iterations.
Mark task 3 as completed.
Mark task 4 as in_progress.
Use AskUserQuestion to ask the user to start Elasticsearch and Kibana:
To test the connector, I need Elasticsearch and Kibana running. Please start them if they aren't already:
yarn es snapshot # in one terminal yarn start # in another terminalLet me know when both are ready.
Wait for the user's confirmation. Once confirmed, verify by running:
src/platform/packages/shared/kbn-connector-specs/.claude/skills/activate-connector/scripts/list_connector_types.sh
If this fails, tell the user Kibana isn't reachable yet and ask them to try again.
Mark task 4 as completed.
Mark task 5 as in_progress.
Invoke the activate-connector skill:
Skill: activate-connector
Args: $ARGUMENTS
This will list available types, ask the user for credentials, and create the connector instance via the Actions API. When agentBuilder:experimentalFeatures is true, the connector's sub-actions become available to agents.
If the user reports Error: No widget found for schema type: ZodNumberFormat... when opening the
connector creation form in the Kibana UI, a z.number() field was used in the connector's config
schema — the form-generator has no numeric widget. Fix it per "There is no widget for z.number()
config fields" in create-connector/reference/connector-patterns.md (regex-validated string + text
widget, coerced to a number in the handler), then ask the user to retry.
Mark task 5 as completed.
Mark task 6 as in_progress.
Invoke the create-agent skill:
Skill: create-agent
Args: $ARGUMENTS Agent
When the skill asks for tool selection, suggest including all connector tools for the newly activated connector (and no platform tools, to keep the test focused).
Mark task 6 as completed.
Mark task 7 as in_progress.
Invoke the chat-with-agent skill to test the agent. Use the agent ID created in Task 6. The default prompt should be:
Summarize the data available to you through your tools.
Skill: chat-with-agent
Args: <agent-id-from-task-6>
Capture and analyze the full output (reasoning, tool calls, tool results, response).
Mark task 7 as completed.
Mark task 8 as in_progress.
Analyze the chat output from Task 7. Check each criterion:
"status":"failed" (unless the failure is due to auth/credential issues, which are not code problems)If tools failed (tool results contain "status":"failed"):
message field in the tool result.Unknown sub-action: 'name' — the sub-action name is wrong. Verify via the connector spec's actions array.Unexpected parameter — the tool call passes a parameter the sub-action doesn't accept. Fix the action's Zod schema.Input should be 'X' — a parameter value is invalid. Fix the action's input constraints.404/Not found or unauthorized on an action that assigns, mentions, or otherwise targets a
specific user (e.g. assignIncidentUser, add-watcher, notify) — before concluding the endpoint or
payload is wrong, check whether the target user ID belongs to the API key's own bound/service
account. Some vendors (e.g. Rootly) reject certain user-targeting operations for that synthetic
identity even though the ID format, payload shape, and endpoint are all otherwise correct. Retry with
a different, real human user's ID from the same org before treating this as a connector bug — if that
succeeds, the code is fine and this is just a property of the test data/account, not something to fix.Unknown type "..." or Cannot query field "..." on type "..." on a GraphQL-backed connector — the
hardcoded query/mutation string references a type or field name that doesn't exist in the vendor's
real schema (a guessed/hallucinated name, not a live-data problem). Don't guess a fix from docs
alone — verify the real name with a GraphQL introspection query (__schema/__type) run through a
temporary debug action, per "Verify GraphQL Schemas via Introspection" in
create-connector/reference/custom-connector-setup.md, then fix every occurrence of the wrong name
(check sibling queries/mutations in the same file for the same mistake) and re-test.scope, a filter, an all_X flag) appears to have
no effect — e.g. a scoped mute/unmute or a filtered update behaves like an unscoped/unfiltered one.
This is not a flaky vendor or a bad test value; it means the handler is sending that param in the
query string when the vendor expects the request body (or vice versa), and the vendor is silently
ignoring the misplaced field instead of erroring. Check the action's real API docs for where that
specific param belongs, fix the handler, and check any sibling action (e.g. the corresponding
mute/unmute or enable/disable pair) for the same mistake — don't assume the sibling is correct just
because it wasn't the one that failed.Mark task 8 as completed and note whether iteration is needed.
Mark task 9 as in_progress.
If Task 8 found code issues:
listTools action to discover actual tool names and schemas:
source "$(git rev-parse --show-toplevel)/scripts/kibana_api_common.sh" && kibana_curl -X POST -H "Content-Type: application/json" \
"$KIBANA_URL/api/actions/connector/<connector_id>/_execute" \
-d '{"params":{"subAction":"listTools","subActionParams":{}}}'
Edit to fix the identified issues/chat-with-agentRepeat this loop up to 3 times. If issues persist after 3 iterations, report the remaining problems to the user and move on.
If Task 8 found NO code issues, skip this task entirely.
Mark task 9 as completed.
Mark task 10 as in_progress.
Do one final review using the review-connector skill. Verify no TODOs/placeholders, consistent naming, no debug artifacts. The review skill will also run docs quality checks (docs-check-style, crosslink-validator, frontmatter-audit, content-type-checker, applies-to-tagging) on any connector docs. Make any final minor fixes if needed.
Mark task 10 as completed.
Mark task 11 as in_progress.
Run one final chat conversation to confirm everything works end-to-end:
Skill: chat-with-agent
Args: <agent-id>
Use a more specific prompt this time, something like:
Search for recent items and give me a detailed summary of what you find.
If any action has optional modifier params (scope, filters, all_X flags, an expiry timestamp)
beyond its required fields, make sure this test (or an earlier one) actually causes the agent to set at
least one of them to a non-default value, not just the required-fields-only happy path. A query-param-vs-
body mismatch on an optional param doesn't error — the vendor silently ignores it — so a test that never
sets the param will pass even though the feature is broken.
Verify the agent successfully calls tools, gets results, and produces a useful response.
Mark task 11 as completed.
Mark task 12 as in_progress.
Read create-connector/reference/pr-validation-table.md for the full format and rules, and build the
## Validated markdown section now, while the results from Tasks 5-11 are fresh:
actions map, plus the connectivity test handler
if one exists — no action may be omitted.✅ Pass (noting any bug that
was found and fixed as part of getting it to pass).⚠️ Not validated — needs manual verification rather than leaving the row out.❌ Fail with a short description.Keep this table's markdown handy (in the task output or scratch notes) — it must be included verbatim
under a ## Validated heading in the PR description when this connector's PR is opened, whether that
happens later in this same session or by a human afterward. If a PR already exists for this connector,
add or update the ## Validated section in its description now rather than waiting.
Mark task 12 as completed.
Mark task 13 as completed.
Tell the user something like the below template, listing the actual file paths that were created or modified during the process:
The $ARGUMENTS connector is ready for manual inspection. Here's what was created:
Files created/modified:
- Connector spec:
src/platform/packages/shared/kbn-connector-specs/src/specs/<name>/...- Documentation:
docs/reference/connectors-kibana/<name>-action-type.mdKibana state:
- Connector created with ID:
<id>- Test agent created with ID:
<id>- Test conversations available in Agent Builder
Next steps:
- Open Kibana and navigate to the Agent Builder to inspect the agent
- Try chatting with the agent in the Kibana UI
- Review the generated code and adjust as needed
- When satisfied, commit the code changes and open a PR — include the
## Validatedtable from Task 12 in the PR description, and add therelease_note:featureandFeature:Actions/ConnectorTypeslabels
List the actual file paths that were created or modified during the process, and include the ## Validated
table compiled in Task 12 in your response so the user has it even if they open the PR themselves.
If you open the PR yourself (via gh pr create), apply both labels as part of that same command or
immediately after with gh pr edit <number> --add-label "release_note:feature" --add-label "Feature:Actions/ConnectorTypes".
release_note:feature surfaces the new connector in the condensed release notes; Feature:Actions/ConnectorTypes
routes the PR to the right reviewers and keeps it discoverable alongside other connector-type work. Use these
exact label names/casing — check gh label list --repo elastic/kibana --search <name> if unsure they still exist.