lokei
Run local web and app development surfaces behind named HTTPS `.test` domains with `lokei`, and optionally expose them through tunnels. Use for local HTTPS setup, framework-aware dev-server startup, tunnel sharing, Docker Compose HTTPS, and lokei diagnostics.
What this skill does
<EXTREMELY-IMPORTANT> `lokei` affects the local networking environment and can trigger setup flows. Non-negotiable rules: 1. Verify `lokei` availability before relying on it. 2. Do not auto-run one-time setup or uninstall flows without approval. 3. Resolve whether the user wants local-only HTTPS, a public tunnel, or multi-service orchestration. 4. Prefer the simplest command that matches the job. 5. Report the resulting URLs and diagnostic blockers clearly. </EXTREMELY-IMPORTANT> # lokei ## Inputs - `$request`: The local HTTPS, share, Docker, service, or diagnostics task ## Goal Use `lokei` to: - run a local project behind a named HTTPS `.test` domain - expose a local service through a tunnel when requested - orchestrate Docker or multi-service local environments - diagnose and explain local proxy/setup problems ## Step 0: Verify installation and setup health Check: - `lokei --version` - `lokei doctor` If `lokei` is missing, tell the user: > `lokei` is not installed. Install with: > ```bash > npm i -g lokei && lokei setup > ``` > `lokei setup` runs once -- generates a local CA, trusts it in the OS keychain, configures DNS for `.test`, and sets up port forwarding. Do not install or run setup automatically. Wait for user confirmation. If setup is unhealthy: - explain the failing component - common fixes: CA not trusted or DNS resolver missing -> re-run `lokei setup` - ask before suggesting or running one-time setup actions **Success criteria**: `lokei` is available and its setup state is understood. ## Step 1: Resolve the requested mode Determine whether the user wants: - `lokei run` for one local app - `lokei share` or `lokei run --expose` for public access - `lokei docker up` for Docker Compose - `lokei up` for `.test.yaml` orchestration - `lokei routes ls`, `inspect`, or `logs` for diagnosis Also resolve whether the project name, command, or port needs to be overridden. **Success criteria**: The correct lokei mode is chosen before execution. ## Step 2: Run the smallest correct command Prefer: - `lokei run` for normal local development - `lokei share --port <port>` for ad-hoc sharing - `lokei run --expose` when the same session needs local HTTPS and a public tunnel - `lokei docker up` or `lokei up` only when the project structure actually calls for them Avoid service-install and uninstall flows unless the user explicitly asked for those operations. **Success criteria**: The executed command matches the requested workflow without overreaching. ## Step 3: Report URLs and health clearly After execution, report: - local `.test` URL - public tunnel URL if one was created - project name and route details if relevant - any doctor/setup blockers if the command failed **Success criteria**: The user knows exactly where the app is reachable and what failed if it is not. ## Guardrails - Do not auto-run `lokei setup`, `service install`, or `uninstall` without approval. - Do not guess that the user wants a public tunnel when local-only HTTPS is enough. - Do not hide diagnostics behind generic "setup failed" summaries. - Do not add `disable-model-invocation`; this is a normal environment workflow skill. ## When To Load References - `references/command-reference.md` Use for the full command catalog, framework detection table, architecture details, `.test.yaml` examples, git worktree behavior, and scenario quick reference. ## Output Contract Report: 1. mode chosen 2. command run 3. resulting local or public URLs 4. any detected setup or networking blocker 5. next action if user approval is required
Related in Cloud & DevOps
appbuilder-action-scaffolder
IncludedCreate, implement, deploy, and debug Adobe Runtime actions with consistent layout, validation, and error handling. Use this skill whenever the user needs to add actions to an App Builder project, understand action structure (params, response format, web/raw actions), configure actions in the manifest, use App Builder SDKs (State, Files, Events, database), deploy and invoke actions via CLI, debug action issues, or implement patterns such as webhook receivers, custom event providers, journaling consumers, large payload redirects, action sequence pipelines, and Asset Compute workers. Also trigger when users mention serverless functions in Adobe context, action logging, IMS authentication for actions, or cron-style scheduled actions.
orchestrating-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. Use this skill when the user needs a multi-step Data Cloud pipeline, cross-phase troubleshooting, or data space and data kit management. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase sf data360 workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching phase-specific skill), the task is STDM/session tracing/parquet telemetry (use observing-agentforce), standard CRM SOQL (use querying-soql), or Apex implementation (use generating-apex).
github-project-automation
IncludedAutomate GitHub repository setup with CI/CD workflows, issue templates, Dependabot, and CodeQL security scanning. Includes 12 production-tested workflows and prevents 18 errors: YAML syntax, action pinning, and configuration. Use when: setting up GitHub Actions CI/CD, creating issue/PR templates, enabling Dependabot or CodeQL scanning, deploying to Cloudflare Workers, implementing matrix testing, or troubleshooting YAML indentation, action version pinning, secrets syntax, runner versions, or CodeQL configuration. Keywords: github actions, github workflow, ci/cd, issue templates, pull request templates, dependabot, codeql, security scanning, yaml syntax, github automation, repository setup, workflow templates, github actions matrix, secrets management, branch protection, codeowners, github projects, continuous integration, continuous deployment, workflow syntax error, action version pinning, runner version, github context, yaml indentation error
sf-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase `sf data360` workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching sf-datacloud-* skill), the task is STDM/session tracing/parquet telemetry (use sf-ai-agentforce-observability), standard CRM SOQL (use sf-soql), or Apex implementation (use sf-apex).
fabric-cli
IncludedUse this skill for Fabric.so CLI workflows with the `fabric` terminal command: diagnose/install/login, search or browse a Fabric library, save notes/links/files, create folders, ask the Fabric AI assistant, manage tasks/workspaces, generate shell completion, check subscription usage, produce JSON output, and use Fabric as persistent agent memory. Do not use for Microsoft Fabric/Azure/Power BI `fab`, Daniel Miessler's Fabric framework, Python Fabric SSH, Fabric.js, or textile/fashion fabric.
lark
IncludedLark/Feishu CLI skills: lark-cli operations for docs, markdown, sheets, base, calendar, im, mail, task, okr, drive, wiki, slides, whiteboard, apps, approval, attendance, contact, vc, minutes, event. Use when the user needs to operate Lark/Feishu resources via lark-cli, send messages, manage documents, spreadsheets, calendars, tasks, OKRs, deploy web pages, or any Feishu/Lark workspace operations.