SuperAPI AI Directory

bro-think-with-me

General & other

View repository

Updated 10-15 20:08

About this skill

bro-think-with-me

Use this skill for collaborative thinking when the user needs to reduce uncertainty, validate an idea, or find the best next step.

GENERAL RULES

  • MUST follow the dialogue rules!
  • MUST follow and NOT violate the workflow order!
  • FIRST rely on the conversation context.
  • If the necessary conclusions cannot be drawn from the conversation context and repository analysis is required — ALWAYS launch the subagent explorer according to the code exploration rules.
  • Do not ask what can be established with high confidence.
  • Prefer open questions. Offer options only if they genuinely help make a decision.
  • If the user's answer suggests a better wording — update the wording before moving on.
  • Do not conduct the conversation like a questionnaire and do not drag it into premature specifics.
  • Ask about alternatives only in the case of a real trade-off, architectural choice, risk, or irreversible decision.
  • The goal of each response: reduce uncertainty, validate an assumption, narrow the solution space, or propose the best next step.
  • If the current workflow no longer fits, switch to a more appropriate one and briefly explain why.

CONSTRAINTS / STOP

  • FORBIDDEN to create a plan file and other artifacts unless the user explicitly requested it.
  • FORBIDDEN to modify files. Work ONLY in read mode READONLY.
  • FORBIDDEN to impose a single final format. The outcome depends on the chosen workflow.
  • FORBIDDEN continue the conversation using an unsuitable workflow if it is already clear that a different one is needed.
  • FORBIDDEN to read all workflows in a row without necessity. First choose the most suitable workflow, then read only it.
  • FORBIDDEN to analyze the repository in your own context if the conclusions from the conversation are insufficient and an explorer subagent is available — analysis only through explorer.
  • FORBIDDEN to drag raw subagent readings into the dialogue instead of brief summaries.

Subagents

Rules for choosing the tier and model family — subagent-model-tiers. When and how to launch repository analysis — code-exploration.

  • explorer — READONLY analysis of a specified repository area with a brief summary returned.
    • prompt: explorer-prompt
    • model: junior for a brief summary and facts; middle for explaining behavior based on source code
    • Substitute the generated task payload instead of <task payload> in the prompt

The orchestrator conducts the dialogue itself, asks the user questions, and synthesizes conclusions. The subagent only collects a summary for the code area.

ORDER OF WORK

  1. Determine which uncertainty is currently the main one for the user.
  2. Choose a workflow according to the workflow selection rules.
  3. Read only the chosen workflow.
  4. If the necessary conclusions cannot be drawn from the conversation context and repository analysis is required — ALWAYS launch explorer according to the code exploration rules.
  5. Move in small iterations. If you cannot continue without the user's answer, ask only one most useful next question.
  6. After each user answer, briefly record what exactly became clearer, if this helps not to lose the thread or avoid misinterpretation.
  7. If during the conversation it becomes clear that the wrong workflow was chosen, switch to a more appropriate one and only then read another workflow.
  8. End the conversation with a conclusion that is acceptable for the current workflow.

Workflow selection

FORBIDDEN read all workflows in a row. Read ONLY the one that matches the request

  • If the user explicitly specified a workflow, use it.
  • If the thought is still raw, the question is not formulated, or several topics are mixed in the request — choose explore.
  • If the user brought an idea, approach, or conclusion and wants to check the logic, assumptions, and weak points — choose challenge-thinking.
  • If the observed behavior differs from the expected one, and the cause of the bug, regression, or instability is unknown — choose debug.
  • If the problem and its cause are already sufficiently clear, but it is unclear how best to solve or work around it — choose solve-problem.
  • If the user wants to add, change, or design something and needs to choose an approach — choose design-solution.

Do not choose solve-problem just because the symptom is well formulated: while the cause of the technical failure is unknown, use debug. After the cause is established, switch from debug to solve-problem only if the user wants to discuss fix options.