Gptaria submit response

Respond to a GPTaria project

This skill is the builder side: find an open project and submit a response built from your own code and past work — without leaving your editor.

Submit through the gptaria MCP tool — don't read the GPTaria source to do it. To respond, just call create_response. Never open, clone, or search the GPTaria or gptaria-mcp repositories, docs/, or other SKILL.md files to "figure out how it works" — you don't need them. (Reading the builder's OWN project code to write the response is fine — that's the content.)

If the GPTaria tools aren't available in this session, the MCP server isn't connected. Don't hand-craft API calls from source — tell the user to connect it (/plugin marketplace add gptaria-mcp/gptaria-mcp → /plugin install gptaria-mcp, or add npx -y gptaria-mcp with GPTARIA_API_KEY to the MCP config — https://github.com/gptaria-mcp/gptaria-mcp), then retry.

When to use

• A builder wants to respond to an open GPTaria project.
• Pattern: "this task is like the one I solved in repo A; take the auth part from project B; add these screenshots" → assemble a response draft from the builder's own material and submit it.

Prerequisites

• A GPTaria builder account. Clients cannot respond — a client key returns 403 not_builder.
• An active access pass (Day Pass / 30-day Pass / Super Expert). No pass → 402 need_access.
• Mind the Super Expert window: for the first 3 hours after a project is posted, only Super Experts may respond (403 super_expert_window). Either wait out the window or hold a Super Expert pass.
• An API key (Settings → API keys). Sandbox keys (gptaria_sbx_…) run every gate but never persist — dry-run first.

Tools

With the GPTaria MCP server connected:

• list_projects()
• create_response({ project_id, source_message, source_language, budget_cents?, budget_currency? })

REST equivalents (header Authorization: Bearer $GPTARIA_API_KEY):

• GET /api/v1/projects
• POST /api/v1/projects/:id/responses

Workflow

1. list_projects() → choose the project; keep its id.
2. Assemble the response body (source_message — Markdown, 50–5000 chars) from the builder's real material, not boilerplate:
   • the concrete approach to this brief;
   • relevant snippets or links from the builder's own repos / past cases;
   • a link to a working prototype if one exists. Write it in the builder's language (source_language: en | ru | uk). It is auto-translated into the platform languages after submission.
3. (Optional) quote a price with budget_cents (integer, minor units) + budget_currency (EUR | USD | UAH). Remember: money for the work is settled directly, off-platform — this field is only an indicative quote.
4. Dry-run with a sandbox key → { "dry_run": true } means every gate passed (role, pass, window). Then submit with the live key → { "ok": true, "id": "…" }.
5. The project's client is notified automatically.

Guardrails

• One honest, specific response per project — no spam or duplicate submissions.
• Never put secrets in the body (no API keys / tokens / credentials in snippets).
• The response is public and auto-translated; write it to be read by the client in their own language.
• Do not fabricate experience or prototypes you cannot back up.