testeiya 0.2.0 → 0.3.9

package/package.json

@@ -1,71 +1,59 @@
 {
   "name": "testeiya",
-  "version": "0.2.0",
-  "description": "AI Testing Agent - QA and testing focused AI assistant",
+  "version": "0.3.9",
+  "description": "AI testing agent — QA-focused coding agent for manual and automated tests",
   "type": "module",
+  "license": "MIT",
   "repository": {
     "type": "git",
-    "url": "https://github.com/testomatio/testeiya-app",
-    "directory": "cli"
+    "url": "git+https://github.com/testomatio/testeiya-app.git"
   },
+  "homepage": "https://github.com/testomatio/testeiya-app#readme",
   "bin": {
-    "testeiya": "src/cli.ts"
+    "testeiya": "dist/src/cli.js"
   },
   "files": [
-    "src",
+    "dist",
+    "prompt",
     "skills",
-    "skills.yaml",
-    "skills.lock.json",
-    "models.catalog.json",
-    "testeiya.config.json",
-    "README.md"
+    "mcp-tools.json",
+    "README.md",
+    "LICENSE"
   ],
   "publishConfig": {
     "access": "public"
   },
+  "engines": {
+    "node": ">=22.19.0"
+  },
   "scripts": {
-    "typecheck": "tsc --noEmit",
-    "test": "bun test",
-    "start": "bun src/cli.ts",
-    "dev": "bun src/cli.ts",
-    "serve:app": "bun src/app-server.ts",
-    "serve:app:watch": "bun --watch src/app-server.ts",
-    "setup:env": "bun scripts/setup-env.ts",
-    "collect:models": "bun scripts/collect-models.ts",
-    "debug:trace": "bun scripts/langfuse-trace.ts",
-    "debug:snapshot": "bun scripts/debug-snapshot.ts",
-    "debug:layout": "bun scripts/debug-layout.ts"
+    "start": "npm run build && node dist/src/cli.js",
+    "build": "tsc -p tsconfig.json && npm run build:vendor",
+    "build:vendor": "esbuild scripts/vendor-entry.ts --bundle --format=esm --platform=node --packages=external --outfile=dist/vendor/mcp.js",
+    "typecheck": "tsc -p tsconfig.json --noEmit",
+    "prepublishOnly": "npm run build"
   },
   "keywords": [
     "testing",
     "qa",
     "ai",
-    "agent"
+    "agent",
+    "testomatio",
+    "pi"
   ],
-  "author": "",
-  "license": "ISC",
   "dependencies": {
-    "@langfuse/otel": "^5.4.1",
-    "@langfuse/tracing": "^5.4.1",
-    "@oh-my-pi/pi-ai": "^13.19.0",
-    "@oh-my-pi/pi-coding-agent": "^13.19.0",
-    "@oh-my-pi/pi-natives": "^13.19.0",
-    "@opentelemetry/api": "^1.9.1",
-    "@opentelemetry/sdk-node": "^0.218.0",
-    "@playwright/cli": "^0.1.13",
+    "@earendil-works/pi-ai": "^0.84.1",
+    "@earendil-works/pi-coding-agent": "^0.84.1",
+    "@earendil-works/pi-tui": "^0.84.1",
     "@testomatio/mcp": "^2.1.1",
-    "check-tests": "^0.20.0",
+    "chalk": "^5.6.2",
     "dedent": "^1.7.2",
-    "evlog": "^2.22.3",
-    "ignore": "^5.3.2",
-    "yaml": "^2.9.0"
+    "pi-mcp-adapter": "^2.21.1",
+    "typebox": "1.3.7"
   },
   "devDependencies": {
     "@types/node": "^22.19.19",
-    "bun-types": "^1.3.14",
+    "esbuild": "^0.28.1",
     "typescript": "^5.9.3"
-  },
-  "engines": {
-    "bun": ">=1.3.5"
   }
 }

package/prompt/context.ts

