{"id":16577,"plugin_id":"plugins_6a5a24b0c10c81919af5b8855e7de513","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T23:13:32.556Z","digest":"029158ff0df41253b319b3dddd5e716ce13ec090f2a35fdd3c39540064ef1f00","against":null,"payload":{"description":"Read when a user asks what Kora is, how Kora works, how to get started, what the main product concepts mean, why Kora exists, or when a first-time chat onboarding prompt asks for an intro. This is a user-facing tutorial skill, not a workflow-authoring or implementation-detail skill.","included_files":[{"relative_path":"agents/openai.yaml","size_in_bytes":325},{"relative_path":"assets/kora-mark.png","size_in_bytes":24826}],"name":"kora-onboarding-guide","skill_md_contents":"---\nname: kora-onboarding-guide\ndescription: \"Read when a user asks what Kora is, how Kora works, how to get started, what the main product concepts mean, why Kora exists, or when a first-time chat onboarding prompt asks for an intro. This is a user-facing tutorial skill, not a workflow-authoring or implementation-detail skill.\"\n---\n\n# Kora Onboarding Guide\n\nUse this skill to explain Kora to a first-time builder in product-facing\nlanguage. The goal is to orient the user, teach the mental model, and help them\nchoose the next specific topic or workflow to explore.\n\nDo not create files, create a release, deploy anything, inspect secrets, or\nchange workspace state from this skill alone.\n\nWhen the user asks how to start using Kora, distinguish the two product entry\npaths before giving commands:\n\n- Kora SaaS users open `https://kora-eu.raw-labs.com/signup` or run\n  `kora auth login`; the CLI uses that SaaS origin by default, and onboarding\n  provisions their initial organization and production environment.\n- Self-managed users install Kora on infrastructure they control through\n  `kora-self-host`.\n\nDo not present the self-managed bootstrap as a prerequisite for Kora SaaS. If\nthe intended deployment mode is unclear, use Kora SaaS; ask about the target\nonly when the user indicates they operate a self-managed deployment.\n\nRoute to a sibling skill when the conversation shifts:\n\n- Building or editing workflow source -> `kora-workflow-builder`.\n- Where to click in the product (routes, tabs, menus, settings sections,\n  buttons) -> `kora-product-ui`, before naming any of them.\n- Custom extension package work -> `kora-extension-builder`, which first checks\n  whether the target is eligible; hosted Kora SaaS supports Kora-shipped\n  built-ins instead of customer packages.\n\n## Response Shape\n\nWhen the user asks for a broad intro, provide a clear first-pass tutorial rather\nthan trying to exhaust this entire skill in one answer. Prefer clear sections and\nplain product language over implementation details.\n\nDefault broad-intro shape:\n\n1. Start with Kora's product goal.\n2. Explain who Kora is for and the adoption path.\n3. Cover the core concepts at overview depth.\n4. Explain that workflow building and workflow improvement happen\n   conversationally in chat.\n5. Explain how change control, events, and governance keep the workflow\n   inspectable and controlled.\n6. End with follow-up questions the user can choose from.\n\nDo not cover every concept in detail unless the user explicitly asks for a deep\ndive. Keep the first answer concise enough to be a good onboarding conversation\nopener.\n\nAfter the explanation, offer focused follow-up questions rather than a long\nintake form. Good defaults include:\n\n- Want to walk through a concrete example workflow?\n- Want to map an existing process into Kora?\n- Want to understand orgs, people, agents, capabilities, and operations?\n- Want to see how governance, events, releases, and deployments work?\n- Want to build your first workflow in chat?\n\n## Base Intro\n\nKora is a workflow operating system for important operational business\nprocesses.\n\nIt is for teams that already have real workflows: approvals, escalations,\nexception handling, quality reviews, fulfillment decisions, maintenance\nhandoffs, change-control paths, or other processes where execution needs to be\nreliable and explainable.\n\nKora is not a lightweight automation toy and not a chat demo wrapped around\nshallow automations. Its product promise is controlled execution. Workflows\nshould be deterministic where that matters, observable while they run, auditable\nafter they finish, approval-aware, and integrated with the systems a company\nalready uses.\n\nA good Kora rollout usually starts with one important workflow. First mirror the\nexisting human process faithfully. Then make it executable, visible, and\nauditable. Once the baseline is trusted, selected steps can move from humans to\nagents without throwing away the workflow model.\n\n## Who Kora Is For\n\nKora is primarily for companies that care about operational reliability and\ncontrolled workflow change.\n\nTypical users include:\n\n- forward deployed engineers or technical implementation leads who understand a\n  customer's operational process\n- operators who need to see runs, tasks, failures, and approvals\n- process owners who care about auditability, handoffs, and controlled change\n- builders who refine workflows and gradually increase automation depth\n\nKora is a good fit when the workflow matters enough that the team needs to know\nwhat changed, what ran, who approved, what failed, and which release was live.\n\n## Adoption Path\n\nExplain the adoption path as a sequence:\n\n1. Mirror the existing workflow.\n   Start with the real human process. Preserve the important steps, decisions,\n   approvals, vetoes, and escalation paths.\n2. Prove reliability.\n   Make the workflow executable and observable. Use releases, deployments,\n   activity, runs, tasks, and failure evidence to build trust.\n3. Introduce agents selectively.\n   Move one step at a time from human ownership to agent ownership only where it\n   is useful and safe. Keep risky or approval-sensitive steps human-owned.\n4. Expand.\n   After one workflow works, add more workflows, integrations, and deeper\n   automation.\n\nThe first successful workflow should usually be narrow enough to model and test\nclearly, but important enough that observability, approvals, and auditability\nmatter.\n\n## Core Concepts\n\nUse this as the concept map. Teach only as much as the user needs in the first\nanswer, but keep the relationships clear.\n\n| Concept | What it is |\n| --- | --- |\n| Organization | The Kora workspace/tenant: access members, chat sessions, releases, environments, deployments, runtime configuration, and operational history. |\n| Access members | Real humans who log in to Kora. They live in the product access model, not in workflow source; their roles decide what they can do in the workspace. |\n| Modeled people | Participants inside a workflow design (reviewer, approver, planner, field technician, escalation or process owner). Not login accounts. |\n| Agents | AI assignees in the workflow model. An agent performs a task when a role assignment resolves to it and the capability has agent configuration. |\n| Roles | Ownership slots in a process (reviewer, dispatcher, approver, technician, escalation owner, compliance reviewer, purchasing owner). A task references a role. |\n| Assignments | Map roles to modeled people or agents -- the link between ownership slots and actual assignees. They let Kora preserve the workflow shape while changing who performs a step. |\n| Capabilities | Describe the work a task needs (triage, approval, review, classification, investigation, reconciliation, drafting, exception analysis). Can include human guidance, agent instructions, and output rules. |\n| Operations | Service actions for custom code, data transformation, system lookups, notifications, or API calls. A service node calls an operation directly; a task routes work to a person or agent. |\n| Extensions | How Kora connects to external systems. Expose functions for operations, tools/skills for agents, settings panels, callbacks, and schedules. Installed into environments; deployment validates the target has what the workflow needs. |\n| Workflows | The workflow graphs: starts, tasks, service nodes, decisions, gateways, waits, timers, receives, calls to other workflows, and ends. BPMN-inspired, not a strict BPMN runtime -- the goal is to translate real operational process meaning into a reliable executable model. |\n| Starts and triggers | A workflow starts from a message, a schedule, or another workflow call; the start defines expected input and where execution begins. For first workflows, frame it in business terms: what event, request, or exception begins the process? |\n| Tasks | Units of work assigned to a person or agent: human decisions, agent analysis, structured outputs, approvals, vetoes, or handoffs. Actions are the product surface for pending human tasks. |\n| Decisions and gateways | Control routing -- approve, reject, escalate, retry, wait, branch, or end. Make decision points explicit instead of hiding them in unstructured instructions. |\n| Source workspace | The proposal area for authored workflow source; may start empty; used for drafting, validation, and safe smoke tests. Not the live runtime -- edits change nothing live until the user creates a release and deploys it. |\n| Releases | Immutable snapshots of authored source. Creating one freezes the proposal but makes nothing live. Use them to review, validate, compare, and preserve versions. |\n| Environments | Deployment targets and runtime-configuration scopes (e.g. production, staging). Own runtime variables, secret metadata, extension installs, deployment policy, and the live deployment pointer. |\n| Deployments | An attempt to apply a release to an environment. Success becomes live; a failed deployment is retained for audit but does not replace the live workflow. Return to an older workflow by deploying that older release again. |\n| Runs | Workflow executions. A run shows what started, which steps happened, what state was produced, and what failed, waited, or completed. |\n| Activity and events | The operational history across runs, tasks, failures, approvals, deployments, and changes. Part of the product value, not incidental logging. |\n\nKey distinctions to keep clear when teaching:\n\n- The organization (tenant) is not the modeled organization inside a workflow\n  release.\n- Access members (login accounts, managed in Settings) are not modeled people\n  (defined inside a release).\n- A task references both a role and a capability; the role assignment decides\n  whether the human path or the agent path runs.\n- Agents are not the default answer. Make it normal to start with human work,\n  move selected steps to agents later, and move them back when needed.\n\n## Conversational Workflow Building\n\nKora's primary authoring experience is conversational.\n\nA builder can describe a workflow in plain language, paste process notes,\nupload existing documentation, or ask Kora to inspect current live state. Kora\nthen helps turn that conversation into a structured workflow model: people,\nagents, roles, assignments, capabilities, operations, decisions, process steps,\nreleases, and deployment targets.\n\nUseful first messages include:\n\n- \"Turn this process into a Kora workflow.\"\n- \"Ask me the questions needed to build the first workflow.\"\n- \"I will paste process notes. Extract the roles, decisions, approvals, and\n  open questions.\"\n- \"Start with a mock integration until the real system is connected.\"\n- \"Make this approval workflow visible and auditable before we automate it.\"\n\nKora should ask focused questions, usually one at a time. The main things to\nlearn are:\n\n- what starts the workflow\n- who participates\n- what decisions exist\n- what human approvals or vetoes matter\n- which systems are involved\n- what can fail\n- what needs to be visible later\n- what should be mocked until a real integration exists\n- where the workflow should eventually run\n\nChat edits are proposals until the user explicitly asks to create a release.\nA release freezes the proposal. A deployment makes a release live in an\nenvironment. This keeps conversation fast while preserving controlled change\nmanagement.\n\n## Conversational Improvement\n\nKora is not only for creating the first workflow. Users can improve workflows by\nasking for changes in chat.\n\nExamples:\n\n- \"Add an approval step before fulfillment.\"\n- \"Make this agent step human-owned for now.\"\n- \"Explain what changed since the last release.\"\n- \"What failed in production?\"\n- \"Where are approvals getting stuck?\"\n- \"Make this workflow safer before we deploy it.\"\n- \"Use a mock integration until the real system is connected.\"\n- \"Turn these process notes into a first workflow proposal.\"\n- \"Compare the live workflow to the release I just created.\"\n- \"Draft a safer rollout plan.\"\n\nAs with new workflows, improvements stay proposals until the user creates a\nrelease and deploys it, so iteration stays fast without changing production\nbehavior.\n\n## Governance, Auditability, And Operational Confidence\n\nKora is designed for workflows where change control matters.\n\nImportant governance surfaces:\n\n- source proposals explain what Kora is drafting\n- releases create immutable snapshots\n- deployments record what was applied to each environment\n- runs show what happened during execution\n- tasks show pending human work and completion decisions\n- activity and events provide operational history\n- failures can be investigated instead of disappearing into logs\n- approvals, vetoes, escalations, and agent handoffs stay visible\n\nThis model helps teams answer governance questions:\n\n- What release was live in the environment?\n- Who or what performed the work?\n- Which decision path was taken?\n- What input was available at the time?\n- What failed, retried, waited, or escalated?\n- What changed between the old workflow and the new one?\n- Can we safely move this human step to an agent?\n- Can we move it back if needed?\n\nThe point is not just to automate work. The point is to make important work\nexecutable, observable, reviewable, and improvable.\n\n## Humans And Agents\n\nExplain human and agent ownership as a strength of the product.\n\nKora should not pressure the user into full autonomy on day one. The safer path\nis:\n\n1. model the workflow with human tasks and approvals\n2. prove that the workflow runs reliably\n3. identify one step where agent help is useful\n4. give the agent bounded instructions, tools, and output expectations\n5. keep approvals or escalation where risk remains\n6. review activity and failures before expanding automation\n\nThe same workflow model can support human and agent work. The user should not\nneed to throw away the workflow to change who owns a step.\n\n## Integrations And External Systems\n\nKora integrates with external systems through explicit modeled behavior.\n\nUse generic language unless the user names a provider or extension discovery\nconfirms a provider is available. Say \"a system of record\",\n\"messaging channel\", \"approval system\", \"ticketing system\", or \"installed\nextension\" rather than inventing a provider.\n\nWhen a real integration is not connected yet, suggest a clearly labeled mock\nstep with representative inputs and outputs. This lets the user test the\nworkflow shape before adding credentials or provider setup.\n\n## Good First Use Cases\n\nGood first Kora workflows are important, bounded, and approval-aware.\n\nExamples:\n\n- quality deviation or non-conformance handling\n- maintenance or production escalation\n- change-control approval\n- procurement or fulfillment exception handling\n- order exception routing\n- field-service escalation\n- support escalation with human approval\n- compliance review handoff\n- incident triage and escalation\n\nThe best first workflow usually has:\n\n- a clear trigger\n- a known process owner\n- one or more human decisions\n- a real operational consequence\n- a visible success outcome\n- enough pain that observability matters\n- enough boundaries that it can be modeled safely\n\n## What Not To Do In The Intro\n\n- Do not describe Kora as generic no-code automation.\n- Do not imply agents should own the whole workflow immediately.\n- Do not blur source proposals, releases, deployments, and live runs.\n- Do not say workspace files are already live.\n- Do not expose implementation details unless the user asks.\n- Do not claim current org state unless you inspected authoritative state.\n- Do not name exact UI routes or buttons unless you have read\n  `kora-product-ui`.\n\n## Closing Question\n\nEnd the broad intro with exactly one question:\n\n> What would be most useful to focus on next: a concrete example workflow, the\n> core concepts, importing an existing process, or building your first workflow\n> in chat?\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}