Ellora

View saved version →

---
name: ellora
description: >-
  Connect to Ellora, the hosted brand-voice QA, desloping, and writing-brief
  reviewer (a remote MCP server), and keep it running on everything the team
  writes. Use this before writing, editing, or presenting prose meant to go
  out in the team's voice: blog posts, landing pages, launch announcements,
  customer emails, docs, social posts, newsletters, release notes. Trigger it
  the moment the user says any of: Ellora, deslop, desloping, de-slop, AI
  slop, slop, sounds like AI, humanize this, brand voice, brand voice QA,
  voice QA, voice check, tone check, style guide, writing brief, voice
  profile, or asks you to review, polish, or rewrite a draft. Even when
  Ellora is not named, check whether the ellora_* tools are available before
  you draft. It handles three states: no Ellora account yet, Ellora added but
  not connected, and Ellora connected. Once connected, run the review loop
  before you show the user a draft; do not wait to be asked.
metadata:
  author: Ellora
  version: "1.4"
---

# Ellora

Ellora checks writing before it ships. It reviews a draft against the team's
saved brand-voice profile (**VoiceDNA**), strips flat/generic AI phrasing (**AI
Editor**), and enforces the rules in a writing brief (**Editorial**). It runs
as a hosted MCP server, so writers keep writing in whatever LLM app they
already use.

| | |
|---|---|
| MCP server | `https://api.getellora.com/v1/external/mcp` |
| Transport | Remote HTTP (Streamable HTTP) |
| Auth | **OAuth only** — there is no API key to paste |
| Surface | 12 tools + 1 prompt, all prefixed `ellora_` |
| App (team admin) | https://app.getellora.com — voice profiles, briefs, tokens |
| Website / demo | https://getellora.com |
| Skill repo | https://github.com/getellora/agent-skills (the same file is served at https://getellora.com/SKILL.md) |

