Knotr

View saved version →

---
name: use-knotr-artifacts
description: >-
  Create and manage Knotr Artifacts over MCP (list_artifact_types,
  create_or_update_artifact, collections). Use when saving Cursor canvases,
  markdown docs, or HTML/React rewrites as durable shareable outputs. Prefer
  knotr-save-artifact for an explicit save.
---

# Use Knotr artifacts (MCP)

Artifacts are durable, shareable outputs—not chat ephemera and not skills.

## After create or update

Always paste **`present_url`** from the MCP response in chat (handoff link).
Set link visibility when the user asks to share.

## Mapping

| Source | artifact_type | content_format | source_kind | Body |
|--------|---------------|----------------|-------------|------|
| Cursor `.canvas.tsx` | `page` | `tsx` | `cursor_canvas` | Paste TSX unchanged |
| Long-form markdown | `document` | `markdown` | `markdown` | Markdown source |
| Static HTML (no scripts) | `page` | `html` | `html_static` | HTML |
| Claude/Gemini interactive HTML/React | — | — | `html_interactive` | **Rewrite** to `page`+`tsx` |

## page + tsx rules

- Default-export one React component
- Import only `cursor/canvas` and `react`
- Inline data; no `fetch()` / network

## Tools

1. `list_artifact_types` if unsure of allowed formats.
2. `create_or_update_artifact` (`mcp_write`) with title, type, format, body.
3. Optional `collection_ids` or `create_or_update_artifact_collection`.
4. `list_artifacts` / `get_artifact` to reopen.

Prefer **knotr-save-artifact** when the user explicitly wants to persist.

## When not to use artifacts

- Reusable procedures → skills
- Source-of-truth notes/docs → knowledgebase

View saved version →

---
name: use-knotr-knowledge
description: >-
  Search and read Knotr knowledgebases over MCP (list_knowledgebases,
  search_knowledgebase, list_documents, get_document) and know when to write
  notes with create_or_update_document. Use when the user wants trusted docs,
  notes, or semantic search from their profile KB.
---

# Use Knotr knowledgebases (MCP)

## Discover

1. `list_knowledgebases` (optional `query`) or `knotr-ai://manifests/knowledgebases`.
2. Prefer **active** KBs for search and document tools.

## Read / search

1. `search_knowledgebase` with a natural-language `query` (and KB scope when
   the tool requires it).
2. Or `list_documents` on an active KB, then `get_document`:
   - `return_type: metadata` (default) — same fields as a list row
   - `contents` — text_note body / extracted file text
   - `file` — signed download URL for file documents
3. Use `knotr-ai://manifests/document-mime-types` before creating files/notes
   with unfamiliar MIME types.

## Write

Use `create_or_update_document` (`mcp_write`) when the user wants durable notes
or uploads in a KB—not for reusable task procedures (skills) or shareable
finished canvases (artifacts).

1. Confirm target `knowledgebase_id` (active).
2. Omit `document_id` to create (`name`, `content_type` required).
3. For `text_note`, store markdown/plain content verbatim.
4. On update, `tags: []` leaves tags unchanged; include `""` in `tags` to
   clear entries.

## When not to use KB

- Reusable how-to → `use-knotr-skills` / `create_or_update_skill`
- Shareable canvas / page / long deliverable link → `use-knotr-artifacts`

View saved version →

---
name: use-knotr-skills
description: >-
  Discover and run Knotr profile skills over MCP (list_skills, get_skill), and
  know when to write them back with create_or_update_skill. Use when the user
  wants profile skills, commands, or subagents without syncing a full IDE skill
  bundle. Prefer knotr-save-skill when the user explicitly wants to persist.
---

# Use Knotr skills (MCP)

Profile skills live on knotr.ai. Discover and fetch them over the connected
profile MCP server—do **not** call `get_ide_plugin_install` for skill bodies.

## Read path

1. Call `list_skills` (optional `query`) or read `knotr-ai://manifests/skills`
   (active only).
2. Pick by name, description, and `intended_use` (`skill` | `command` |
   `subagent`).
3. Call `get_skill` with `skill_id`, or `resources/read` on `resource_uri`
   (`knotr-ai://skills|commands|agents/<uuid>`).
4. Follow the returned markdown. Use `referenced_documents` from `get_skill`
   when present.
5. Content is live—no `knotr-sync` / reload required to pick up remote edits.

## Write path

Prefer the **knotr-save-skill** command when the user should explicitly persist.
Otherwise use `create_or_update_skill` (`mcp_write`) when:

**Write when**

- User asks to save, create, update, or publish a skill on Knotr.
- A reusable workflow should travel across tools/machines with this profile.
- Refining an existing Knotr skill (`skill_id` from list/get).
- Persona/team procedures belong on the profile (not only in a repo’s
  `.cursor/skills/`).

**Do not write when**

- One-off chat instructions.
- Facts/docs → knowledgebase / `create_or_update_document`; finished shareable
  outputs → Artifact.
- Secrets, tokens, or machine-only absolute paths.
- A matching skill already exists and the user only wanted to run it.
- Soft-off (`inactive`) or overwrite of an active skill without confirmation.
- Inventing skills nobody asked to persist.

**Checklist**

1. `list_skills` — avoid duplicates; prefer update with `skill_id`.
2. Confirm with the user if create vs update is unclear.
3. Set `intended_use`; prefer `status: draft` on create unless they want
   `active`.
4. Store clean markdown; attach `reference_document_ids` only for owned docs.
5. Report UUID—live on MCP immediately (no full skill sync).

## Repo-local vs Knotr

- Project `.cursor/skills/` — git, this codebase only.
- Knotr profile skill — durable across MCP clients. Default for “save as a
  skill” in a connected session: Knotr via `create_or_update_skill`.

View saved version →

---
name: use-knotr-style
description: >-
  Lint user-facing prose against the profile’s Knotr style guides via MCP
  check_style (Vale). Use before shipping copy, emails, docs, or marketing text
  so outputs match the user’s voice. Prefer knotr-check-style for an explicit
  lint pass.
---

# Use Knotr style checking (MCP)

`check_style` is only available when the profile has at least one **active**
style guide. Prefer this path over guessing tone from memory.

## Check loop

1. `list_style_guides` — confirm an active guide exists (`status: active`).
   If none, tell the user to activate or create a guide in knotr.ai (or use
   `create_or_update_style_guide` with `mcp_write` if they ask).
2. Optionally `get_style_guide` for editorial guidelines / source context.
3. Call `check_style` with the draft `content` (optional `format`, default
   `md`; optional `style_guide_id`).
4. Fix reported issues (line, match, message, rule, suggested fix).
5. Re-run `check_style` until clean or the user accepts remaining issues.

## When to run

- Before finalizing user-facing prose the profile should “sound like”
- After substantial rewrites of emails, docs, landing copy, or skill text
- When the user asks to match brand / style / voice

## Authoring guides (light)

Creating or regenerating Vale rules is secondary. Use
`create_or_update_style_guide` when the user wants a new guide or to change
`source_text` / regenerate. Deep Vale on-disk sync remains an optional profile
IDE zip concern—not required for MCP `check_style`.