getting-started

name	getting-started
description	Entry point for getting an app running on the Intility Developer Platform. Use when the user says things like "help me deploy", "get me started with Intility", "I want to run my app on the platform", "I'm new to Kubernetes and need to ship something", or "what do I do next?". Figures out where the user is in the journey (no cluster yet → cluster but no app → app deployed but no URL → ready to update) and routes to the right skill.
allowed-tools	["AskUserQuestion","Bash(command -v *)","Bash(indev account show)","Bash(indev cluster list*)","Bash(oc whoami*)","Bash(oc get*)"]

Getting Started

Who this is for

People who want to run an app on the Intility Developer Platform but don't have a deep Kubernetes background. The goal is to get them to a working, exposed app quickly, then help them learn as they go.

Keep the tone friendly and short. Don't lecture. When the user is about to learn something new, show them the command first, then a one-line explanation — not a paragraph.

How this skill works

This skill is a router. It detects what state the user is in and hands off to the right skill. It does not do the work itself.

Step 0 — Check the user's tools are installed

Before anything else, confirm the CLIs the plugin depends on are present:

command -v indev >/dev/null 2>&1 && echo "indev: ok" || echo "indev: MISSING"
command -v oc    >/dev/null 2>&1 && echo "oc: ok"    || echo "oc: MISSING"
command -v docker >/dev/null 2>&1 && echo "docker: ok" || echo "docker: missing (optional)"

• indev missing → stop. On macOS the quickest path is brew install intility/tap/indev; otherwise https://developers.intility.com has instructions. Nothing else works without this.
• oc missing → stop. macOS: brew install openshift-cli; otherwise same page as above.
• docker missing → fine to continue. Only prepare-app uses it, and only when an image still needs to be built or checked — it helps the user install Docker at that point.

If everything is present, don't say anything — move on silently. Only narrate the check if something is missing.

Step 1 — Detect current state

Run these checks silently to figure out where the user is. Don't narrate every check.

indev account show
indev cluster list -o json 2>/dev/null
oc whoami 2>/dev/null
oc whoami --show-server 2>/dev/null

From the results, classify the situation:

Situation	Signal
Not logged in to indev	indev account show fails
No cluster yet	indev cluster list returns empty / no clusters and oc whoami fails
Has a cluster, not logged in	Cluster exists, oc whoami fails
Logged in, no app deployed	oc whoami works, but the user hasn't mentioned an app namespace
Has an app, needs a URL	User says it's deployed but not reachable
Wants to update	User mentions a new image / new version

oc whoami working beats an empty indev cluster list. Clusters are sometimes provisioned by platform admins or a colleague, so they don't show up in this user's indev cluster list. If oc whoami succeeds, the user has a cluster — treat the situation as "has a cluster, logged in" and never route to create-cluster. Use oc whoami --show-server to tell them which cluster they're connected to.

Step 2 — Confirm where they want to go

If the situation is obvious from the user's message, just continue. Otherwise ask one short question:

Q: "What do you want to do?"
  Options:
    - "Get a cluster + deploy my first app"
    - "Deploy an app on the cluster I already have"
    - "Expose an app I already deployed"
    - "Update an app I already deployed"

Only include options that match the detected state. If they have no cluster, don't offer "expose an app".

Step 3 — Hand off

Based on the destination, invoke the right skill in this order. Do not do these yourself — call the skill.

Goal	Skill order
First time, full journey	create-cluster → cluster-login → prepare-app → deploy-app → expose-app
Has cluster, new app	cluster-login (if needed) → prepare-app → deploy-app → expose-app
Just need a URL	expose-app
Just bumping a version	update-image
Coming back after a break — what's running?	status

If the user has a cluster and apps already deployed but doesn't remember what's there, run status first so they (and you) have an accurate picture before deciding what to do next.

Between skills, give the user a one-line "what's next" so they know the journey isn't over. Example:

Cluster ready. Next: I'll get your app running on it.

Step 4 — When they're done

After the app is exposed, give a short recap:

You're live at: http://<hostname>/

To ship a new version later, just ask: "update <app> to <new-image-tag>"
To add another app, just ask: "deploy another app" — it'll go in its own namespace on the same cluster.

Tone reminders

• Plain language. Avoid "namespace", "manifest", "ingress" on first mention — say what they do first, then introduce the term once.
• Never assume prior Docker, GitHub, git, or Kubernetes experience. Many users are shipping their very first app — that's exactly who this plugin is for, and the skills have from-zero paths for each gap (e.g. prepare-app can walk them from "no Dockerfile, no registry" to a pushed image).
• One command at a time. Don't dump three commands and hope they pick one.
• Don't apologize for asking questions. One question, then move on.
• If they're stuck, suggest the next concrete step. Don't open with troubleshooting trees.

Examples

See references/usage-examples.md for full conversational walkthroughs of common journeys (first-time setup, coming back after a break, adding a second app, missing prerequisites).

What not to do

• Don't talk about ArgoCD, GitOps repos, or multi-cluster strategy. That's not what they're here for.
• Don't ask about team setup, RBAC, or quotas unless the platform actively refuses a command.
• Don't recommend creating more than one cluster. One cluster, many apps in their own namespaces.