@preapexis/piexis 0.1.2

package/skills/claude-api/typescript/managed-agents/README.md

@@ -0,0 +1,359 @@
+# Managed Agents - TypeScript
+
+> **Bindings not shown here:** This README covers the most common managed-agents flows for TypeScript. If you need a class, method, namespace, field, or behavior that isn't shown, WebFetch the TypeScript SDK repo **or the relevant docs page** from `shared/live-sources.md` rather than guess. Do not extrapolate from cURL shapes or another language's SDK.
+
+> **Agents are persistent - create once, reference by ID.** Store the agent ID returned by `agents.create` and pass it to every subsequent `sessions.create`; do not call `agents.create` in the request path. **Recommended:** define agents and environments as version-controlled YAML applied with the `ant` CLI - see `shared/anthropic-cli.md` (its live-docs URL is in `shared/live-sources.md`). The CLI owns the control plane (create/update); your code owns the data plane (sessions with the stored ID). The examples below show in-code creation for when you must provision programmatically; in production the create call belongs in setup, not in the request path.
+
+## Installation
+
+```bash
+npm install @anthropic-ai/sdk
+```
+
+## Client Initialization
+
+```typescript
+import Anthropic from "@anthropic-ai/sdk";
+
+// Default - resolves credentials from the environment:
+// ANTHROPIC_API_KEY, or ANTHROPIC_AUTH_TOKEN, or an `ant auth login` profile.
+// Prefer this for local dev; don't hardcode a key.
+const client = new Anthropic();
+
+// Explicit API key (only when you must inject a specific key)
+const client = new Anthropic({ apiKey: "your-api-key" });
+```
+
+---
+
+## Create an Environment
+
+```typescript
+const environment = await client.beta.environments.create(
+  {
+    name: "my-dev-env",
+    config: {
+      type: "cloud",
+      networking: { type: "unrestricted" },
+    },
+  },
+);
+console.log(environment.id); // env_...
+```
+
+---
+
+## Create an Agent (required first step)
+
+> Warning: **There is no inline agent config.** `model`/`system`/`tools` live on the agent object, not the session. Always start with `agents.create()` - the session only takes `agent: { type: "agent", id: agent.id }`.
+
+### Minimal
+
+```typescript
+// 1. Create the agent (reusable, versioned)
+const agent = await client.beta.agents.create(
+  {
+    name: "Coding Assistant",
+    model: "claude-opus-5",
+    tools: [{ type: "agent_toolset_20260401", default_config: { enabled: true } }],
+  },
+);
+
+// 2. Start a session
+const session = await client.beta.sessions.create(
+  {
+    agent: { type: "agent", id: agent.id, version: agent.version },
+    environment_id: environment.id,
+  },
+);
+console.log(session.id, session.status);
+console.log(`Trace: https://platform.claude.com/workspaces/default/sessions/${session.id}`); // swap 'default' for your workspace ID if the API key is not in the Default workspace
+```
+
+### With system prompt and custom tools
+
+```typescript
+const agent = await client.beta.agents.create(
+  {
+    name: "Code Reviewer",
+    model: "claude-opus-5",
+    system: "You are a senior code reviewer.",
+    tools: [
+      { type: "agent_toolset_20260401", default_config: { enabled: true } },
+      {
+        type: "custom",
+        name: "run_tests",
+        description: "Run the test suite",
+        input_schema: {
+          type: "object",
+          properties: {
+            test_path: { type: "string", description: "Path to test file" },
+          },
+          required: ["test_path"],
+        },
+      },
+    ],
+  },
+);
+
+const session = await client.beta.sessions.create(
+  {
+    agent: { type: "agent", id: agent.id, version: agent.version },
+    environment_id: environment.id,
+    title: "Code review session",
+    resources: [
+      {
+        type: "github_repository",
+        url: "https://github.com/owner/repo",
+        mount_path: "/workspace/repo",
+        authorization_token: process.env.GITHUB_TOKEN,
+        branch: "main",
+      },
+    ],
+  },
+);
+```
+
+---
+
+## Send a User Message
+
+```typescript
+await client.beta.sessions.events.send(
+  session.id,
+  {
+    events: [
+      {
+        type: "user.message",
+        content: [{ type: "text", text: "Review the auth module" }],
+      },
+    ],
+  },
+);
+```
+
+> Tip: **Stream-first:** Open the stream *before* (or concurrently with) sending the message. The stream only delivers events that occur after it opens - stream-after-send means early events arrive buffered in one batch. See [Steering Patterns](../../shared/managed-agents-events.md#steering-patterns).
+
+---
+
+## Stream Events (SSE)
+
+```typescript
+// Stream-first: open stream and send concurrently
+const [events] = await Promise.all([
+  collectStream(session.id),
+  client.beta.sessions.events.send(
+    session.id,
+    { events: [{ type: "user.message", content: [{ type: "text", text: "..." }] }] },
+  ),
+]);
+
+// Standalone stream iteration:
+const stream = await client.beta.sessions.events.stream(
+  session.id,
+);
+
+for await (const event of stream) {
+  switch (event.type) {
+    case "agent.message":
+      for (const block of event.content) {
+        if (block.type === "text") {
+          process.stdout.write(block.text);
+        }
+      }
+      break;
+    case "agent.custom_tool_use":
+      // Custom tool invocation - session is now idle
+      console.log(`\nCustom tool call: ${event.name}`);
+      console.log(`Input: ${JSON.stringify(event.input)}`);
+      break;
+    case "session.status_idle":
+      console.log("\n--- Agent idle ---");
+      break;
+    case "session.status_terminated":
+      console.log("\n--- Session terminated ---");
+      break;
+  }
+}
+```
+
+---
+
+## Provide Custom Tool Result
+
+```typescript
+await client.beta.sessions.events.send(
+  session.id,
+  {
+    events: [
+      {
+        type: "user.custom_tool_result",
+        custom_tool_use_id: "sevt_abc123",
+        content: [{ type: "text", text: "All 42 tests passed." }],
+      },
+    ],
+  },
+);
+```
+
+---
+
+## Poll Events
+
+```typescript
+const events = await client.beta.sessions.events.list(
+  session.id,
+);
+for (const event of events.data) {
+  console.log(`${event.type}: ${event.id}`);
+}
+```
+
+---
+
+## Full Streaming Loop with Custom Tools
+
+```typescript
+function runCustomTool(toolName: string, toolInput: unknown): string {
+  if (toolName === "run_tests") {
+    // Your tool implementation here
+    return "All tests passed.";
+  }
+  return `Unknown tool: ${toolName}`;
+}
+
+async function runSession(client: Anthropic, sessionId: string) {
+  while (true) {
+    const stream = await client.beta.sessions.events.stream(
+      sessionId,
+    );
+
+    const toolCalls: Anthropic.Beta.Sessions.BetaManagedAgentsAgentCustomToolUseEvent[] = [];
+
+    for await (const event of stream) {
+      if (event.type === "agent.message") {
+        for (const block of event.content) {
+          if (block.type === "text") {
+            process.stdout.write(block.text);
+          }
+        }
+      } else if (event.type === "agent.custom_tool_use") {
+        toolCalls.push(event);
+      } else if (event.type === "session.status_idle") {
+        break;
+      } else if (event.type === "session.status_terminated") {
+        return;
+      }
+    }
+
+    if (toolCalls.length === 0) break;
+
+    // Process custom tool calls
+    const results = toolCalls.map((call) => ({
+      type: "user.custom_tool_result" as const,
+      custom_tool_use_id: call.id,
+      content: [{ type: "text" as const, text: runCustomTool(call.name, call.input) }],
+    }));
+
+    await client.beta.sessions.events.send(
+      sessionId,
+      { events: results },
+    );
+  }
+}
+```
+
+---
+
+## Upload a File
+
+```typescript
+import fs from "fs";
+
+const file = await client.beta.files.upload({
+  file: fs.createReadStream("data.csv"),
+  purpose: "agent",
+});
+
+// Use in a session
+const session = await client.beta.sessions.create(
+  {
+    agent: { type: "agent", id: agent.id, version: agent.version },
+    environment_id: environment.id,
+    resources: [{ type: "file", file_id: file.id, mount_path: "/workspace/data.csv" }],
+  },
+);
+```
+
+---
+
+## List and Download Session Files
+
+List files the agent wrote to `/mnt/session/outputs/` during a session, then download them.
+
+```typescript
+import fs from "fs";
+
+// List files associated with a session
+const files = await client.beta.files.list({
+  scope_id: session.id,
+  betas: ["managed-agents-2026-04-01"],
+});
+for (const f of files.data) {
+  console.log(f.filename, f.size_bytes);
+
+  // Download and save to disk
+  const resp = await client.beta.files.download(f.id);
+  const buffer = Buffer.from(await resp.arrayBuffer());
+  fs.writeFileSync(f.filename, buffer);
+}
+```
+
+> Tip: There's a brief indexing lag (~1-3s) between `session.status_idle` and output files appearing in `files.list`. Retry once or twice if the list is empty.
+
+---
+
+## Session Management
+
+```typescript
+// Get session details
+const session = await client.beta.sessions.retrieve("sesn_011CZxAbc123Def456");
+console.log(session.status, session.usage);
+
+// List sessions
+const sessions = await client.beta.sessions.list();
+
+// Delete a session
+await client.beta.sessions.delete("sesn_011CZxAbc123Def456");
+
+// Archive a session
+await client.beta.sessions.archive("sesn_011CZxAbc123Def456");
+```
+
+---
+
+## MCP Server Integration
+
+```typescript
+// Agent declares MCP server (no auth here - auth goes in a vault)
+const agent = await client.beta.agents.create({
+  name: "MCP Agent",
+  model: "claude-opus-5",
+  mcp_servers: [
+    { type: "url", name: "my-tools", url: "https://my-mcp-server.example.com/sse" },
+  ],
+  tools: [
+    { type: "agent_toolset_20260401", default_config: { enabled: true } },
+    { type: "mcp_toolset", mcp_server_name: "my-tools" },
+  ],
+});
+
+// Session attaches vault(s) containing credentials for those MCP server URLs
+const session = await client.beta.sessions.create({
+  agent: agent.id,
+  environment_id: environment.id,
+  vault_ids: [vault.id],
+});
+```
+
+See `shared/managed-agents-tools.md` §Vaults for creating vaults and adding credentials.

package/skills/code-review/SKILL.md

@@ -0,0 +1,34 @@
+---
+name: code-review
+description: Review a diff, branch, pull request, or repository. Default to correctness, repository standards, and any supplied spec; use simplicity mode when asked about complexity or over-engineering; use repository-audit mode when asked to review the whole codebase. Do not use for implementation or architecture design.
+---
+
+# Code Review
+
+Review evidence, not intentions. Report actionable findings with file and line references. Do not modify code unless the user asks.
+
+## Select scope and mode
+
+- **Diff review:** use the user-supplied ref, PR diff, working tree, or merge-base. If no scope is available, ask for one.
+- **Correctness mode:** find behavior, error handling, compatibility, security, and test gaps.
+- **Standards/spec mode:** compare the diff with repository instructions and a user-supplied, linked, or discoverable spec. If no spec exists, say so; do not require an issue tracker or setup workflow.
+- **Simplicity mode:** find dead code, speculative abstraction, unnecessary dependencies, hand-rolled platform/standard-library behavior, and avoidable indirection.
+- **Repository-audit mode:** inspect the whole repository for the highest-value architecture or simplification findings. Keep correctness and security out of scope unless requested.
+
+## Process
+
+1. Establish the exact files and baseline. Read relevant repository standards, tests, and spec material.
+2. Inspect the changed behavior and its callers, not only individual lines.
+3. Separate confirmed defects from risks, judgement calls, and missing context. A repository convention overrides a generic heuristic.
+4. In simplicity mode, use one of: `delete`, `stdlib`, `native`, `yagni`, or `shrink`. Do not flag requested validation, error handling, or meaningful regression tests as bloat.
+5. Prioritize findings by impact. Omit praise, restatement, and speculative nits.
+
+## Output
+
+Use this concise format unless the user requests a narrative:
+
+```text
+path:line[-line] [severity] problem. Consequence. Concrete fix.
+```
+
+Use `bug`, `risk`, `nit`, or `question` as the severity. For a clean review, state what scope and modes were checked. Summarize findings by mode without inventing a global pass/fail verdict.

package/skills/code-review/agents/openai.yaml

@@ -0,0 +1,3 @@
+interface:
+  display_name: "Code Review"
+  short_description: "Review a diff on standards and spec"

package/skills/codebase-design/DEEPENING.md

@@ -0,0 +1,37 @@
+# Deepening
+
+How to deepen a cluster of shallow modules safely, given its dependencies. Assumes the vocabulary in [SKILL.md](SKILL.md): **module**, **interface**, **seam**, **adapter**.
+
+## Dependency categories
+
+When assessing a candidate for deepening, classify its dependencies. The category determines how the deepened module is tested across its seam.
+
+### 1. In-process
+
+Pure computation, in-memory state, no I/O. Always deepenable: merge the modules and test through the new interface directly. No adapter needed.
+
+### 2. Local-substitutable
+
+Dependencies that have local test stand-ins (PGLite for Postgres, in-memory filesystem). Deepenable if the stand-in exists. The deepened module is tested with the stand-in running in the test suite. The seam is internal; no port at the module's external interface.
+
+### 3. Remote but owned (Ports & Adapters)
+
+Your own services across a network boundary (microservices, internal APIs). Define a **port** (interface) at the seam. The deep module owns the logic; the transport is injected as an **adapter**. Tests use an in-memory adapter. Production uses an HTTP/gRPC/queue adapter.
+
+Recommendation shape: *"Define a port at the seam, implement an HTTP adapter for production and an in-memory adapter for testing, so the logic sits in one deep module even though it's deployed across a network."*
+
+### 4. True external (Mock)
+
+Third-party services (Stripe, Twilio, etc.) you don't control. The deepened module takes the external dependency as an injected port; tests provide a mock adapter.
+
+## Seam discipline
+
+- **One adapter means a hypothetical seam. Two adapters means a real one.** Don't introduce a port unless at least two adapters are justified (typically production + test). A single-adapter seam is just indirection.
+- **Internal seams vs external seams.** A deep module can have internal seams (private to its implementation, used by its own tests) as well as the external seam at its interface. Don't expose internal seams through the interface just because tests use them.
+
+## Testing strategy: replace, don't layer
+
+- Old unit tests on shallow modules become waste once tests at the deepened module's interface exist; delete them.
+- Write new tests at the deepened module's interface. The **interface is the test surface**.
+- Tests assert on observable outcomes through the interface, not internal state.
+- Tests should survive internal refactors, since they describe behaviour, not implementation. If a test has to change when the implementation changes, it's testing past the interface.

package/skills/codebase-design/DESIGN-IT-TWICE.md

@@ -0,0 +1,44 @@
+# Design It Twice
+
+When the user wants to explore alternative interfaces for a chosen deepening candidate, use this parallel sub-agent pattern. Based on "Design It Twice" (Ousterhout): your first idea is unlikely to be the best.
+
+Uses the vocabulary in [SKILL.md](SKILL.md): **module**, **interface**, **seam**, **adapter**, **leverage**.
+
+## Process
+
+### 1. Frame the problem space
+
+Before spawning sub-agents, write a user-facing explanation of the problem space for the chosen candidate:
+
+- The constraints any new interface would need to satisfy
+- The dependencies it would rely on, and which category they fall into (see [DEEPENING.md](DEEPENING.md))
+- A rough illustrative code sketch to ground the constraints, not a proposal, just a way to make the constraints concrete
+
+Show this to the user, then immediately proceed to Step 2. The user reads and thinks while the sub-agents work in parallel.
+
+### 2. Spawn sub-agents
+
+Spawn 3+ sub-agents in parallel. Each must produce a **radically different** interface for the deepened module.
+
+Prompt each sub-agent with a separate technical brief (file paths, coupling details, dependency category from [DEEPENING.md](DEEPENING.md), what sits behind the seam). The brief is independent of the user-facing problem-space explanation in Step 1. Give each agent a different design constraint:
+
+- Agent 1: "Minimize the interface: aim for 1–3 entry points max. Maximise leverage per entry point."
+- Agent 2: "Maximise flexibility: support many use cases and extension."
+- Agent 3: "Optimise for the most common caller: make the default case trivial."
+- Agent 4 (if applicable): "Design around ports & adapters for cross-seam dependencies."
+
+Include both [SKILL.md](SKILL.md) vocabulary and CONTEXT.md vocabulary in the brief so each sub-agent names things consistently with the architecture language and the project's domain language.
+
+Each sub-agent outputs:
+
+1. Interface (types, methods, params, plus invariants, ordering, error modes)
+2. Usage example showing how callers use it
+3. What the implementation hides behind the seam
+4. Dependency strategy and adapters (see [DEEPENING.md](DEEPENING.md))
+5. Trade-offs: where leverage is high, where it's thin
+
+### 3. Present and compare
+
+Present designs sequentially so the user can absorb each one, then compare them in prose. Contrast by **depth** (leverage at the interface), **locality** (where change concentrates), and **seam placement**.
+
+After comparing, give your own recommendation: which design you think is strongest and why. If elements from different designs would combine well, propose a hybrid. Be opinionated: the user wants a strong read, not a menu.

package/skills/codebase-design/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: codebase-design
+description: "Design or improve module and service architecture: interfaces, ownership, seams, dependencies, testability, domain vocabulary, and ADR-worthy decisions. Also use for an explicit architecture audit or deepening review. Do not use for implementation, generic code review, or requirement interviews."
+---
+
+# Codebase Design
+
+Design modules that give callers useful behavior through a small, understandable interface while keeping ownership and verification local.
+
+## Core ideas
+
+- A **module** may be a function, package, component, service, or vertical slice.
+- Its **interface** includes types plus invariants, errors, ordering, configuration, and performance facts callers need.
+- A **seam** is where behavior can vary without changing callers. Add one only for a real variation, typically production and test adapters.
+- **Depth** is leverage: useful behavior behind an interface simpler than the implementation it hides.
+- The interface is normally the highest-value test surface.
+
+Use this vocabulary when it clarifies a decision; do not police ordinary engineering language.
+
+## Design workflow
+
+1. Read the relevant code, tests, project terminology, and existing decisions. Separate observed constraints from assumptions.
+2. Identify ownership, callers, data flow, invariants, and the change pressure motivating the design.
+3. Prefer a small interface with clear responsibility. Apply the deletion test: if removing a module merely removes indirection, collapse it; if complexity would spread across callers, it earns its place.
+4. For external dependencies, inject an adapter only when a real boundary varies. Keep internal testing seams private when possible.
+5. Test behavior through the interface rather than internal collaboration. Replace obsolete shallow-module tests when a higher seam makes them redundant.
+6. Record domain terms only when they are project-specific and contested. Record an ADR only for a hard-to-reverse, non-obvious trade-off with real alternatives.
+
+## Architecture-audit mode
+
+When explicitly asked to audit architecture:
+
+1. Scope the review to a named subsystem or recent change hotspots.
+2. Identify a small ranked set of concrete ownership, interface, coupling, or testability problems.
+3. For each, state current friction, evidence, proposed seam or consolidation, expected leverage/locality, risks, and the smallest next experiment.
+4. Do not require an HTML report, subagents, or a refactor proposal before the user chooses a candidate.
+
+## Completion
+
+Present the recommended design, alternatives only where they are materially different, invariants, test strategy, migration/compatibility implications, and unresolved decisions.

package/skills/diagnosing-bugs/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: diagnosing-bugs
+description: Diagnose unknown bugs, regressions, intermittent failures, slow paths, unexpected results, or server errors before changing code. Also use for a known-cause small fix when the user wants a narrow patch with regression proof. Do not use for new feature implementation.
+---
+
+# Diagnose and Patch Bugs
+
+Use the lightest path that establishes enough evidence for the request. Redact secrets from commands, logs, traces, and captured artifacts.
+
+## Choose a path
+
+- **Unknown cause, intermittent failure, or performance regression:** investigate first.
+- **Known cause and small requested fix:** use the narrow-patch path.
+- **New behavior rather than incorrect behavior:** use `lean-build`.
+
+## Investigation path
+
+1. State the observed symptom separately from possible causes. Read relevant project context, ADRs, callers, tests, and failure output.
+2. Build the strongest practical feedback loop: an existing failing test, focused new test, CLI fixture, HTTP request, browser automation, trace replay, timing harness, or bisection. Prefer a fast, deterministic signal that exercises the reported symptom.
+3. If a tight repro is unavailable, gather the strongest available evidence and state the blocker. Do not present an inferred cause as confirmed.
+4. Minimize a reproducible case when doing so will materially reduce the hypothesis space.
+5. Rank plausible, falsifiable mechanisms. Test the cheapest discriminating probe first; change one variable at a time.
+6. Fix the responsible mechanism, not a symptom at one caller. Add a regression test at the highest seam that reproduces the real failure when such a seam exists.
+7. Re-run the original feedback loop, focused regression proof, and nearest affected check. Remove temporary instrumentation and report evidence, cause, fix, and remaining uncertainty.
+
+For performance work, establish a comparable baseline and measure the affected path; do not substitute log volume for a performance measurement.
+
+## Known-cause narrow-patch path
+
+1. Confirm the reported cause against the affected code and callers.
+2. Change the narrowest layer that owns the incorrect behavior. Preserve unrelated behavior, user changes, and public contracts.
+3. Avoid cleanup, renaming, abstractions, and unrelated tests.
+4. Add or update the smallest relevant regression proof when economical; otherwise state the evidence that substitutes for it.
+5. Run the focused proof plus the nearest affected gate. Stop when the requested behavior is fixed.
+
+## Completion
+
+Report the observed symptom, evidence, confirmed or suspected cause, proof run, and any unresolved limitation. Do not claim diagnosis certainty without supporting evidence.

package/skills/diagnosing-bugs/agents/openai.yaml

@@ -0,0 +1,3 @@
+interface:
+  display_name: "Diagnosing Bugs"
+  short_description: "Diagnose hard bugs and regressions"

package/skills/diagnosing-bugs/scripts/hitl-loop.template.sh

@@ -0,0 +1,44 @@
+#!/usr/bin/env bash
+# Human-in-the-loop reproduction loop.
+# Copy this file, edit the steps below, and run it.
+# The agent runs the script; the user follows prompts in their terminal.
+#
+# Usage:
+#   bash hitl-loop.template.sh
+#
+# Two helpers:
+#   step "<instruction>"          → show instruction, wait for Enter
+#   capture VAR "<question>"      → show question, read response into VAR
+#
+# At the end, captured values are printed as KEY=VALUE for the agent to parse.
+#
+# `capture` prints its value back to the terminal, where the agent reads it,
+# so capture observations, and leave signing in to the user as a `step`.
+
+set -euo pipefail
+
+step() {
+  printf '\n>>> %s\n' "$1"
+  read -r -p "    [Enter when done] " _
+}
+
+capture() {
+  local var="$1" question="$2" answer
+  printf '\n>>> %s\n' "$question"
+  read -r -p "    > " answer
+  printf -v "$var" '%s' "$answer"
+}
+
+# --- edit below ---------------------------------------------------------
+
+step "Open the app at http://localhost:3000 and sign in."
+
+capture ERRORED "Click the 'Export' button. Did it throw an error? (y/n)"
+
+capture ERROR_MSG "Paste the error message (or 'none'):"
+
+# --- edit above ---------------------------------------------------------
+
+printf '\n--- Captured ---\n'
+printf 'ERRORED=%s\n' "$ERRORED"
+printf 'ERROR_MSG=%s\n' "$ERROR_MSG"

package/skills/docx/LICENSE.txt

@@ -0,0 +1,30 @@
+© 2025 Anthropic, PBC. All rights reserved.
+
+LICENSE: Use of these materials (including all code, prompts, assets, files,
+and other components of this Skill) is governed by your agreement with
+Anthropic regarding use of Anthropic's services. If no separate agreement
+exists, use is governed by Anthropic's Consumer Terms of Service or
+Commercial Terms of Service, as applicable:
+https://www.anthropic.com/legal/consumer-terms
+https://www.anthropic.com/legal/commercial-terms
+Your applicable agreement is referred to as the "Agreement." "Services" are
+as defined in the Agreement.
+
+ADDITIONAL RESTRICTIONS: Notwithstanding anything in the Agreement to the
+contrary, users may not:
+
+- Extract these materials from the Services or retain copies of these
+  materials outside the Services
+- Reproduce or copy these materials, except for temporary copies created
+  automatically during authorized use of the Services
+- Create derivative works based on these materials
+- Distribute, sublicense, or transfer these materials to any third party
+- Make, offer to sell, sell, or import any inventions embodied in these
+  materials
+- Reverse engineer, decompile, or disassemble these materials
+
+The receipt, viewing, or possession of these materials does not convey or
+imply any license or right beyond those expressly granted above.
+
+Anthropic retains all right, title, and interest in these materials,
+including all copyrights, patents, and other intellectual property rights.