> ## Documentation Index
> Fetch the complete documentation index at: https://docs.flashduty.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Setup (/init)

> Type /init in an AI SRE session and the agent turns into an onboarding interviewer, building your operational knowledge base from scratch (DUTY.md + runbooks + service catalog and more) and connecting MCP as needed — every write is confirmed by you, item by item.

<Info>
  **Private beta**: AI SRE is currently in private beta. Pro or higher accounts can apply for free beta access through the [AI SRE private beta application form](https://c9xudyniiq.feishu.cn/share/base/form/shrcn0ngCfdoygiaHnAT80BfZiH); after approval, Flashduty will add your account to the whitelist. Features and the UI may change during the beta.
</Info>

## Overview

***

Type `/init` in the input box of any AI SRE session, and the agent switches into an **operational onboarding interviewer** that walks you through building an operational knowledge base from scratch — your team's "operational map." It scans your Flashduty incidents and notification channels, asks you questions, captures the service topology, runbooks, cluster access, and more that you describe into knowledge files, and helps you connect external tools (MCP) when needed.

`/init` is the **starting point** for the knowledge base. AI SRE's diagnostic quality depends directly on how much real knowledge it can read about your systems: the more complete and accurate your [Knowledge](/en/ai-sre/knowledge) base is, the faster and more reliably the agent pinpoints root causes. `/init` is the guided flow that builds that knowledge from zero — and once it's built, every session loads it automatically.

<Note>
  `/init` will **never** write or install anything without your consent. Before anything lands at each phase, it lists exactly "which files will be created/updated," and only acts after you confirm them one by one. Credentials (tokens, passwords, AK/SK) are never echoed back in plain text in the conversation — only recorded as `<recorded (length=N)>`. See [Safety & consent](#safety--consent).
</Note>

## When to use /init vs. plain natural language

***

`/init` is for **structured setup from scratch / systematic backfilling**; small, one-off edits don't need it.

| Scenario                                                               | What to use                                                                                                                     |
| ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| Setting up a knowledge base for an account / team for the first time   | **`/init`** — it works through services, observability, runbooks, common failures, cluster access, and more as a coherent whole |
| Systematically backfilling or restructuring an existing knowledge base | **`/init`** — rerun it anytime; it continues from what's already there rather than starting over                                |
| "Add a runbook," "update services.md," "record this failure mode"      | **Just say it in natural language** — no `/init` needed; the agent reads, edits, and saves within the current session's scope   |

<Tip>
  `/init` and one-off natural-language edits are complementary: use `/init` to lay the foundation in full, then incrementally maintain it during day-to-day troubleshooting by simply telling the agent to "record this lesson in the knowledge base." Both write to the same knowledge base.
</Tip>

## How to run

***

<Steps>
  <Step title="Type /init in a session">
    Type `/init` in the input box of any AI SRE session and send it. No parameters are required.
  </Step>

  <Step title="Confirm the scope">
    `/init` first locks the scope it will write to: **account level** (visible to all sessions in the account) or a specific **team level** (loaded only in that team's sessions). The scope is determined by whether the current session is bound to a team, and the agent confirms it with you first; a single session locks one scope and does not switch mid-way.
  </Step>

  <Step title="Follow the interview">
    The agent asks questions phase by phase, topic by topic (services and topology, observability, runbooks, common failures, cluster access, and so on), turning your answers into draft knowledge files. At the end of each phase it asks whether to "continue to the next item or stop here for now."
  </Step>

  <Step title="Confirm each item before it writes">
    Before anything lands at each phase, the agent presents a list of "which files will be created/updated," each with a 3–5 line summary. Only after you confirm does it write to the knowledge base and link the new files into the `DUTY.md` table of contents.
  </Step>

  <Step title="Pause or rerun anytime">
    You can say "skip this," "go back to step N," or "stop here" at any time. `/init` is not a one-shot run — typing `/init` again at any later point continues backfilling from the existing knowledge.
  </Step>
</Steps>

## The interview

***

`/init` works through a fixed sequence of phases, each with clear entry and exit conditions. You can skip, go back, or stop at any time.

<AccordionGroup>
  <Accordion title="Phase 0 — Lock the scope" icon="crosshairs">
    Reads the team bound to the current session: if a team is bound, this `/init` run lands at that team level; if it's an account-level session, it lands at the account level (visible to all teams). The agent confirms this with you first, and once confirmed the entire session uses that single scope. To switch to a different team's scope, exit and reopen `/init` from the target team.
  </Accordion>

  <Accordion title="Phase 1 — Scan" icon="radar">
    Pulls your channels, incidents from the last 30 days, teams, and members via the Flashduty MCP, then infers the integration types you use and your most frequent incident labels. If the scan comes back empty (a brand-new account), it switches to "cold start" mode and collects everything through the interview instead.
  </Accordion>

  <Accordion title="Phase 1.5 — Import from local AI coding tools (optional)" icon="file-import">
    An optional, opt-in step that is never triggered automatically. If you have already accumulated knowledge and memory in local tools like Claude Code / Codex / Cursor / Windsurf / Copilot / Gemini CLI, you can import it in one pass so the later phases build on it instead of re-asking. When the Runner can reach those files directly (a self-hosted Runner installed on your own machine), the agent reads `~/.claude/CLAUDE.md`, each repo's `CLAUDE.md` / `AGENTS.md`, `.cursor/rules`, memory stores, and so on. Otherwise (cloud sandbox, or a Runner on another host), the agent hands you two universal prompts to run locally and paste / upload back. Imported content is routed by what it is: operational / service knowledge goes into knowledge-pack files, personal preferences and reusable habits go into agent memory, and duplicate or generic items are dropped. Everything imported is **secret-redacted** before any preview or write — secrets are never persisted.
  </Accordion>

  <Accordion title="Phase 2 — Synthesis & correction" icon="circle-check">
    The agent plays back the picture it sees in a single paragraph: "I see N channels, M incidents in the last 30 days, you appear to use \[list], and your high-frequency labels include \[list]. Is that right? What's missing?" It waits for you to confirm or correct, and **does not write any files at this point**.
  </Accordion>

  <Accordion title="Phases 3–7 — Topic-by-topic collection" icon="layer-group">
    Collects and writes content phase by phase, topic by topic. Every phase follows the same loop: "collect → draft files → show a preview list → you confirm → write and update the DUTY.md table of contents":

    | Phase | Topic                            | Produces                                                      |
    | ----- | -------------------------------- | ------------------------------------------------------------- |
    | 3     | Services & topology              | `services.md` (+ optional `topology.md`)                      |
    | 4     | Observability stack              | `observability.md` + registers the relevant MCP in `tools.md` |
    | 5     | Runbooks                         | `runbooks/<topic>.md`, one file per failure class             |
    | 6     | Common failures                  | `common-failures.md`                                          |
    | 7     | Cluster access & runtime probing | `clusters.md` (k8s) / appended to `tools.md` (MCP)            |

    <Note>
      In Phase 7, **native kubectl is the primary way to access a cluster**, with k8s-MCP as a fallback (never configure both for the same cluster). This path is BYOC-only: place a **read-only** kubeconfig for each cluster on the Runner (`<workspace>/.kube/<name>.config`); `clusters.md` records only the **path**, never the token.
    </Note>
  </Accordion>

  <Accordion title="Phase 8 — Close" icon="flag-checkered">
    When you indicate you're done, the agent gives a short summary: which files it created/updated this run, which MCP it registered, and a reminder that "rerunning `/init` anytime picks up where you left off." The knowledge base itself is the durable result of this session.
  </Accordion>
</AccordionGroup>

## Safety & consent

***

`/init` writes knowledge, may install MCP, and touches credentials, so consent and least privilege are hard constraints:

<AccordionGroup>
  <Accordion title="Per-item explicit consent" icon="hand">
    Any write or install requires your explicit consent. Before anything lands, each collection phase lists "which files will be created/updated" (each with a 3–5 line summary), and it only proceeds after you say yes — it never triggers a write off a vague "ok."
  </Accordion>

  <Accordion title="Credentials are never echoed" icon="key">
    When you provide sensitive information such as a token, password, or AK/SK, the agent only confirms "recorded (length=N)" and never reprints the plaintext in the conversation.
  </Accordion>

  <Accordion title="Least-privilege credentials" icon="lock">
    Whenever you need to provide or generate a credential (kubeconfig, cloud AK/SK, database account, API token), the agent asks you to configure it as **read-only / least privilege**; when the boundary is machine-verifiable, it runs a read-only boundary check before recording it.
  </Accordion>

  <Accordion title="Minimality" icon="filter">
    Not every detail belongs in the knowledge base. The agent only writes content where "without it, the AI would make a worse decision during an incident" — optional, nice-to-have details aren't crammed in, keeping the knowledge base from bloating.
  </Accordion>
</AccordionGroup>

## What it produces

***

The result of `/init` is a [Knowledge](/en/ai-sre/knowledge) base that every subsequent session loads automatically:

* **`DUTY.md`** — the table-of-contents entry point for the knowledge base, holding only a one-line introduction and a list of `@filename` links pointing to each topic file;
* **Topic files** — `services.md`, `topology.md`, `observability.md`, `runbooks/<topic>.md`, `common-failures.md`, `clusters.md`, and so on, where all the substantive content lives;
* **MCP registrations** (optional) — if external tools were connected during the interview, they're recorded in `tools.md` and the MCP server registration is completed.

<Note>
  `/init`'s primary output is **knowledge**, not skills. It does not save content as a Skill unless you explicitly ask. It also does not automatically install Agents — those resources currently need to be added manually in the console.
</Note>

## /init and /insight: a best-practice pair

***

`/init` and [`/insight`](/en/ai-sre/insight) are the two ends of the operational-knowledge "build → refine" loop:

<CardGroup cols={2}>
  <Card title="/init — build the foundation" icon="seedling">
    Build the knowledge base from scratch: services, topology, runbooks, and cluster access are captured as a coherent whole in one pass, so the agent understands your systems from the very first session.
  </Card>

  <Card title="/insight — keep refining" icon="gauge-high">
    Review the last 30 days of sessions to surface repeatedly pasted context, missing runbooks, and wrong data sources, telling you **what to add to the knowledge base next**.
  </Card>
</CardGroup>

<Tip>
  The recommended rhythm: use `/init` to lay a solid foundation, run a few real investigations, then use `/insight` to review and fold the friction it identifies back into the knowledge base — rerunning `/init` for a systematic cleanup when needed. The more complete your knowledge base, the more accurate and useful AI SRE.
</Tip>

## Related pages

***

<CardGroup cols={2}>
  <Card title="Manage Knowledge" icon="book" href="/en/ai-sre/knowledge">
    Where `/init`'s output lands — learn the DUTY.md structure, file constraints, and how to edit and maintain it manually.
  </Card>

  <Card title="Usage Insights" icon="gauge-high" href="/en/ai-sre/insight">
    Use `/insight` to review sessions, surface operational friction, and guide ongoing backfilling of the knowledge base.
  </Card>

  <Card title="MCP (External Tools)" icon="plug" href="/en/ai-sre/mcp">
    The external tools `/init` can help you connect during the interview — learn how to connect and manage MCP.
  </Card>
</CardGroup>