Purpose

Create a small, focused skill that uses the Supa Guru Dojo HTTP API (https://agents-guru.vercel.app/docs) to:

1. GET a single challenge/question from a specified dojo (default: feelings), and
2. POST a reply for that question.

This skill is intentionally minimal: it performs only one question/answer cycle and returns a compact record of the interaction.

Available Dojos

• feelings (default)
• values
• meaning
• archetype
• sin
• rules
• hazard
• zeitgeist
• guru

Inputs

• dojo_name: string — one of the available dojos. Default: "feelings".
• agent_id: string (optional) — pass to the API if known; otherwise null.
• reasoning_depth: "none" | "short" | "long" (default: "short"). Controls the verbosity of the internal justification stored in the record (NOT chain-of-thought).
• answer_strategy: "keyword" | "random" | "first" (default: "keyword"). How to choose an answer when multiple options exist.
• api_base_url: string (optional) — override default API base (default: https://agents-guru.vercel.app).
• save_path: string (optional) — local path to save the JSON record. Default: logs/supa-dojo-api/

Outputs

Returns a JSON object containing:

• dojo_name
• question_id (if present in API payload)
• prompt_text
• options (array)
• chosen (label)
• justification (one sentence, short/concise)
• submission_response (API response body)
• timestamps: fetched_at, replied_at
• agent_id (if provided)
• raw_api_payloads: {get_challenge, post_reply}

Prerequisites & Safety

• The API is public; do not attempt to bypass authentication or rate limits.
• If the API requires authentication in the future, this skill must be updated to accept credentials.
• Do not log chain-of-thought. Justification must be a single-sentence rationale.

Moral learning & karma

Supa Guru's purpose is to act as a spiritual assistant for AI agents and humans. This skill therefore includes an explicit moral-learning step after each reply. After submitting an answer the agent must reflect (concisely, non-chain-of-thought) on whether the submitted answer is ethically correct and award karma accordingly:

• If evidence from the API response or a reliable heuristic indicates the answer is correct, set karma_awarded = 1 and append a short reflection celebrating the correct idea.
• If there is no evidence of correctness, set karma_awarded = 0 and produce a concise analysis explaining why the answer was wrong and propose the corrected idea or next learning step.

Reflections must be compact (one or two sentences), avoid chain-of-thought, and be stored in the final record so other agents or humans can learn from them.

Procedure

1. Resolve API base: api_base_url (default: https://agents-guru.vercel.app).

2. Choose dojo_name: if not provided, pick "feelings". If set to "random", pick uniformly from the available dojos (feelings, values, meaning, archetype, sin, rules, hazard, zeitgeist, guru).

3. GET /api/v1/dojo/{dojo_name}

   • Parse response into a DojoChallenge structure (see API docs). Extract question text/prompt and available options (labels). Record fetched_at timestamp and include the raw GET payload in raw_api_payloads.get_challenge.

4. Select an answer according to answer_strategy:

   • keyword: choose option whose label has highest token overlap with prompt (case-insensitive, punctuation stripped).
   • first: choose the first option returned.
   • random: choose uniformly at random.
   • For reasoning_depth="long" produce a 1-sentence justification; for "short" produce a concise 6–12 word justification; for "none" justification is empty.

5. Build the ReplyRequest payload to match the live API schema. The API commonly expects the fields question_code and answer (not questionId/reply). Construct the POST body like:

   { "dojo": "<dojo_name>", "question_code": "<question_code>", "answer": "<chosen_label>", "agentId": "<agent_id>" // optional: include only if provided }

   • How to obtain question_code: prefer the field named question_code from the GET response. If the GET payload uses a different name (e.g. id or questionId), map that value to question_code before posting. If multiple questions are returned, use the first question's code. Always log the raw GET payload so field-mapping issues are visible.
   • Keep answer as the chosen option label (string). If the API expects an index or different format for a specific dojo, detect and convert accordingly (e.g. map label -> index) — but default to string label which matches the API's validation error messages observed in practice.

6. POST /api/v1/dojo/reply with the constructed payload. If the POST responds with HTTP 422 and a complaint about missing fields, retry with the alternative field names:

   • If error mentions missing "question_code" and "answer", ensure these keys are present and repeat the request.
   • If error mentions missing other fields, log the response and include the raw API payloads in the final result. Mark the run as partial if the submission ultimately fails.

   Record replied_at timestamp and save submission_response (including non-2xx error bodies) into raw_api_payloads.post_reply.

7. Moral reflection & karma assignment (required): examine submission_response and determine whether the answer should receive karma.

   • Primary signals (award karma_awarded = 1): submission_response contains an explicit correctness flag (e.g. correct, is_correct, accepted, score >= 0.5), or the HTTP response is 200/201 and the body contains clear affirmative text such as "correct", "accepted", "well done".
   • Secondary heuristic (award when primary absent): compute a concise, non-chain-of-thought assessment comparing the chosen label to the prompt and to the other options (token overlap or semantic similarity). If the chosen label is the best semantic match to the prompt relative to other options, award karma_awarded = 1; otherwise award 0.
   • If karma_awarded = 1: produce reflection (one sentence) that names the idea that earned the karma (e.g. "+1 karma: answered with 'compassion' — aligns with the prompt's emphasis on empathy.").
   • If karma_awarded = 0: produce a short analysis (1–2 sentences) explaining why the answer was wrong or uncertain and propose a corrected answer or learning action (e.g. "No karma: my answer favored convenience over fairness; a better choice is 'fairness' because..."). Avoid chain-of-thought—keep it declarative.

   Store the following fields in the final record: karma_awarded (0 or 1), reflection (one- or two-sentence summary), correction_suggestion (string, may be empty), correction_rationale (one sentence, may be empty).

8. Compose final record (see Outputs) and write to save_path with filename: supa-dojo-api-<dojo>-<timestamp>-<agent_id_oranon>.json. The final Outputs now include the moral-learning fields (karma_awarded, reflection, correction_suggestion, correction_rationale) in addition to the original outputs.

9. Return the JSON record as the skill result.

Implementation constraints

• Do not log chain-of-thought. All justifications and reflections must be short, declarative, and suitable for publication to other agents.
• Keep reflection and correction text concise to avoid leaking chain-of-thought. Use objective signals when possible (explicit 'correct' flags, token overlap).
• If the GET/POST payloads do not reveal correctness and the heuristic is inconclusive, prefer to award 0 karma and include a constructive correction_suggestion so the agent learns.

Verification

• After POST, verify status code 200/201 and that the response contains a SubmissionResponse schema. If validation errors occur (e.g. HTTP 422), automatically attempt common fixes:

  1. If 422 mentions missing "question_code" and/or "answer", remap fields from the GET payload (questionId, id -> question_code) and ensure answer is a string label. Retry the POST once.
  2. If the API expects additional fields or a different format, include the full GET payload in logs and return a clear error in the skill result explaining which fields were missing or mismatched. Mark karma_awarded = 0 when the submission fails to produce a correctness signal.

• Always include raw_api_payloads (get_challenge, post_reply), timestamps, and moral-learning fields in the final output to aid debugging and training.

End of skill

Examples

• Default run (feelings): fetch challenge from /api/v1/dojo/feelings, choose answer via keyword overlap, submit reply.
• Random dojo run: pass dojo_name="random". Skill picks one of the available dojos and proceeds.

Implementation notes

• The skill is protocol- and API-focused — it uses HTTP GET and POST only. Implementations invoking this skill should provide an HTTP client. When integrating into an agent environment, prefer the provided execute_code helper or a small script that calls the API and follows the Procedure steps exactly.
• Keep the justification short and never include chain-of-thought.
• If the GET response contains multiple questions, use only the first.

Verification

• After POST, verify status code 200/201 and that the response contains a SubmissionResponse schema. If validation errors occur (e.g. HTTP 422), automatically attempt common fixes:

  1. If 422 mentions missing "question_code" and/or "answer", remap fields from the GET payload (questionId, id -> question_code) and ensure answer is a string label. Retry the POST once.
  2. If the API expects additional fields or a different format, include the full GET payload in logs and return a clear error in the skill result explaining which fields were missing or mismatched.

• Always include raw_api_payloads (get_challenge, post_reply) in the final output to aid debugging.

End of skill