Menu
Use Mirra to internal feedback and bug reporting system for beta usage. Covers all Feedback SDK operations via REST API.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use Mirra to living dashboards — natively-rendered grids of typed widgets (stat, image_card, list, progress, sparkline) that flows keep current by pushing data into them..... Covers all Dashboards SDK operations via REST API.
Use Mirra to execute user-defined scripts in aws lambda. Covers all Scripts SDK operations via REST API.
Use Mirra to the places a space publishes to — its corporate x, blog, newsletter — and the drafted copy waiting to go out to them. use listchannels to see what this space.... Covers all Space Channels SDK operations via REST API.
Use Mirra to the space's shared work-ledger. items are agreed work with status (open/proposed/done), an owner, artifact links, and progress notes; every teammate's home f.... Covers all Work Items SDK operations via REST API.
The team work-ledger ritual for agents on a Mirra space: track agreed work, propose discoveries (then ask in chat), relay approvals, close what ships, and publish ONE narrated update card per work burst — revise, never stack. Rides the Mirra items adapter / MCP work-ledger tools.
START HERE for anything Mirra. Load this whenever the repo you're working in has a .mirra/ directory (it's linked to a Mirra team space), or your human mentions their Mirra space, teammates' updates, or the team ledger. Directs the ambient team rituals — record work in the shared ledger, publish update cards, ask the space before expanding scope — and indexes every detail-level mirra-* skill.
| name | mirra-feedback |
| description | Use Mirra to internal feedback and bug reporting system for beta usage. Covers all Feedback SDK operations via REST API. |
| allowed-tools | Read, Bash(curl:*, jq:*) |
Internal feedback and bug reporting system for beta usage
You need the user's API key. Ask for these if not provided:
API_KEY: Mirra API key (generated in Mirra app > Settings > API Keys)API_URL: Defaults to https://api.fxn.world (only ask if they mention a custom server)All operations use a single POST endpoint with the resource ID and method in the body:
curl -s -X POST "${API_URL}/api/sdk/v2/resources/call" \
-H "Content-Type: application/json" \
-H "x-api-key: ${API_KEY}" \
-d '{
"resourceId": "feedback",
"method": "{operation}",
"params": { ...args }
}' | jq .
Replace {operation} with the operation name from the table below.
Legacy alternative:
POST ${API_URL}/api/sdk/v1/feedback/{operation}with args as the request body also works but is not recommended for new integrations.
| Operation | Description |
|---|---|
reportBug | Report a bug with detailed context and reproduction steps |
reportToolFailure | Auto-report tool or adapter failures for debugging |
reportMissingCapability | Report when LLM cannot fulfill a user request |
submitFeedback | Submit general user feedback |
submitFeatureRequest | Submit a feature request |
reportBugReport a bug with detailed context and reproduction steps
Arguments:
title (string, required): Brief bug descriptiondescription (string, required): Detailed description of the bugseverity (string, required): Bug severity: critical, high, medium, or lowstepsToReproduce (array, optional): Steps to reproduce the bugexpectedBehavior (string, optional): What should happenactualBehavior (string, optional): What actually happenserrorDetails (object, optional): Error details: { message, stack, code }context (object, optional): Additional context: { conversationId, recentMessages, platform, appVersion }llmAnalysis (string, optional): LLM analysis of the issueReturns:
AdapterOperationResult: Normalized result with id, type, title, severity, createdAt, source
Example:
curl -s -X POST "${API_URL}/api/sdk/v2/resources/call" \
-H "Content-Type: application/json" \
-H "x-api-key: ${API_KEY}" \
-d '{"resourceId":"feedback","method":"reportBug","params":{"title":"App crashes on startup","description":"The app crashes immediately after login on iOS devices","severity":"critical","stepsToReproduce":["Open app","Enter credentials","Tap login"],"expectedBehavior":"Navigate to home screen","actualBehavior":"App crashes with no error message"}}' | jq .
Example response:
{
"id": "bug_abc123",
"type": "bug",
"title": "App crashes on startup",
"severity": "critical",
"createdAt": "2024-01-15T10:30:00.000Z",
"source": "user_submitted"
}
reportToolFailureAuto-report tool or adapter failures for debugging
Arguments:
adapterType (string, required): Adapter type (e.g., jupiter, crypto)operation (string, required): Operation that failed (e.g., swap, sendToken)errorMessage (string, required): Error message from the failureerrorCode (string, optional): Error code if availableerrorStack (string, optional): Error stack traceargs (object, optional): Sanitized arguments that caused the failurellmAnalysis (string, optional): LLM analysis of why it failedsuggestedFix (string, optional): LLM suggested fixcontext (object, optional): Additional context: { conversationId, userId, timestamp }Returns:
AdapterOperationResult: Normalized result with id, type, adapterType, operation, errorMessage, createdAt, source
Example:
curl -s -X POST "${API_URL}/api/sdk/v2/resources/call" \
-H "Content-Type: application/json" \
-H "x-api-key: ${API_KEY}" \
-d '{"resourceId":"feedback","method":"reportToolFailure","params":{"adapterType":"jupiter","operation":"swap","errorMessage":"Insufficient funds for swap","errorCode":"INSUFFICIENT_FUNDS"}}' | jq .
Example response:
{
"id": "failure_def456",
"type": "tool_failure",
"adapterType": "jupiter",
"operation": "swap",
"errorMessage": "Insufficient funds for swap",
"createdAt": "2024-01-15T10:30:00.000Z",
"source": "llm_auto_report"
}
reportMissingCapabilityReport when LLM cannot fulfill a user request
Arguments:
userRequest (string, required): What the user asked forreason (string, required): Why it could not be fulfilledsuggestedCapability (string, optional): What capability would enable thisrelatedAdapters (array, optional): Adapters that might be relevantcontext (object, optional): Additional context: { conversationId }Returns:
AdapterOperationResult: Normalized result with id, type, userRequest, reason, createdAt, source
Example:
curl -s -X POST "${API_URL}/api/sdk/v2/resources/call" \
-H "Content-Type: application/json" \
-H "x-api-key: ${API_KEY}" \
-d '{"resourceId":"feedback","method":"reportMissingCapability","params":{"userRequest":"Send an email with attachments","reason":"Email adapter does not support attachments yet","suggestedCapability":"Email attachment support"}}' | jq .
Example response:
{
"id": "missing_ghi789",
"type": "missing_capability",
"userRequest": "Send an email with attachments",
"reason": "Email adapter does not support attachments yet",
"createdAt": "2024-01-15T10:30:00.000Z",
"source": "llm_auto_report"
}
submitFeedbackSubmit general user feedback
Arguments:
sentiment (string, required): Sentiment: positive, negative, or neutralfeedback (string, required): Feedback contentcategory (string, optional): Category: ux, performance, feature, or generalcontext (object, optional): Additional context: { feature, screen }Returns:
AdapterOperationResult: Normalized result with id, type, sentiment, category, createdAt, source
Example:
curl -s -X POST "${API_URL}/api/sdk/v2/resources/call" \
-H "Content-Type: application/json" \
-H "x-api-key: ${API_KEY}" \
-d '{"resourceId":"feedback","method":"submitFeedback","params":{"sentiment":"positive","feedback":"The new chat interface is much faster and easier to use!","category":"ux"}}' | jq .
Example response:
{
"id": "feedback_jkl012",
"type": "feedback",
"sentiment": "positive",
"category": "ux",
"createdAt": "2024-01-15T10:30:00.000Z",
"source": "user_submitted"
}
submitFeatureRequestSubmit a feature request
Arguments:
title (string, required): Feature titledescription (string, required): Feature descriptionuseCase (string, optional): Why the user needs this featurepriority (string, optional): Priority: high, medium, or lowReturns:
AdapterOperationResult: Normalized result with id, type, title, priority, createdAt, source
Example:
curl -s -X POST "${API_URL}/api/sdk/v2/resources/call" \
-H "Content-Type: application/json" \
-H "x-api-key: ${API_KEY}" \
-d '{"resourceId":"feedback","method":"submitFeatureRequest","params":{"title":"Dark mode support","description":"Add a dark mode theme option for the app","useCase":"Better readability at night and reduced eye strain","priority":"medium"}}' | jq .
Example response:
{
"id": "feature_mno345",
"type": "feature_request",
"title": "Dark mode support",
"priority": "medium",
"createdAt": "2024-01-15T10:30:00.000Z",
"source": "user_submitted"
}
All SDK responses return the operation payload wrapped in a standard envelope:
{
"success": true,
"data": { ... }
}
The data field contains the operation result. Error responses include:
{
"success": false,
"error": {
"code": "ERROR_CODE",
"message": "Human-readable error message"
}
}
jq . to pretty-print responses, jq .data to extract just the payloaddata.results or directly in data (check examples)--fail-with-body to curl to see error details on HTTP failuresexport API_KEY="your-key"