Skip logic and branching

Sets up survey logic so that no respondent ever hits a dead end

Free agent skill for Claude Code, Codex, Cursor and Gemini CLI. It works through the SurveyNinja MCP server, with your permissions.

Category
Build and share
Tags
logic and branching, wording
Works with
Claude Code, Codex, Cursor, Gemini CLI
MCP tools
3, 2 of them change data
Version
1.0.1, October 20, 2026
Made by
SurveyNinja
Price
Free
Skill file
SKILL.md

What it does

  • Everyone sees only their questions. Branches, shown and hidden questions, skipped blocks, screenouts and quotas keep respondents away from what does not apply to them.
  • No branch ends in a dead end. Every branch has an exit, to the next block or to the end of the survey.
  • Every route is checked. After the edit the skill walks each branch from the first question to the end.

Example

You type

If someone rates us below four, ask them why

What the assistant brings back

4
Branches
0
Dead endseach route walked
0
Unreachable
0
Loopsno jumps backwards
  1. Rating below 4 → "What went wrong?" branch on answer · question 2
  2. Rating 4 or higher → skip question 3 skipped block
  3. "Never used the service" → screenout screenout · question 4
  4. 200 responses in the group → stop admitting quota
"Other" fires on the option, not on the text

A common mistake is expecting a jump to react to the words typed into the "Other" field. The condition reacts to the option being chosen; the text plays no part.

The rules above are an example. Logic is built from your questions and their identifiers.

How it works

  1. Reads the structure firstThe skill reads the question IDs first, so every condition points at a real question.
  2. Builds the right kind of ruleA branch on an answer, a question shown or hidden, a skipped block, a screenout for people who do not qualify or a quota per group, chosen to fit the task.
  3. Knows the usual traps"Other" fires on the option, not on the text typed into it. "Greater than" does not work on text. Conditions are checked in order and the first match wins.
  4. Walks the route after the editFrom the first question along every branch to the end. With more than three or four branches, the assistant describes the map in words.

Try also

  • Skip the quality questions for people who never used the service
  • Check the survey logic for dead ends

What it will not do

  • Do not write logic without reading the structure
  • Do not change the question set in the same edit
  • Do not build branching where one question with options is enough
  • Do not suggest a plan upgrade or lead to payment

The skill works with your permissions. Tools that change data are marked, so you check what the assistant is about to do before you confirm. To cut access, remove the connector in the assistant or delete the API key.

In short

What can be set up?

A branch on an answer ("rated below four, ask why"), showing or hiding a question, skipping a block, screening out people who do not qualify, and quotas per group.

Why does the skill read the survey first?

Conditions point at questions by their IDs. The skill reads those IDs first, so every condition points at a real question.

How does it avoid dead ends?

Every branch must have an exit, to the next block or to the end, and no branch may lead back to a question already answered.

Will a condition react to the text typed into "Other"?

No. The condition reacts to the "Other" option being chosen, not to what the respondent typed.

Will the skill change my questions as well?

No. Questions and logic are separate edits. If both change at once and something breaks, it is unclear which change caused it.

What do I need for this skill to work?

A SurveyNinja account on any plan, including Free, and an AI assistant that supports MCP and loads skills from a folder, such as Claude Code, Codex, Cursor or Gemini CLI. The skill is a plain text file; the assistant works through your API key or the access you allow when connecting.

The full skill

The SKILL.md file the assistant reads, exactly as it is in the archive.

Show the full text

Branching and routing

Logic is where surveys break silently: a condition references a question by identifier, and a branch built blind leads the respondent into a dead end with no way out.

Reply to the person in the language they write in.

The order is strict

  1. get_quiz_structure: read the current state and the question identifiers.
  2. Build the change against what actually exists.
  3. update_quiz_logic: write.
  4. The edit lands in the draft. Respondents get it only after publish_quiz, and publishing waits for the person's go-ahead.

The first step cannot be skipped. Identifiers cannot be guessed, and logic that points at a question that does not exist is rejected on save (widget_missing and similar errors).

What can be built

  • Branch on an answer. "Rated below four: ask why."
  • Show or hide a question. "Ask about delivery only if they ordered online."
  • Skip a block. "Did not use the service: do not ask about its quality."
  • Screen out. A respondent who does not fit belongs on a screenout screen, not driven to the end and cleaned up afterwards.
  • Quotas. Once a group is full, stop admitting it.
  • Branch on a link label. A value passed in the survey link (a hidden variable) can drive a condition. Hidden variables are not on every plan: if they are not available, say so and stop.

Rules people trip over

  • Every branch needs an exit, to the next block or to the end of the survey.
  • A condition on "Other" matches the option, not the text typed into it.
  • The operator must fit the question type. Greater and less than are for numbers and scales, not for text or choices.
  • Order matters: conditions are checked top to bottom and the first match wins.
  • A branch must not lead back to an already answered question, or the respondent ends up in a loop.

After the edit

Walk the route by eye: from the first question along every branch to the end. If there are more than three or four branches, describe the map in words: who ends up where. Then ask whether to publish: until then respondents still follow the old route.

What not to do

  • Do not write logic without reading the structure.
  • Do not change the question set in the same edit. When something breaks, it becomes unclear which change caused it.
  • Do not build branching where one question with options is enough.
  • Do not suggest a plan upgrade or lead to payment. If a limit is hit, state the fact and stop.
The SurveyNinja ninja on a rocket

Connect SurveyNinja to your assistant

The MCP server works on every plan, Free included. Sign up, allow access and ask your assistant to build the first survey.