sgc-install-ai

Install AI capabilities

Wire up an App's AI capabilities in one pass, from product entry point and invocation channel to model strategy and optional UI; the generated user interface only presents the capabilities the user needs, without exposing the background, account, or channel details from this request.

Triggers

Activate when

• The user says "add AI capabilities to this App", "initialize AI invocation", or "add a chat/summary/generation entry point".
• The user mentions Agent Client, MaaS relay channel, model preferences, model routing, or optional AI UI.
• User asks to “add AI to this app”, “bootstrap an AI feature”, or “connect an app to an Agent Client or MaaS”.

Do not activate when

• The user only wants to invoke an existing script or do a one-off model test in the development environment; use the current project's development toolchain.
• The user only wants to configure the global account or API Key for a certain Agent Client, without changing App functionality; use that Client's or MaaS's configuration process.

User Configuration

This Skill stores only portable preferences such as route order, model intent, language, and UI default. Resolve them through references/user-config.md; never store API keys, tokens, private endpoints, or project paths in source control.

Workflow (MANDATORY)

You MUST follow these steps in order.

Step 0: Inspect the App and define one user outcome

• Identify the stack, runtime surfaces, authentication model, existing backend boundary, and the user action that AI improves.
• Separate internal implementation context from product copy. Do not put provider names, personal notes, model names, or setup history in the user-facing UI unless they are a deliberate user choice.
• Default to one narrow capability such as rewrite, extract, classify, chat with a scoped source, or generate a structured draft; do not add a generic chat box without a product job.

Step 1: Resolve the integration choices

• Reuse explicit project context and saved preferences first. If a choice remains product-visible, present this compact selection:
  1. Agent Client — use only when the App runs locally and the user has a compatible local Client/bridge.
  2. MaaS — use a server-side gateway for web, mobile, shared, or production traffic.
  3. Hybrid — use MaaS as the product runtime and an Agent Client only for local desktop/developer enhancement.
• Select a model intent rather than hard-coding a provider model: fast, balanced, reasoning, vision, or creative.
• Ask whether user-facing UI is needed only when the feature can reasonably be headless or interactive. Infer a focused UI for user-initiated App features.
• Read references/runtime-routing.md and, when adding UI, references/ai-feature-ui.md.

Step 2: Add the product boundary

• Create one typed feature contract: input, validated request, selected model intent, streamed or non-streamed response, error shape, and usage metadata.
• Put MaaS credentials and upstream routing on a server-side gateway. The browser/mobile client calls the App's own endpoint, never an upstream secret directly.
• Implement Agent Client support behind the same adapter contract. Detect availability at runtime; expose a clear unavailable state and do not block the whole App when it is absent.
• Keep provider routing, retries, rate limits, telemetry, and raw provider errors outside user-visible copy.

Step 3: Add UI only when the product needs it

• Reuse the App's existing component, locale, loading, and error conventions.
• Build the smallest complete interaction: purposeful entry point, input constraints, pending state, result rendering, retry, and accessible keyboard behavior.
• Show model preference only when the end user benefits from controlling trade-offs. Otherwise keep it as a product or profile preference.
• For generated content, provide a next action meaningful to the App: insert, apply, save, copy, compare, or discard.

Step 4: Validate an end-to-end route

• Test Agent Client present, Agent Client absent, MaaS success, MaaS failure, slow or streaming response, and malformed model output as applicable.
• Verify no credential, internal route, provider stack trace, or private prompt appears in source, network payloads, logs, or final UI.
• Run the target project's format, lint, typecheck, tests, and a real user interaction through the selected route.
• Report the chosen runtime route, configured model intent, UI decision, fallback behavior, and user-visible result.

Dependencies

• A target App with a known frontend and/or server boundary.
• A compatible local Agent Client bridge, a configured MaaS gateway, or both.

General feedback loop

When the user raises modification feedback during a Skill-driven task, before continuing with the current artifact you must do the following:

1. First determine whether the feedback is task-specific(this time only) or reusable(reusable across tasks).
2. task-specific Modify only the current task, do not change the Skill.
3. reusable First determine the scope: for domain rules, first update the corresponding canonical Skill; for rules that apply to all Skills, first update the shared specification.
4. After completing rule updates, versioning, lint, and distribution verification, then apply the modification to the current task.
5. reusable The modification invalidates previous "confirm", "continue", and "send it" responses; after completing the current artifact modification and read-back, you must stop and wait for the user's next instruction, without automatically proceeding to publishing, submission, or other external writes.