القائمة
Step 2 of building a generic Falcon connector. Asks which authentication type the provider uses, generates the correct YAML auth block from patterns, and writes it into the connector config file.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Step 4 of building a generic Falcon connector. Generates YAML action configurations for all confirmed actions using actionType custom, writes partial files per resource, and updates the main connector YAML with $ref links.
Step 1 of building a generic Falcon connector. Checks StackOne's provider index via MCP, detects CLI availability, and either pulls an existing connector base config or scaffolds a new one.
Interactive wizard for building a generic Falcon connector. Guides builders through provider setup, authentication, action discovery (scoped or maximal), YAML config generation, validation, and live testing with cleanup. Auto-triggers when someone asks to build a new connector, add a new provider, or create a Falcon config.
Step 5 of building a generic Falcon connector. Validates the generated YAML config using the StackOne CLI (or a manual checklist if CLI is unavailable), interprets and fixes common errors, then confirms the connector is ready for live testing.
Step 2 of building a unified connector. Checks if the StackOne CLI is available, looks up whether the connector already exists in the StackOne index, and either pulls it down or scaffolds a new one based on auth type.
Step 4 of building a unified connector. Guides the builder through mapping provider API fields to their schema using fieldConfigs. Writes or updates the connector YAML partial files for each resource.
| name | configure-auth |
| description | Step 2 of building a generic Falcon connector. Asks which authentication type the provider uses, generates the correct YAML auth block from patterns, and writes it into the connector config file. |
| invoke | configure-auth |
Step 2 of the generic connector build process.
Read .connector-build-session.json. Confirm:
"Configuring auth for
{{provider}}."
Read ${CLAUDE_PLUGIN_ROOT}/references/auth-patterns.md before starting.
Ask:
"How does
{{provider}}'s API authenticate requests?A) API Key / Bearer token — static key passed in a header B) OAuth 2.0 — users authorise via a browser flow C) Basic Auth — username and password D) API Key in query parameter — key appended to the URL E) Something else — describe it and I'll help figure it out
(A/B/C/D/E)"
Ask for the specific values needed:
{{provider}} expect? (e.g., Authorization: Bearer ..., X-API-Key: ...)"api_key, token)"auth-patterns.mdRead connectors/{{provider}}/{{provider}}.connector.s1.yaml.
Replace the authentication: {} placeholder with the correct pattern from auth-patterns.md.
Also set baseUrl:
"What is the base URL for
{{provider}}'s API? (e.g.,https://api.provider.com/v1)"
If unknown, use placeholder: baseUrl: "# TODO: set provider base URL".
Tell the builder exactly what to add to .env:
"Add these to your
.envfile before testing:{{PROVIDER_CREDENTIAL_VARS}} ```"
Show the written auth block and ask:
"Does this look right? The credentials stay in
.env— the YAML only references them by variable name."
Apply any corrections.
Save to session:
auth_type: The authentication type (custom or oauth2)auth_details: Full auth configuration including header names, credential references, and authorization type (e.g., { "authorization_type": "none", "custom_headers": [{ "name": "X-Api-Key", "value": "$.credentials.apiKey" }] }). This is needed by /build-config to add the correct auth headers to each action's request step."Auth configured. ✓
Next: choose which actions to build. Run
/discover-actionsto continue."
Update session_step to "discover-actions".