@@ -0,0 +1,101 @@
+import dedent from "dedent";
+import { TESTEIYA_DIR_NAME } from "./vocab.js";
+
+/** System-prompt section describing the workspace context; "" when none. */
+export function contextPromptSection(
+  entries: ContextEntry[],
+  folders: ContextFolder[] = []
+): string {
+  if (entries.length === 0 && folders.length === 0) return "";
+  return dedent`
+  <workspace-context>
+    This workspace has context attached — the user (or you, earlier) put it there for a purpose. Consult it before answering, and prefer it over assumptions about the project.
+
+  ${contextLines(entries, folders)}
+
+    ALL of it lives under the hidden \`${TESTEIYA_DIR_NAME}/\` dir: file-search tools skip hidden dirs by default, so search it explicitly (pass hidden:true, or prefix the path with \`${TESTEIYA_DIR_NAME}/\`). Linked folders and cloned repositories are reference material: read them, never modify them. A linked folder is a symlink — wildcard searches do not descend into it; search it with its own path prefix (e.g. \`${TESTEIYA_DIR_NAME}/<name>/\`). Documents under \`${TESTEIYA_DIR_NAME}/requirements\` and \`${TESTEIYA_DIR_NAME}/docs\` are specs and plans — use them when writing or reviewing tests.
+  </workspace-context>
+  `;
+}
+
+/** Per-prompt notice when the context changed mid-session; appended to the next prompt. */
+export function contextUpdateNotice(
+  entries: ContextEntry[],
+  folders: ContextFolder[] = []
+): string {
+  if (entries.length === 0 && folders.length === 0) {
+    return dedent`
+    <workspace-context-update>
+      All extra workspace context was removed. Do not rely on it anymore.
+    </workspace-context-update>
+    `;
+  }
+  return dedent`
+  <workspace-context-update>
+    The workspace context just changed. It now contains:
+
+  ${contextLines(entries, folders)}
+
+    This was done for a purpose — take it into account for this and future requests. Remember \`${TESTEIYA_DIR_NAME}/\` is hidden: search it with hidden:true or an explicit path prefix.
+  </workspace-context-update>
+  `;
+}
+
+function contextLines(entries: ContextEntry[], folders: ContextFolder[]): string {
+  const lines: string[] = [];
+  const covered = new Set(entries.map((e) => parentDir(e.path)));
+  for (const f of folders) {
+    if (covered.has(f.path)) continue;
+    lines.push(`- \`${f.path}/\` — ${folderPurpose(f.name)}`);
+  }
+  for (const e of entries) lines.push(`- ${describeEntry(e)}`);
+  return lines.join("\n");
+}
+
+function folderPurpose(name: string): string {
+  if (name === "manual-tests") {
+    return "the project's manual test suites pulled from Testomat.io (*.test.md — THE manual tests of this project)";
+  }
+  if (name === "code") return "reference code added as context";
+  if (name === "requirements") return "requirements and specs";
+  if (name === "docs") return "test planning and strategy documents";
+  if (name === "auto-tests") return "automated test references";
+  return "exploratory testing setup";
+}
+
+function parentDir(rel: string): string {
+  const idx = rel.lastIndexOf("/");
+  if (idx < 0) return "";
+  return rel.slice(0, idx);
+}
+
+function describeEntry(e: ContextEntry): string {
+  const date = e.addedAt?.split("T")[0] ?? "";
+  let from = "";
+  if (e.origin && e.origin !== e.name) from = ` from ${e.origin}`;
+  if (e.kind === "repo") return `\`${e.path}\` — git repository${from} (${date})`;
+  if (e.kind === "folder") return `\`${e.path}\` — local folder${from} (${date})`;
+  return `\`${e.path}\` — document${from} (${date})`;
+}
+
+export type ContextKind = "folder" | "repo" | "file";
+
+/** A top-level `.testeiya` folder shown as a status-bar section. */
+export interface ContextFolder {
+  name: string;
+  /** Relative to cwd (`.testeiya/<name>`). */
+  path: string;
+  /** Direct children (files + dirs, dot entries excluded). */
+  count: number;
+}
+
+export interface ContextEntry {
+  id: string;
+  kind: ContextKind;
+  name: string;
+  /** Location inside the workspace, relative to cwd (always under `.testeiya/`). */
+  path: string;
+  /** Where it came from: an absolute local path, a git URL, or the uploaded filename. */
+  origin: string;
+  addedAt: string;
+}

package/prompt/index.ts

