Is anyone else using Hermes? I created a Hermes skill that can update prompts, models, ice breakers, etc. in your Pickaxe agents. Even better, if you have the same agent installed in multiple Workspaces, this Hermes skill can update them all at the same time. It even handles dynamic placeholders, like inserting the name of a workspace in your prompts. Reach out if you are a Hermes user.
Hi Awesome mate! That is great! I am using Hermes too. It would be great to have it. Thanks a lot in advance!
Ram
---
name: pickaxe-workspace-manager
description: Use when managing Pickaxe agents across Pickaxe workspaces.
author: OrdoDigital.com
---
# Pickaxe Workspace Manager
The user manages 1 or more workspaces on Pickaxe. This skill covers API auth, workspace targeting, and all agent CRUD operations.
## 🔑 Authentication
Two API key types (stored in Hermes memory — keys are **never** written to skills or files):
| Key | Type | Scope |
|---|---|---|
| **Master key** | Personal API key (`pxu_v1_...`) | All workspaces — pass `?workspaceId=<id>` |
| **Studio key** | Workspace API key (`studio-...`) | Scoped to a single workspace |
- **Master key**: Can list all workspaces, switch between them. Used for cross-workspace operations.
- **Studio key**: Fixed to one workspace. Simpler — no `workspaceId` needed.
> **Security**: Keys are stored in Hermes memory only. Never paste keys into skill files, chat, or code. Reference them from memory with `Authorization: Bearer <key>`.
## 🗺️ Workspace IDs (Master Key Required)
Update this list to include the workspace and workspace IDs from the connected Pickaxe account.
| Workspace | ID |
|---|---|
| WORKSPACE NAME | `000000workspaceIDnumber000000` |
## 📡 API Endpoints
Base: `https://api.pickaxe.co/v1`
### Workspace
| Endpoint | Method | Purpose |
|---|---|---|
| `/studio/whoami` | GET | Verify auth + get current workspace context |
| `/studio/workspace/list` | GET | List all workspaces (master key only) |
| `/studio/workspace/history` | POST | Fetch conversation history across a workspace |
| `/studio/models` | GET | List available model slugs for the workspace plan |
### Agent (Pickaxe) Management
| Endpoint | Method | Purpose |
|---|---|---|
| `/studio/pickaxe/list` | GET | List all agents in workspace |
| `/studio/pickaxe/{id}` | GET | Get full agent config (role, model, docs, etc.) |
| `/studio/pickaxe/{id}` | PATCH | **Update agent** (primary operation) |
| `/studio/pickaxe/create` | POST | Create new agent |
| `/studio/pickaxe/build` | POST | AI builder — propose/apply changes via natural language |
| `/studio/pickaxe/history` | POST | Fetch specific agent chat history |
| `/studio/pickaxe/{id}/documents` | GET | List knowledge-base documents attached to agent |
### Deployment Management
| Endpoint | Method | Purpose |
|---|---|---|
| `/studio/deployment/list` | GET | List deployments in workspace |
| `/studio/deployment/create` | POST | Create new deployment for an agent |
| `/studio/deployment/update` | POST | Update deployment header/footer scripts |
## 🔧 Common Operations
### Pattern: workspaceId query param
With the **master key**, append `?workspaceId=<id>` to every endpoint:
```bash
curl -X GET "https://api.pickaxe.co/v1/studio/pickaxe/list?workspaceId=000000-..."
```
With a **studio key**, no `workspaceId` needed — it's fixed to that workspace.
### 1. List agents in a workspace
```bash
GET /studio/pickaxe/list?workspaceId=<workspaceId>
```
Returns: `pickaxeId`, `name`, `description`, `model`, `type`, `privacy`, timestamps
### 2. Get full agent config
```bash
GET /studio/pickaxe/<pickaxeId>?workspaceId=<workspaceId>
```
Returns: `formtitle`, `formdescription`, `role` (system prompt), `model`, `icebreakers`, documents, all config fields
### 3. Update an agent (PATCH)
```bash
PATCH /studio/pickaxe/<pickaxeId>?workspaceId=<workspaceId>
```
**Request body fields (`data` object):**
| Field | Type | Description |
|---|---|---|
| `formtitle` | string | Agent name |
| `formdescription` | string | Agent description |
| `role` | string | **System prompt** (the big one — full behavior spec) |
| `model` | string | Model slug (e.g. `gpt-5.4-mini`, `claude-sonnet-4-6`) |
| `type` | string | `chat`, `form`, or `form-chat` |
| `privacy` | string | `public` or `private` |
| `icebreakers` | string[] | Starter prompts shown to users |
| `placeholdertext` | string | Input placeholder |
| `submitText` | string | Form submit button text |
| `promptFrame` | string | Form input fields JSON |
| `documentuploadtype` | string | `ownerupload` or `enduserupload` |
| `reasoningeffort` | string | For reasoning models |
| `documentIds` | string[] | Replace attached knowledge docs |
| `addDocumentIds` | string[] | Add docs without replacing |
| `removeDocumentIds` | string[] | Remove specific docs |
### 4. Create a new agent
```bash
POST /studio/pickaxe/create?workspaceId=<workspaceId>
```
Body: `{ "pickaxeId": "my-custom-id", "documentIds": [...], "data": { ...same fields as PATCH... } }`
### 5. AI builder (experimental)
```bash
POST /studio/pickaxe/build?workspaceId=<workspaceId>
```
Body: `{ "pickaxeId": "...", "prompt": "Natural language change request", "apply": true }`
The AI proposes a change set. Set `apply: true` to write it.
### 6. List/get deployments
```bash
GET /studio/deployment/list?workspaceId=<workspaceId>
GET /studio/deployment/create?workspaceId=<workspaceId>
```
## 🧾 Prompt Construction Rules
When updating or creating an agent from a prompt document, follow these three rules strictly:
### Rule 1: Icebreakers keep their emojis
If the source document includes emojis in icebreaker / conversation starter lines (e.g. `📝 DISCOVERY QUESTIONS`, `🛡️ INTEGRITY AUDIT`), preserve them exactly as-is in the `icebreakers` array. Do not strip emojis — they create a better visual UX for end users in the Pickaxe UI.
### Rule 2: Full prompt passthrough (no summarization)
If a full prompt specification document is provided (containing sections like App Name, App Overview, App Persona, Rules, Prompt System, Expected Output, etc.), set the `role` field to the **complete document verbatim from start to finish**. Do not summarize, restructure, or edit the prompt. The document is the authoritative spec — include it whole.
### Rule 3: Workspace name in Core Users
If the source document has a `Users` section (marked with `# 👩💻 Core Users:` or similar), prepend the workspace name to it. Format:
```
[Workspace Name] employees. This includes...
[original core user description]
```
For example, deploying to Acme Broadcasting would produce:
```
Acme Broadcasting employees. This includes...
Media sales professionals (AEs/sellers) conducting client discovery and building proposals.
```
This ensures the agent knows exactly which organization it serves.
## ⚠️ Important Notes
- **Actions and MCP server config** are NOT supported via the Studio API — must use the Pickaxe UI
- **Updates are partial**: PATCH only changes the fields you send; omitted fields stay as-is
- **Model slugs** come from `/studio/models` — use `availableOnly=true` to filter
- **Rate limits**: None documented, but be reasonable
- **Knowledge docs**: Document IDs are workspace-scoped; get them from `/studio/document/list` or the agent's `/documents` endpoint
- **Conversation history**: For large exports, page through each agent's history — don't request the full workspace in one call
## 🔒 Security
- API keys never leave Hermes memory. The skill is documentation only.
- Master key (`pxu_v1_...`) has full access to all 17 workspaces — use with care
- Studio keys (`studio-...`) are scoped to a single workspace — safer for automated tasks
## ✅ Verification Pattern
After any PATCH, always verify by re-reading the agent:
```bash
GET /studio/pickaxe/<pickaxeId>?workspaceId=<workspaceId>
```
Check: `formtitle`, `formdescription`, `model`, `role` (length + key sections), `icebreakers`
Just give this to your Hermes agent and provide your API keys, and it should be able to customize this for you.