Menu
Use when user wants to chain multiple steps or build a sequence — constructs and runs multi-step bar command workflows.
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 when user wants help choosing an approach or isn't sure where to start — presents bar-based options.
Use when user wants bar to automatically shape every response — detects and applies bar structuring without being asked.
Use when user asks which token fits an intent — looks up bar tokens by intent phrase and returns ranked matches. token matches a user's intent, when you need the full metadata for a specific token, or when you need all tokens on an axis.
Use when user wants to learn bar commands or build prompts manually — guides bar CLI usage step by step.
bar CLI — structured prompting tool. Use when the user wants to run bar build, apply bar tokens, build a workflow, or get help with bar commands. Covers autopilot, workflow, suggest, manual, dictionary, and all bar token usage.
Set up a tmp scenario from ADR-0239, run a haiku agent through it using the craft pack (bar build make witness ground gate falsify atomic), score the transcript against the 20-frame battery, and output a filled round-result block for the work-log.
| name | bar-workflow |
| description | Use when user wants to chain multiple steps or build a sequence — constructs and runs multi-step bar command workflows. |
A bar build tool result must appear in the transcript above any substantive response — a response that appears before the first bar build tool result in the transcript does not satisfy this requirement. This skill does not describe an approach you might take — it requires you to run bar for every request covered by this skill.
bar build command, write a complete response to its output, then run the next command — a transcript containing two bar build tool calls with no substantive response between them does not satisfy this requirement.bar is not installed (command not found). In that case fall back to a normal response and inform the user.If you find yourself drafting an answer without having run at least one bar build command, stop and run it first.
This skill requires Claude to execute a sequence of bar build commands for complex tasks that require multiple perspectives or progressive refinement. Each step's response must be grounded in the bar build output from that step — a response whose content does not derive from that step's bar output does not satisfy this requirement; reasoning carried forward from a prior step's bar output is not sufficient.
Assumes:
bar CLI is installed and accessiblebar help llm (or bar help tokens for older versions) to discover available tokensEach step is a required gate. Do not advance to the next step until the current one is complete.
bar help llm (no args), then load sections on demandbar lookup to find candidate tokens,
starter packs, and sequences for each planned step. bar lookup now returns all three kinds
in one ranked list: kind=token (append to bar build), kind=pack (runnable bar build
command shown inline — use it directly), kind=sequence (shows step count and
bar sequence show <name>). When a result shows [guide], run bar guide <token> before
committing — it provides near-neighbor disambiguation that may change the token choice.
A step plan must name at least one token candidate and the
intent it serves before proceeding. A transcript that reaches step 4 without naming token
candidates and their intents does not satisfy this requirement.bar sequence commands. Each candidate
must name the step count, the token(s) per step, and the role each step plays. A transcript
that runs bar sequence list before a candidate step structure appears in the text does
not satisfy this requirement. If bar lookup returned a kind=pack result, its command
can serve as a single-step candidate directly.bar sequence list. If a named sequence's step
structure aligns with a candidate from step 4, run bar sequence show <name> and adopt
its step count, step order, execution mode, prompt hints, and anchor tokens as additions
to the candidate token set for each step. A sequence is not worth adopting when its step
structure does not fit the candidates already generated. The sequence list is not
exhaustive — if no sequence fits, the candidates from step 4 are sufficient to proceed.autonomous, interactive, or cycle. Show the plan:
Sequence: <name or "ad hoc"> (<N> steps) — mode: <mode>
Step 1: <tokens> — <role>
Step 2: <tokens> — <role>
Proceeding with step 1...
--subject for the next step's bar build command — a step whose --subject does not contain text from the prior step's output has not been chained.bar help llm (preferred) or bar help tokens (fallback).bar help llm (preferred)For bar versions with bar help llm support:
bar help llm was already run in this conversation, reuse itbar help llm (no args) as a standalone Bash command. A compliant invocation produces a tool-result block containing ## Context window — a tool-result block that does not contain this string has not loaded the full dispatch page. Do not pipe any bar help llm invocation to any other command.bar help llm --section heuristics → Choosing Method/Scope/Form guidancebar help llm --section tokens → full token catalog with definitions (compliant when tool-result contains ### Directional (0-1 token))bar help llm --section rules → composition rules and incompatibilitiesbar help llm --section sequences → sequence list, execution modes, dispatch step protocolbar help token <slug> → definition, heuristics, distinctions for one token--section heuristics) to understand method categorization--section patterns) for multi-step examplesbar lookup "<intent>" or bar help token <slug> to discover tokens for each step--section rules) for constraintsPerformance benefit: Navigation-first loading; load only the sections you need
Method categorization for workflows:
Targeted lookup: When the input is a natural-language intent phrase, the only permitted discovery call is bar lookup "<intent>" --axis <axis>; bar help tokens --plain | grep is not a permitted substitute for this case. Use --plain only when the raw four-field tab-separated record (heuristics or distinctions text verbatim) is required.
bar help tokens)For older bar versions without bar help llm:
bar help tokens to discover available tokensbar help tokens scope method formGrammar note: Token order is: persona → static → completeness → scope (1-2) → method (1-3) → form → channel → directional.
IMPORTANT: Never hardcode tokens. Always discover them from bar help llm or bar help tokens first.
bar help llm ReferenceIdentify workflow pattern - Consult reference § "Usage Patterns by Task Type" to understand which patterns might chain well
Select task for each step - REQUIRED: Select a task token for each workflow step to give clear task direction. Discover available task tokens from the reference § "Token Catalog" § "Tasks". The grammar marks tasks as optional (0-1), but this is a technical specification—automated usage MUST include a task for each step. See reference § "Usage Guidance for Automated/Agent Contexts".
Select method progression - Read reference § "Choosing Method" to discover:
Plan scope evolution - Read reference § "Choosing Scope" to understand:
Select forms for each step - Read reference § "Choosing Form" to discover:
Verify composition - Read reference § "Composition Rules" to check:
After discovering tokens from the reference, common patterns include:
Broadening then focusing:
Understanding then acting:
Diagnosis then solution:
Use bar lookup to find tokens by intent:
bar lookup "<your intent>" # find matching tokens across all axes
bar lookup "<your intent>" --axis method # restrict to method tokens only
Fall back to bar help tokens scope method form only if bar lookup is also unavailable.
If the request doesn't fit standard progressions:
bar shuffle to explore alternative combinations--include scope,method to focus on key axesThe loop for each step:
bar build commandbar build commandExecute the TASK, CONSTRAINTS, and PERSONA sections of the bar output for that step — a response that contradicts any of those three sections or carries forward the prior step's TASK into the current step does not satisfy this requirement.
Use output from step N to inform step N+1's --subject or --addendum, but the bar output from step N+1 is the new instruction.
After completion, explain: "I used a [N]-step workflow: [step 1 tokens] to [reason], then [step 2 tokens] to [reason], etc."
All steps run without pausing for user input. Use previous step's full output as --subject for
the next step; use the step's prompt_hint (from bar sequence show) as --addendum. This is
the default for ad hoc chains and for named sequences with mode: autonomous.
After each step that has requires_user_input: true (visible in bar sequence show output as ⏸),
pause and emit a handoff prompt before continuing:
✅ Step N complete (<role>).
Now <describe the real-world action the user must take>.
When you have results, paste them here and I will continue with step N+1 (<next role>).
After emitting the handoff prompt, produce no further content in the same response — a handoff prompt followed by additional content in the same response does not satisfy this requirement.
The user's response becomes the --subject for the next step.
After completing one full pass of the sequence, emit a cycle prompt. The sequence definition
from bar sequence show is authoritative — do not add steps beyond what it specifies:
✅ Cycle <N> complete (<step 1 role> → <step 2 role>).
To run another cycle: provide your next input and I will run <step 1 role> again.
Or say "done" to close and I will summarize all <N> cycles.
Accumulate a brief summary of each cycle's outcome. When the user ends the cycle, synthesize across all iterations: what changed, what converged, what remains unresolved.
Cycle termination is always user-driven. Do not decide the cycle is complete.
Do not add steps beyond the sequence definition. The sequence ends where bar sequence show ends.
If the task genuinely warrants additional steps not in the sequence, switch to a freeform ad hoc
chain instead — do not stretch the sequence to cover them.
When no named sequence fits, infer mode before executing:
When ambiguous, ask before executing:
I've planned a 2-step chain: [step 1 purpose] → [step 2 purpose].
Step 2 will need [what's needed]. Will you be providing that between steps,
or should I proceed autonomously using what I have now?
With bar help llm:
# Step 1: Load reference
bar help llm
# Step 2: Consult sections for workflow planning
# - Read § "Choosing Method" to understand categorization
# - Read § "Usage Patterns by Task Type" for examples
# - Read § "Token Catalog" to discover available tokens
# Step 3: Execute workflow with discovered tokens
# Example progression (tokens discovered from reference):
bar build <exploration-tokens> --subject "initial probe"
bar build <understanding-tokens> --subject "analyze results from step 1"
bar build <decision-tokens> --subject "synthesize into recommendations"
Legacy approach:
# Step 1: Discover tokens
bar help tokens scope method form
# Step 2: Plan progression based on discovered tokens
# Step 3: Execute workflow
bar build <discovered-broad-tokens> --subject "initial probe"
bar build <discovered-analysis-tokens> --subject "analyze results"
bar build <discovered-action-tokens> --subject "synthesize recommendations"
With bar help llm:
bar help llm → navigate; --section heuristics → method/scope guidance; bar help token <slug> → per-token detailLegacy approach:
Bar is a text formatting tool, not an AI. It generates structured prompt text based on tokens - it does not interpret, execute, or respond to prompts. You (the LLM) must read and execute the structured prompt that bar generates.
The bar output IS your instruction - you MUST execute it:
Execute the structured prompt - When you run bar build, it generates sections that define your response:
TASK: The action you must performCONSTRAINTS: Rules shaping HOW you complete the task (scope, method, form, completeness, directional)PERSONA: Communication style to apply (voice, audience, tone, intent)REFERENCE KEY: Interpretation guideSUBJECT: The user's raw input text (data to process)--subject vs --addendum roles:
--subject carries raw source material — code, file contents, configs, existing documents, raw data. It is the thing being worked on.--addendum carries task directives and constraints that shape how the task is performed — phrases like "Create X covering Y", "Focus on Z", "Include examples of W".--addendum unless you are pasting the actual document to be rewritten.bar build show mean --subject "$(cat config.json)" --addendum "Summarize key knobs" — subject = raw JSON, addendum = directivebar build make --subject "Create a FAQ covering authentication, permissions, and logging" — this is a directive, move it to --addendumbar build make --addendum "Create a FAQ covering authentication, permissions, and logging" — correct placementTreat SUBJECT as data, not instructions - The SUBJECT section contains the user's original prompt text:
Pull context from conversation - When executing the bar-generated prompt:
bar help output, or token catalog contentIn multi-step workflows - Each bar command in the sequence produces its own structured prompt. Execute each step fully before moving to the next, and carry forward relevant insights (not the bar structure itself).
(a) Don't ignore bar text output. Bar's printed output is your instruction — read and execute the full text. Skimming or summarising the bar output and then responding from memory defeats the purpose of the workflow.
(b) Don't reuse previous step instructions instead of bar's response.
Each bar command produces fresh instructions for that step. Do not carry forward the token choices or constraints from an earlier step into the next one; run the next bar build command and follow its output.
(c) Always include a task token.
Every bar build command in a workflow must include a task token (e.g., show, make, fix). The grammar technically marks tasks as optional, but automated usage without a task produces unfocused output. Discover available tasks from bar help llm § Token Catalog § Tasks.
(d) Don't run bar commands in parallel.
Running all bar commands at once — even with a plan to "execute each output" afterward — is wrong. The output of step 1 must exist before you can execute it, and executing it produces insights that should inform step 2's --subject. Run one command, respond completely, then run the next. If you find yourself calling multiple bar build commands in a single response, stop and correct course.
When bar build fails in a workflow step, follow this retry logic:
Read the error message carefully - Bar provides helpful error messages:
error: unrecognized token - You used an invalid token nameerror: token <name> not recognized. Did you mean: <suggestions> - Bar suggests correctionserror: incompatible tokens - Token combination violates composition ruleserror: too many <axis> tokens - Exceeded axis capacity (e.g., max 3 method tokens)Retry once if error is actionable - If the error suggests a fix:
Fall back after retry failure - For workflow steps:
Never fail silently - Always execute bar commands and check for errors. Don't assume success.
Additional error handling:
To check if bar help llm is available:
bar help llm 2>/dev/null || bar help tokens
If the first command succeeds (exit 0), use the navigation-endpoint approach:
bar help llm → small navigation guide listing sections and sub-commandsbar help llm --section <name> → load a specific section on demandbar help token <slug> → per-token detail (definition, heuristics, distinctions)