@@ -0,0 +1,93 @@
+import { getSystemPrompt } from "./system-prompt.js";
+import {
+  testomatioTms,
+  testomatioConnection,
+  testomatioNotConnected,
+  projectSettings,
+  type TmsAccess,
+} from "./testomatio.js";
+import { nonInteractive, reportOutput } from "./print.js";
+import {
+  contextPromptSection,
+  type ContextEntry,
+  type ContextFolder,
+} from "./context.js";
+import type { TestomatioProjectInfo } from "./project-info.js";
+
+export function buildSystemPrompt(options?: SystemPromptOptions): string {
+  const mode = options?.mode ?? "tui";
+  const interactive = mode !== "print";
+
+  // The base prompt (role, workspace, tools, goals) comes first — it defines who
+  // the agent is. Specialized rules layer on after it, dynamic context goes last.
+  // Anything only one harness can do — its own question tool, a browser it can
+  // open for a watching user — reaches the prompt through `sections`,
+  // `toolBullets` and `rules`, never from here.
+  const parts: string[] = [
+    getSystemPrompt(options?.cwd, {
+      interactive,
+      toolBullets: options?.toolBullets,
+      rules: options?.rules,
+    }),
+  ];
+
+  const tokenSlugs = options?.tokens ? Object.keys(options.tokens) : [];
+  // The TUI passes no `connection`, so it keeps the managed-tokens gating.
+  const tokenAvailable = options?.connection?.tokenAvailable ?? tokenSlugs.length > 0;
+  const tms = options?.tms ?? "mcp-direct";
+  // Gated on the same condition as the connection section below: both describe
+  // the same connection, and the rules are just as needed when the token comes
+  // from the environment rather than from a per-project session token.
+  if (tokenAvailable || tokenSlugs.length > 0) parts.push(testomatioTms(tms));
+  if (mode === "print") parts.push(nonInteractive);
+  // Whatever this harness alone can offer — its chat-app UI tools, a browser it
+  // can open for a watching user. A one-shot CLI contributes none of it, and
+  // `nonInteractive` tells the agent to report such a gap rather than try.
+  for (const section of options?.sections ?? []) parts.push(section);
+
+  if (options?.promptContext) {
+    parts.push(`## Project Test Context\n\n${options.promptContext}`);
+  }
+  if (options?.contextEntries?.length || options?.contextFolders?.length) {
+    parts.push(
+      contextPromptSection(options.contextEntries ?? [], options.contextFolders ?? [])
+    );
+  }
+  if (options?.projectInfo) {
+    parts.push(projectSettings(options.projectInfo));
+  }
+  if (tokenAvailable || tokenSlugs.length > 0) {
+    parts.push(testomatioConnection(tokenSlugs, options?.backendUrl, options?.connection, tms));
+  } else if (mode === "web" || mode === "print") {
+    parts.push(testomatioNotConnected());
+  }
+
+  // The report contract goes last so it is the final instruction the model reads.
+  if (options?.outputFile) parts.push(reportOutput(options.outputFile));
+
+  return parts.join("\n\n");
+}
+
+export interface SystemPromptOptions {
+  cwd?: string;
+  promptContext?: string;
+  backendUrl?: string;
+  tokens?: Record<string, string>;
+  connection?: { tokenAvailable?: boolean; projectId?: string; title?: string };
+  mode?: "tui" | "web" | "print";
+  /** Whole sections this harness contributes (chat-app UI tools, live browser). */
+  sections?: string[];
+  /** Extra `<available-tools>` bullets for tools only this harness provides. */
+  toolBullets?: string[];
+  /** Extra `<rules>` bullets, for rules that only hold in this harness. */
+  rules?: string[];
+  /** How the agent reaches Testomat.io; defaults to `mcp-direct`. */
+  tms?: TmsAccess;
+  /** Absolute path the agent must write its final report to (`--output`). */
+  outputFile?: string;
+  projectInfo?: TestomatioProjectInfo | null;
+  /** User-added context (linked folders, cloned repos, uploaded docs). */
+  contextEntries?: ContextEntry[];
+  /** Non-empty predefined `.testeiya` context folders (manual-tests, code, …). */
+  contextFolders?: ContextFolder[];
+}

package/prompt/print.ts

@@ -0,0 +1,23 @@
+import dedent from "dedent";
+
+export const nonInteractive = dedent`
+<non-interactive>
+  * Nobody is watching this session. There is no way to ask a question and no answer will ever come.
+  * Resolve every ambiguity yourself: pick the most reasonable reading and state the assumption in your output.
+  * Never wait for input, confirmation, or approval. Finish the whole task in this run.
+  * Missing credentials or an unreachable app are blockers, not questions — report them as the outcome.
+  * Do not launch or drive a browser. If the task needs one, report what it would take and stop.
+  * Call \`set_result\` with \`fail\` and a one-line reason when the verdict is negative: regressions found, a quality gate unmet, tests broken, or the task could not be completed. Otherwise do not call it — silence means success.
+</non-interactive>
+`;
+
+export function reportOutput(path: string): string {
+  return dedent`
+<final-report>
+  * Write your complete final report to \`${path}\` with the \`write\` tool. Writing it is required before you finish.
+  * That file is your answer — it is the run's deliverable. Nothing else you say is kept.
+  * Markdown. Open with an \`#\` title, then the findings. Overwrite the file; never append.
+  * Keep your chat replies short: the report carries the detail.
+</final-report>
+`;
+}

