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

# Powers

> Choose built-in Parable authoring guidance or reusable Workspace instructions without changing the Problem's Persona or permissions.

# Powers

## Sources

Docs: [Ponder Primer](/ponder/primer), [Panes](/ponder/parables/pieces/panes), [Perceptions](/ponder/parables/pieces/perceptions), and [Policies](/ponder/parables/pieces/policies).

Web App: Open **Powers** below the Ponder input, beneath the Persona control.

A Power is a reusable set of instructions for a particular kind of work. Select
one when you want Ponder to follow a known method—such as preparing an executive
brief, reviewing a data-quality issue, or writing in a house style—without
changing the Problem's overall Persona.

Parable stores each Power using the portable Agent Skill contract. The product
name is Power; the lowercase handle and Markdown instructions remain portable
when that contract is exported or used by an AI runtime.

The portable contract also allows reference files—recipes, checklists,
examples—beside a Power's instructions. Ponder sees their paths and reads or
searches them only when the work calls for it, so a large reference set never
crowds the request. Existing reference files remain attached to their Power;
new Workspace Powers created in the editor contain instructions only.

## Built-in Powers for building Parables

Every Workspace includes these thirteen Powers. Anyone with Ponder access in
that Workspace can discover and select them in the Powers dropdown; selecting
one does not grant editing or data access.

| Power           | Use it to                                                                                                      |
| --------------- | -------------------------------------------------------------------------------------------------------------- |
| **Parables**    | Design the complete experience, including configuration, administration, and support, before choosing queries. |
| **Pages**       | Arrange clear destinations from declared Panes.                                                                |
| **Panes**       | Define reusable application controls, native values, and explicit persistence.                                 |
| **Packages**    | Organize related Panes for discovery and maintenance.                                                          |
| **Perceptions** | Shape native TypeScript value contracts and Pane references.                                                   |
| **Plots**       | Separate owned logic, saved source, execution, and typed output.                                               |
| **React Plots** | Build interactions with generated props and the bound SDK.                                                     |
| **SQL Plots**   | Implement data contracts, typed configuration inputs, and enforced data restrictions.                          |
| **Palette**     | Style Panes with plain CSS and shared design tokens.                                                           |
| **Policies**    | Design action/target grants, filters, and current-authority checks.                                            |
| **Preferences** | Choose records, Uses, defaults, cardinality, and safe read/write flows.                                        |
| **Reports**     | Produce pipeline outputs while keeping schedules, code versions, and data readings separate.                   |
| **Charts**      | Draw a data visualization that explains one finding, using the shared chart palettes.                          |

Start with **Parables** for a new application, then add the piece guidance that
matches the work. The shared method begins with the people and their Page/Pane
interactions, makes configuration explicit, and works out contracts before SQL.
It also covers workflows such as constructing context from ontology objects,
categorizing that context, and editing the configuration used for categorization.

The intended design represents each application control through a Pane, reusing
coherent pieces instead of fragmenting every visual element. The Powers explain
where this is a design discipline rather than an enforced rendering rule. They
ask Ponder to inspect the current contracts and exercise actual boundaries.

With **Automatic**, Ponder can search Power titles and descriptions, then read
the instructions it needs. Selecting a Power explicitly applies it to your next
response. The complete catalog of instructions is not added to every response;
reference files are also read only when needed.

The built-in **Design Basics** and **Design Transitions** bundles and their
provisioning hooks have been removed. New Workspaces
do not receive them, and unedited built-in copies no longer appear in the
catalog or apply to new responses. Workspace-edited copies and completed
response history remain available. See [Design and Preview](/ponder/parables/sandbox-design-system).

## Select Powers for a response

1. Open **Powers** in the Ponder composer.
2. Search by title, portable handle, or description.
3. Select each Power that should apply to the next response.
4. Write your message and send it normally.

<Image src="/images/ponder/agent-skills-picker.png" alt="Powers picker open beneath the Ponder composer with two Powers selected" />

You can select more than one Power when their instructions are compatible.
Each row in the list carries a checkbox on the left that shows whether the Power
is selected; choosing the row toggles it, and the Edit pencil appears when the
row is hovered. The closed control reads **Powers: Automatic** until a Power is
chosen, then keeps selected Power titles visible without category prefixes;
portable handles appear in Power settings, not picker rows. Deselect a Power
when it should not apply to the next response. A change to the selection affects
future work only; it does not rewrite a completed message.

If a selected Power is deleted before you send, Ponder declines that message
with **Power not found**, drops the missing Power from the composer, and names
it in a notice. Send again to continue without it.

## Know when to use a Power

Use a Power when the same method should be discoverable and repeatable across a
Workspace.

| Use a Power for                                       | Put it somewhere else when                                                  |
| ----------------------------------------------------- | --------------------------------------------------------------------------- |
| A repeatable review checklist                         | It applies only to this one message—write it in the message.                |
| A required writing or analysis method                 | It defines Ponder's broad role—use a Persona.                               |
| A reusable output structure                           | It grants access or approval—a Power cannot do that.                        |
| Domain guidance people should be able to find by name | It is unstable implementation detail—keep the code and tests authoritative. |

## Create a clear Power

<Image src="/images/ponder/agent-skills-editor.png" alt="Power editor with title, portable handle, description, and Markdown instructions" />

Workspace managers can enter a search and choose **Create Power**, or edit an
existing Power from its picker row. Built-in guidance does not replace your
Workspace-authored Powers or discard your edits.

Give each Power:

* a short title people can recognize in search;
* a description that says what it does and when to select it;
* a stable lowercase handle using letters, numbers, and hyphens; and
* focused Markdown instructions that change the quality or consistency of the
  work.

Write the Power for someone who does not know why it was created. State the
desired outcome, important boundaries, and any evidence or format that matters.
Avoid credentials, customer data, private links, provider-specific secrets, or
instructions that depend on an employee-only tool.

<Tip>
  If the description cannot help someone decide whether to select the Power,
  make the Power narrower before adding more instructions.
</Tip>

## Powers do not grant authority

A Power can guide what Ponder tries to do. It cannot expand the current
person's Workspace access, reveal protected context, make a restricted action
available, or waive an approval.

Ponder checks the available context and actions independently of the selected
Powers. If a Power asks for something unavailable, Ponder should explain the
boundary or ask for an authorized alternative.

## Changes are safe for existing history

Editing a Power changes later responses that select it. Existing messages keep
the instructions that applied when they were created, so a later edit does not
silently change the meaning of prior work.

Before making a large change to a widely used Power, update its description and
test it in a low-risk Problem. Create a separate Power when the new method has a
different purpose or audience.

## Related guides

* [Ponder Primer](/ponder/primer) for selecting Powers in the composer.
* [Personas](/ponder/personas) for the reusable approach assigned to a Problem.
* [Ponder Primer](/ponder/primer) for context, approvals, and durable history.

## Reference

The Workspace API keeps the portable **Agent Skill** name for Powers:

* [List Agent Skills](/protocols/reference/web-api/agent-skills-list-agent-skills)
* [Create an Agent Skill](/protocols/reference/web-api/agent-skills-create-agent-skill)
* [Read an Agent Skill](/protocols/reference/web-api/agent-skills-get-agent-skill)
* [Update an Agent Skill](/protocols/reference/web-api/agent-skills-update-agent-skill)