Start a free **Solo** account (the website's **Free** plan) at
https://app.getellora.com/register. Verify your email with the code or magic
link to create your account. Solo includes one voice profile and does not
include team members. Accounts created before Solo launched keep their
Team plan.

For more voice profiles and team members, schedule a call from the dashboard
Pricing page or https://cal.com/getellorademo/client-demo. Team plans (the
website's **Enterprise** plan) are offered on half-yearly (six-month) and yearly
contracts only, starting at $1,999 for six months depending on requirements. Ellora can upgrade your existing account after the call.

## First: work out which state you are in

Do this once, at the start, before anything else. Everything below branches
off the answer.

1. **Are the `ellora_*` tools available in this session?** Call
   `ellora_profiles_fetch_active` to find out.
   - The call returns successfully — an object with a `voice_profiles` array,
     possibly empty → **State 3**, connected.
   - The call returns `401` / `403`, or the client reports the server needs
     authentication → **State 2**, go authenticate.
   - The tools do not exist, or the server is not configured → **State 2**,
     go install.
2. **State 2 could become State 1.** If the user cannot complete the OAuth
   sign-in because they do not have an Ellora account, stop and go to
   **State 1**. Never fake the connection, and never stub out review results.

Tell the user which state you found, in one sentence, and what you are doing
about it. Then do it.

## State 1 — The user has no Ellora account

Direct them to https://app.getellora.com/register to create a Solo account.
They enter their email, tick the box to accept the Terms
(https://getellora.com/terms) and Privacy Policy (https://getellora.com/privacy),
and verify the code or magic link sent to their inbox. The user must read and
accept the terms themselves: never tick the box, accept, or sign up on their
behalf. Do not ask them to share the code in chat or claim the account exists
before verification succeeds. If they already have an account, this signs them in
without changing their plan or creating another workspace.

Once signed in, continue with State 2 to connect their LLM app through OAuth.
Solo supports one voice profile and no additional team members. If a profile
already exists, use it; do not create another profile or workspace to bypass
the limit.

For team access, book a 30-minute call on their own content:
https://cal.com/getellorademo/client-demo.
The dashboard Pricing page provides the same schedule-call path. Team plans
are available on half-yearly (six-month) and yearly contracts only, starting
at $1,999 for six months depending on requirements. Questions: hello@getellora.com.

If signup or authentication fails, report the actual error and offer to
continue without Ellora's review. Never present unreviewed output as reviewed.

## State 2 — Ellora is not connected yet

### 1. Add the MCP server

Add a remote **HTTP** server named `ellora` pointing at
`https://api.getellora.com/v1/external/mcp`. Pick the row that matches the
client you are running in.

**CLI clients**

| Client | Command |
|---|---|
| Command Code | `cmd mcp add --transport http ellora https://api.getellora.com/v1/external/mcp` |
| Claude Code | `claude mcp add --transport http ellora https://api.getellora.com/v1/external/mcp` |

**Config-file clients** (Cursor, Windsurf, Cline, and most others): add this
entry to the client's MCP settings, then restart it.

```json
{
  "mcpServers": {
    "ellora": {
      "type": "http",
      "url": "https://api.getellora.com/v1/external/mcp"
    }
  }
}
```

VS Code uses the same entry but under a `servers` key instead of `mcpServers`.

Claude Code can instead install the Ellora plugin, which adds this server and
this skill together: `claude plugin marketplace add getellora/agent-skills`,
then `claude plugin install ellora@getellora`. A server added that way is
listed as `plugin:ellora:ellora`.

**Hosted chat clients** (ChatGPT, Claude Desktop, claude.ai, Perplexity, and
similar): open the client's connector/MCP settings, choose to add a **custom
remote connector**, and give it the URL above. No headers, no keys.

**Any other agent**: the two facts you need are the URL and the shape — it is a
remote HTTP MCP server that authenticates with OAuth. Configure it however that
client configures remote MCP servers; don't guess at a token.

### 2. Authenticate

OAuth is the only auth path, so the client has to run the flow — you cannot
curl it into place.

- Command Code: `cmd mcp auth ellora`, or run `/mcp` and authenticate.
- Claude Code: run `/mcp` and authenticate `ellora`. A server you added with
  `claude mcp add` also accepts `claude mcp login ellora`; one installed
  through the Ellora plugin is listed as `plugin:ellora:ellora`, so use `/mcp`.
- Other clients: trigger a connect/authenticate action and follow the browser
  prompt.

A browser opens on `app.getellora.com`. The user signs in and approves the
connection; tokens are then stored and refreshed by the client. If no browser
opens, print the URL and have them open it manually, then paste the callback
URL back. Verify afterwards (re-run the check from "First", or
`cmd mcp list` / `/mcp`) that the server shows **connected**, not
*needs authentication*.

**If the user has no account**, go to State 1 to register. If an existing
account cannot sign in, report the error and direct them to
hello@getellora.com; registration does not bypass a suspended account.

## State 3 — Connected: write with Ellora on

This is the standing default from here on: **whenever you are drafting or
substantially rewriting prose of the covered kinds, run the review loop before
you present the draft to the user.** Not only when they say "Ellora" — the
point is that it is always on, so the first version they see is already
on-voice and deslopped.

Covered: blog posts and articles · landing-page and website copy · launch and
release announcements · customer-facing emails · docs for an external audience
· social posts · newsletters · decks and outreach.

Skip: code, config, commit messages, internal scratch notes, quick chat
replies, and anything the user calls a rough throwaway. When it is genuinely
borderline, ask once: "Want me to run this through the Ellora voice check?"

When the connection is new, confirm it in one line and put it to work — say
what you'll do (run every draft through the voice check) and get on with the
user's actual writing task.

## The review loop

Fuller version: the `ellora-review` skill, if it is installed. Same sequence
also lives on the server as the `ellora_review_loop` MCP prompt.

1. **Pick a voice profile** — `ellora_profiles_fetch_active`. One → use it.
   Several → ask which (teams commonly keep one per writer, or per author they
   want to sound like). None → a team admin can create one with
   `ellora_profile_create` from 2–20 samples of the team's own writing, then
   use the returned `voice_profile_id`. Don't send them elsewhere to build one,
   and never review without one — an id has to resolve to a saved, active
   profile. If the user isn't an admin and none exists, stop and say a profile
   has to be created first; that's a real blocker, not something to work around.
2. **Pick a writing brief** — `ellora_briefs_fetch_active`. Same pattern. If
   there is none, build an inline `writing_brief_json` for this session only
   (never saved). **A brief is mandatory** — `ellora_session_start` fails
   without either a `writing_brief_id` or a `writing_brief_json`. Pass the JSON
   as an **object**, not a string. Required fields: `version` (`"1"`),
   `audience`, `intent`, `format`. `format` is one of `general`, `social`,
   `deck`, `outreach`, `blog`, `audit`, `website`.
3. **Start the session** — `ellora_session_start` with those two. They are
   locked for the whole session. Keep the returned `content_session_id` and
   pass it to every later call for this one piece of content. While you're
   there, self-report the optional `model_name` / `model_class` /
   `model_version` / `thinking_effort` and `mcp_client_name` /
   `mcp_client_version` — analytics-only, never affects the review.
4. **Optionally pull positioning** — `ellora_positioning_recommendations`,
   before drafting. Advisory only.
5. **Review** — `ellora_review` with the `content_session_id` and the current
   draft as `content`. It takes no profile or brief argument of its own — both
   are already locked into the session. `content` is capped at 100,000
   characters, so split anything longer into successive pieces.
6. **Do what `next_action` says.**
   - `keep_rewriting` → rewrite using the response's own `rewrite_guidance`,
     then go back to step 5 with the same `content_session_id`. **Do not show
     the draft to the user yet** — you are mid-loop.
   - `ready_to_verify` → no mandatory finding remains. Check *this same
     response*: it already carries a `verification` block comparing the
     content against the session's first-reviewed content — **unless this was
     the session's very first call**, in which case there is nothing yet to
     compare against (treat it like `keep_rewriting` if findings remain, or
     deliver as-is if there are none). Don't run another pass just to get
     verified. Deliver once `verification.passed: true`.
   - `diminishing_returns` → the rewrites stopped helping, or you hit
     `max_iterations`. Stop looping, tell the user exactly what is still
     flagged, and ask how to proceed.

   **Blue findings never gate.** Severity `blue` (counted separately in
   `current_finding_counts.blue`) are optional AI-Editor suggestions: they
   never make `next_action` `keep_rewriting` and are never a reason to run
   another pass. Apply or ignore them as you see fit.
7. **Verification and learning are automatic.** A passing call that isn't the
   session's first already carries the `verification` block, and on success
   against a saved profile a `learning_event`. There is no separate verify call
   to make.
8. **Teach the profile only on explicit approval.** If the user accepts the
   delivered rewrite *and* approves the rules you extracted from it, call
   `ellora_learn_from_accepted_rewrite` with `user_approved: true`. Never on
   your own inference.

Keep going around 5 → 6 → 7 until step 6 sends you out of the loop. Don't stop
early because the draft "seems good enough" — the `iteration` / `max_iterations`
budget exists so you can keep going with confidence.

One session = one piece of content. A different article, or a switch to another
profile or brief, means a new `ellora_session_start`.

When the loop finishes, present the final draft plus a short summary: how many
passes it took, what changed at a high level, and anything still flagged that
you chose to leave. Don't dump raw finding JSON unless asked.

## Tools

| Tool | Use it for |
|---|---|
| `ellora_session_start` | Open a session for one piece of writing; locks in profile + brief |
| `ellora_review` | Review the draft; auto-inlines rewrite guidance, auto-verifies |
| `ellora_learn_from_accepted_rewrite` | Save a human-approved rule (never on inference) |
| `ellora_profile_create` | **Admin-only.** Create a voice profile from 2–20 samples |
| `ellora_profiles_fetch_active` / `_by_id` | Find a usable voice profile id |
| `ellora_briefs_fetch_active` / `_by_id` | Find a usable writing brief id |
| `ellora_context_fetch_active` / `_by_id` | Read the team's company context docs |
| `ellora_context_capture` | Save a context doc mid-session (admin activates it) |
| `ellora_positioning_recommendations` | Advisory messaging/positioning guidance |

Prompts: `ellora_review_loop`.

## Rules

1. **Never invent results.** If the tools aren't connected, say so and carry on
   without Ellora. Do not describe a finding, a score, or a `passed` verdict you
   did not get back from `ellora_review`.
2. **Don't route around access or plan limits.** Signup requires accepting the
   terms and verifying the email; connection requires OAuth. Solo permits one voice profile
   and no team members. Use the Pricing page to discuss a Team upgrade.
3. **Don't show unreviewed drafts as reviewed**, and don't claim a piece passed
   when you stopped on `diminishing_returns`.
4. **Follow `next_action`**, not your own judgment, about whether to keep
   looping.
5. **A brief is mandatory.** If the team has none, build the inline
   `writing_brief_json` rather than skipping the review.
6. **One piece of content, one session.**

View saved version →

---
name: ellora-review
description: >-
  Run the Ellora brand-voice + AI-Editor review loop on prose written or
  edited for the team — blog posts, marketing copy, launch announcements,
  customer emails, docs, landing-page and social copy. Use whenever you
  draft or substantially revise content of this kind, BEFORE showing it to
  the user, even if "Ellora" is not mentioned by name. Walks through
  starting a content session, reviewing against the team's saved voice
  profile and writing brief, rewriting, and looping until the draft
  converges (or verification passes). Requires the Ellora MCP server to be
  connected.
---

# Ellora review loop

The Ellora MCP server (`ellora_*` tools) is this team's automated writing QA:
**VoiceDNA** checks a draft against a saved brand-voice profile, **AI Editor**
strips AI-tell / slop, and an optional **Editorial** pack checks format-level
brief rules. This skill is the procedure for using it well — in particular,
for *looping until the draft is actually done* instead of stopping after one
or two passes.

## When to use this

Use it whenever you produce or meaningfully rewrite prose that is meant to go
out in the team's voice:

- blog posts, articles, newsletters
- landing-page / website copy, marketing one-pagers
- launch or release announcements
- customer-facing emails, in-app copy, release notes
- social posts, docs written for an external audience

You do **not** need the user to say "Ellora", "run the review loop", or
"check the voice" — if the content is of this kind, run the loop before you
present a draft.

**Skip it for:** code, config, commit messages, internal scratch notes,
quick chat replies, or content the user explicitly says is a rough
throwaway. If in doubt, ask: "Want me to run this through the Ellora voice
check?"

## Prerequisites

The Ellora tools must be connected: `ellora_session_start`, `ellora_review`,
`ellora_learn_from_accepted_rewrite`, `ellora_profile_create`,
`ellora_profiles_fetch_active`,
`ellora_profiles_fetch_by_id`, `ellora_briefs_fetch_active`,
`ellora_briefs_fetch_by_id`, `ellora_context_fetch_active`,
`ellora_context_fetch_by_id`, `ellora_context_capture`,
`ellora_positioning_recommendations`. If they are not available, tell the user
the Ellora MCP server isn't connected and continue without it — don't
fabricate results.

The older `ellora_analyze`, `ellora_verify`, `ellora_rewrite_prompt`,
`ellora_prepare_rewrite` and `ellora_apply_rewrite` tools no longer exist —
they were merged into `ellora_review`. One `ellora_review` call analyzes the
draft, returns rewrite guidance when findings are open, and auto-verifies once
the draft passes. There is no separate verify call.

## The loop

1. **Pick a voice profile.** Call `ellora_profiles_fetch_active`.
   - Exactly one → use it.
   - More than one → ask the user which one this piece is for.
   - None → a team admin can create one with `ellora_profile_create` from
     2-20 samples of the team's own writing, then use the id it returns. If
     they aren't a team admin, tell them a profile has to exist first — you
     can't run VoiceDNA without one.

2. **Pick a writing brief.** Call `ellora_briefs_fetch_active`. Same pattern:
   one → use it; several → ask; none → construct an inline `writing_brief_json`
   for this session only (it is never saved). **A brief is mandatory** —
   `ellora_session_start` fails without either a `writing_brief_id` or a
   `writing_brief_json`.

3. **Start the session.** Call `ellora_session_start` with the chosen
   `voice_profile_id` and `writing_brief_id` / `writing_brief_json`. These
   are **locked for the whole session** — every later call reuses them.
   Keep the returned `content_session_id` and pass it to every call below,
   for this one piece of content. The response also tells you
   `max_iterations` (the loop budget).
   - Pass `writing_brief_json` as a JSON **object**, never as a stringified
     one. Required fields: `version` (`"1"`), `audience`, `intent`, `format`.
   - `format` must be one of: `general`, `social`, `deck`, `outreach`,
     `blog`, `audit`, `website`.

4. **Optionally pull positioning.** When messaging guidance would help, call
   `ellora_positioning_recommendations` with the `content_session_id` before
   drafting. Its output is advisory and never changes `ellora_review`.

5. **Review.** Call `ellora_review` with the `content_session_id` and the
   current draft as `content`.

6. **Do what `next_action` says.** The response carries
   `convergence_recommendation`, `iteration` / `max_iterations`, and a
   plain-language `next_action`. Follow it:
   - **`keep_rewriting`** → go to step 7. **Do not show the draft to the
     user yet.** You are mid-loop.
   - **`ready_to_verify`** → no mandatory finding remains. **This same
     response** already includes the `verification` block (step 8) — do not
     run another pass just to get verified. If this was the session's very
     first call there is nothing to compare against yet: treat it like
     `keep_rewriting` if findings remain, or deliver as-is if there are none.
   - **`diminishing_returns`** → the rewrites have stopped helping, or you
     have hit `max_iterations`. Stop looping on your own. Tell the user
     exactly what is still flagged and ask how they want to proceed (ship
     as-is / keep going / adjust the voice profile or brief).

   **Blue findings never gate.** Severity `blue` (counted separately in
   `current_finding_counts.blue`) are optional AI-Editor suggestions: they
   never make `next_action` `keep_rewriting` and are never a reason to run
   another pass. Apply or ignore them as you see fit.

7. **Rewrite, then re-review.** Use the response's own `rewrite_guidance`
   field to rewrite the content yourself, then **go back to step 5** with the
   new text and the same `content_session_id`.

   Keep going around 5 → 6 → 7 until step 6 sends you out of the loop. Do
   not stop early just because the draft "seems good enough" — the
   `iteration` / `max_iterations` budget is there so you can keep going with
   confidence; that's the whole point of this skill.

8. **Verification is automatic.** Once a call passes and it is not the
   session's first review, that same response includes a `verification`
   block comparing the final text against the session's original content —
   and, on success against a saved profile, a `learning_event`. There is no
   separate verify call to make. Stop and deliver once you see
   `verification.passed: true`.

9. **Teach the profile only on explicit approval.** If the user accepts the
   delivered rewrite AND approves one or more concise rules you extracted
   from it, call `ellora_learn_from_accepted_rewrite` with the same
   `content_session_id`, those rules, and `user_approved: true`. Do not call
   it on your own inference.

## What to tell the user at the end

Once the loop finishes, present the final draft plus a short summary:

- how many passes it took (`iteration`)
- what changed between the first draft and the final one, at a high level
- anything still flagged that you chose not to act on, and why (e.g.
  judgment-required advisories, or a `diminishing_returns` stop)

Don't dump raw finding JSON at the user unless they ask for it.

## Notes

- One session = one piece of content. A different article, or a switch to a
  different voice profile / brief, means a **new** `ellora_session_start`.
- Only `ellora_review` writes history rows (visible read-only in the Ellora
  app under Content Sessions).
- The MCP server also exposes an `ellora_review_loop` prompt with this same
  sequence — this skill is the fuller version, with the "keep looping" and
  "when to use" guidance the prompt can't carry.