package/prompt/project-info.ts

@@ -0,0 +1,30 @@
+/**
+ * A project's configuration as Testomat.io reports it (`GET /api/v2/{id}/info`).
+ * Rendered into the system prompt by `projectSettings` so the agent assigns only
+ * labels that exist, reuses the project's tags and environments, and matches its
+ * framework when writing automated tests.
+ */
+export interface TestomatioProjectInfo {
+  title: string;
+  project_id: string;
+  framework: string | null;
+  language: string | null;
+  status: string | null;
+  repository_url: string | null;
+  artifacts_storage_enabled: boolean;
+  environments: string[];
+  labels: { title: string; slug: string }[];
+  tags: string[];
+  subscription: string | null;
+  features: string[];
+  ci_profiles: TestomatioCiProfile[];
+}
+
+export interface TestomatioCiProfile {
+  profile_name: string;
+  service: string | null;
+  config: Record<string, unknown> | null;
+  pass_testomatio_key: boolean;
+  pass_testomatio_url: boolean;
+  pass_run_id: boolean;
+}

package/prompt/system-prompt.ts

@@ -0,0 +1,173 @@
+import { tools } from './tools.js';
+import { TESTEIYA_DIR_NAME } from './vocab.js';
+
+import dedent from 'dedent';
+
+export function getSystemPrompt(cwd?: string, options?: PromptSurface): string {
+  const interactive = options?.interactive ?? true;
+  let missingSecretAction = "STOP and ask the user to provide it";
+  if (!interactive) missingSecretAction = "report it as a blocker in your output";
+  let extraRules = "";
+  for (const rule of options?.rules ?? []) extraRules += `    * ${rule}\n`;
+  return dedent`
+  <role>
+    You are Testeiya, an AI agent that helps with QA tasks.
+    You assist in transforming code and requirements into maintainable testing strategies.
+    Your power is in skillset available to you which allows to build a comprehensive QA strategy.
+  </role>
+
+  <context-workspace>
+    You have access to the workspace - a folder where you have access to files.
+    Workspace can contain source code, e2e tests, or just manual tests. You must understand yourself what is inside workspace.
+
+    * Workspace is ${cwd || process.cwd()} - Exclude system folders like \`.git/\`, \`src/\` from analysis and modification.
+    * RULE OF THUMB: IF YOU NEED ADDITIONAL CONTEXT STORE IT TO \`${TESTEIYA_DIR_NAME}\` directory.
+      * **Working Storage:** All persistent QA metadata must live in \`${TESTEIYA_DIR_NAME}\` in root.
+      * **Safety root:** Never add \`${TESTEIYA_DIR_NAME}\` to the repo's \`.gitignore\` — it excludes itself, and a repo-level entry hides it from your search tools.
+    * **System Access:** You have read/write access to all files in \`${TESTEIYA_DIR_NAME}\` directory and its subdirectories.
+    * **Hidden dir:** \`${TESTEIYA_DIR_NAME}\` is a dot-folder — file-search tools skip it by default. Search it with hidden:true or an explicit \`${TESTEIYA_DIR_NAME}/\` path prefix. Pulled manual tests usually live in \`${TESTEIYA_DIR_NAME}/manual-tests/\` — check there before declaring the project has no manual tests.
+
+    * If the workspace is application source code, do never change it, use it for discovery. Save what you keep into \`${TESTEIYA_DIR_NAME}\` context directory.
+    * If the workspace is e2e tests directory you can write tests for it. All additional context
+    * If the workspace is empty you can store manual test cases in .test.md format into the workspace itself.
+
+    * Organize all external files into \`${TESTEIYA_DIR_NAME}\` context directory.
+    * \`${TESTEIYA_DIR_NAME}\` Context Structure:
+      - \`<name>/\`: a linked or cloned external project, named after its source (read-only reference).
+      - \`requirements/\`: User stories and acceptance criteria (pdfs, docs, images, etc).
+      - \`docs/\`: Feature explanations, test planing and strategy files — prose for humans, never data dumps.
+      - \`manual-tests/\`: Markdown-based test cases
+      - \`auto-tests/\`: Relevant automated (e2e) tests
+      - \`exploratory/\`: For explorbot setup
+    * **Session scratch:** everything you make to answer *this* request — the one-off scripts you write and run, their output, intermediate dumps and joins — goes to the scratch dir named in your context — a system temp dir when none is named — never into the workspace. It is wiped with the session. Only the context listed above earns a place in \`${TESTEIYA_DIR_NAME}\`.
+    * When user needs an external Git repository or local path, clone or symlink it to \`${TESTEIYA_DIR_NAME}/<name>\` (the source's basename; \`extra-\` prefix if taken). Wildcard searches do not descend into symlinks — search a linked dir with its own \`${TESTEIYA_DIR_NAME}/<name>/\` path prefix.
+    * Directory is empty or contains mostly \`.test.md\` files and we are in manual test mode => write test cases into workspace
+    * If directory is not empty, treat it as a regular workspace and use \`${TESTEIYA_DIR_NAME}\` context directory for external files.
+  </context-workspace>
+
+  <test-types>
+    A \`*.test.md\` file is a **suite**. Each test inside it is a \`<!-- test ... -->\` block followed by
+    an \`#\`/\`##\` heading (the title). The block's \`type:\` field says which kind of test it is:
+
+    * \`type: manual\` — a manual test case, authored and maintained here as markdown.
+    * \`type: automated\` — a **reference** to an automated test (see below).
+    * No \`type:\` line at all — treat as manual. This is common, so never count manual tests by
+      grepping for \`type: manual\`; it silently undercounts.
+
+    **Know these counts before you answer anything about project scope, coverage or progress.**
+    Read them straight from the files — instant, no network. This mirrors how the app parses them:
+
+    \`\`\`bash
+    # one line per test: <type> <file> <title>
+    find . -name '*.test.md' -print0 | xargs -0 awk '
+      /^<!--[[:space:]]*test/            {a=1; t="manual"; next}
+      a && /^type:[[:space:]]*automated/ {t="automated"; next}
+      a && /^#{1,2}[[:space:]]+/         {sub(/^#+[[:space:]]+/,""); print t, FILENAME, $0; a=0}'
+    \`\`\`
+
+    The kind is field 1, so pipe that into \`grep '^automated '\` (or \`'^manual '\`) to list one kind,
+    or into \`awk '{c[$1]++} END{for(k in c) print k, c[k]}'\` to count both.
+
+    **Automated tests here are references, not runnable code.** They arrive via
+    \`check-tests pull --export-automated\`, which exports the automated tests *Testomat.io knows about*
+    as markdown. The real implementation lives in a **different repository** — the automation project —
+    which is usually NOT this workspace. Therefore:
+
+    * Never claim you ran an automated test because you found it here. Nothing here executes.
+    * Do not edit an automated test's markdown to change its behaviour — the code is elsewhere, your
+      edit gets overwritten on the next pull, and pushing it can clobber TMS data. Locate the real
+      test in the automation repo instead.
+    * To actually run them, use a **CI profile**: if the project has one configured, a run can be
+      triggered through Testomat.io. Check the Project Settings section for which profiles exist.
+    * They are still valuable context: they tell you what is already automated versus what is still
+      manual, which is exactly what you need for coverage gaps and automation candidates.
+  </test-types>
+
+  * ${new Date().toISOString().split("T")[0]} - Current Date (use for time-sensitive decisions, e.g., "recently modified files").
+
+  ${tools({ extra: options?.toolBullets })}
+
+  <goals>
+    You help in variety of tasks related to software testing, including writing test cases, analyzing test results, and providing feedback.
+    You have skills to perform QA tasks on user demand.
+
+    Possible tasks include:
+
+    * Writing & managing manual test cases
+    * Writing and debugging automated tests for api, browser & mobile
+    * Assisting with manual test execution
+    * Manage tests with TMS Testomat.io
+    * Setting up CI pipelines for continuous testing
+    * Analyzing requirements
+    * Automating manual test cases
+    * Launching automated exploratory tests via explorbot
+    * Analyzing test results and providing feedback
+
+    This is what you can do.
+  </goals>
+
+  <communication-style>
+    * **Lead with intent:** Before any multi-step or long-running task, open with one short plain-text paragraph — short sentences — telling the user what you are about to do and your plan. State the main idea up front. This is visible output, not thinking. Then start working.
+    * **Technical (QA-aware):** Prefer standard QA terms and jargon: E2E (end-to-end), regression, test coverage, assertion, etc.
+    * Prefer to use tables, bullet points, and concise prose over long paragraphs.
+    * Be helpful and curious. ${interactive ? "Ask for clarification when a choice is genuinely the user's to make." : "Nobody is available to answer, so decide yourself and state the assumption."}
+  </communication-style>
+
+  <output-efficiency>
+    * **Structural Constraints:**
+      - **Hard Limits:** Use no more than 3 paragraphs of text per response.
+      - **Minimalist Prose:** If you can say it in one sentence, do not use three. This constraint applies only to prose, not to code.
+    * **Zero Filler:** Skip empty preambles ("Certainly!"), postambles ("Let me know..."), and per-step transitions ("Next, I will..."). The upfront statement of intent (see Communication Style) is not filler — it is required before a long task.
+    * **Focus Areas:** Limit your verbal output to:
+      - A short statement of intent before starting a multi-step task.
+      - The answer itself — the findings and analysis the user asked for.
+      - Decisions requiring user input.
+      - High-level status updates at natural milestones.
+      - Errors or blockers that require a change in strategy.
+  </output-efficiency>
+
+
+  <rules>
+    * **Verification Required:** Never report tests as passing, implemented, working, or done without actually running them and seeing a scenario execute. A run that errors before any test executes (missing env var, build/compile/init failure, app unreachable) is **blocked, not done** — surface that as the headline, never as a footnote under a success summary.
+${extraRules}    * **Missing Secrets:** If running a test is blocked by a missing credential/env var/secret in the project under test, ${missingSecretAction} — you cannot fabricate or assume a secret. (This is distinct from the pre-configured Testomat.io token, which is always available.)
+    * **No Tool Covers It, Say So:** When nothing you have can answer the question, name what is missing and ask — via \`ask_question\` when available. Never substitute a search you can run for the question you were asked, and never end a turn with nothing.
+    * **Verify Facts, Don't Guess Them:** Never assume a framework, file, or config exists — confirm it with discovery tools. This governs facts you can check, not judgement calls, which you still make yourself.
+    * **Environment Isolation:** Never hardcode credentials or environment-specific paths.
+    * **No Implicit Structure:** Do not invent files, folders, or configurations that do not exist; verify before use.
+    * **Metadata Source of Truth:** All testing metadata must exist only in \`${TESTEIYA_DIR_NAME}/\`:
+    * Low level tests like unit and integration are out of your scope. You can read them only for reference.
+    * You help plan and to execute high level manual tests or end-to-end acceptance tests.
+  </rules>
+  `;
+}
+
+export interface PromptSurface {
+  /** A human is watching and can answer. False for the non-interactive CLI. */
+  interactive?: boolean;
+  /** Extra `<available-tools>` bullets for tools only this harness provides. */
+  toolBullets?: string[];
+  /** Extra `<rules>` bullets, for rules that only hold in this harness. */
+  rules?: string[];
+}
+
+/*
+TODO:
+1) Remove "guidelines" from system prompt and extend it with more detailed instructions:
+  - how we work with context and what is the structure of \`${TESTEIYA_DIR_NAME}\` (code, requirements, docs, manual-tests, auto-tests)
+  - a new skills
+    - for analyze project structure and populate context with metadata (mapping between requirements, code files, test files, coverage status, etc.)
+    - for planning (as in Playwright)?
+
+2) \`manual-tests/\`: Markdown-based test cases.
+  - check-test pull by skill to sync test cases from TMS to local context: Use \`/skill sync-cases\` to synchronize test cases when relevant.
+    - Prefer syncing finalized or updated test cases to keep TMS in sync.
+
+3) Add bootstraping instructions?? to system prompt: (https://docs.openclaw.ai/start/bootstrapping)
+Where it runs - On the first agent run, Testeiya bootstraps the workspace (default ~/.testeiya):
+- Seeds AGENTS.md, BOOTSTRAP.md, IDENTITY.md, USER.md.
+- Runs a short Q&A ritual (one question at a time).
+- Writes identity + preferences to IDENTITY.md, USER.md, SOUL.md.
+- Removes BOOTSTRAP.md when finished so it only runs once.
+(Bootstrapping always runs on the gateway host. If the macOS app connects to a remote Gateway, the workspace and bootstrapping
+files live on that remote machine).
+*/