<< All versions

Skill v1.0.0

currentAutomated scan
aytuncyildizli/reprompter/reprompter-goal-workflow
──Details
PublishedOctober 22, 2026 at 04:31 PM
Content Hashsha256:1897030ec06f0e91...
Git SHA95a69dd7f7ad
──Files
Files (1 file, 18.4 KB)
SKILL.md18.4 KBactive
SKILL.md · 322 lines · 18.4 KB

version: "1.0.0" name: reprompter-goal-workflow description: | RePrompter Improve output formats — compress a finished spec-XML prompt to a /goal <objective> command (Codex CLI, Claude Code v2.1.139+, Hermes), compile it to a runnable .workflow.js for Claude's dynamic Workflow tool, or deliver it to another model via headless-relay. Use when: "before /goal", "for /goal", "Codex /goal", "Claude Code /goal", "Hermes /goal", improve a goal prompt, "compile to workflow", "workflow preflight", "dynamic workflow"; or the headless-relay delivery step after a finished Single/Reverse prompt. Don't use for outcome-prose / One-Shot build briefs (delivered as-is), simple Q&A, or execution-only tasks. Outputs: /goal command card (Codex/Claude Code/Hermes); Workflow Command Card + runnable .workflow.js (Workflow preflight lane / Option H); optional relay delivery offer. Target score: spec >= 7/10.


RePrompter — /goal, Workflow script, and headless-relay delivery

Mode skill of the reprompter plugin. Entry/routing: ../reprompter/SKILL.md. Generate the spec prompt with ../reprompter-improve/SKILL.md, then apply the format below. Content below is verbatim from root SKILL.md lines 58-211 (/goal), 212-356 (Workflow script) and 1481-1558 (headless-relay). references/workflow-template.md and references/runtime/claude-workflow-runtime.md are copied alongside; Repromptverse Option H is in ../reprompter-team/references/runtime-options.md. scripts/<name> paths resolve to the bundled ../reprompter/scripts/<name> (e.g. node ../reprompter/scripts/workflow-command.js --help).
Required reading: ../reprompter/references/advanced-features.md. The always-on rules in ../reprompter/SKILL.md → "Core shared rules" (context check, uncertainty permission, WHAT not HOW) apply before any /goal compression or workflow compile.

Format: /goal command (Improve output)

When the user mentions /goal, before /goal, for /goal, "Codex /goal", "Claude Code /goal", "Hermes /goal", or asks to improve a goal prompt, run RePrompter before the goal is submitted.

This lane works on Codex CLI (any version exposing the goals feature), Claude Code CLI v2.1.139+ (the release that shipped a native /goal slash command on 2026-05-11), and Hermes Agent (persistent goals documented in the v0.13.0 / 2026.5.7 release). These runtimes accept the same /goal <objective> shape, so the compression flow is identical; only the setup check and a few runtime-specific operational notes differ. If the target runtime is Claude surfaces without /goal support, OpenClaw, Grok CLI, Gemini, or another LLM, use Improve (spec-XML) or Repromptverse instead; do not emit a /goal command for runtimes that have no /goal surface.

Detecting the target runtime

Pick the runtime once, at the start of the lane, and pass it through to the Card:

User signalRuntime
"Codex /goal", "for Codex /goal", explicit codex mentionCodex CLI
"Claude Code /goal", "/goal in Claude Code", explicit claude / claude-code mentionClaude Code CLI (≥ v2.1.139)
"Hermes /goal", "/goal in Hermes", explicit hermes / hermes-agent mentionHermes Agent
Bare "/goal" or "before /goal" with no runtime markerASK which runtime, with the three options as buttons; default to the user's primary CLI if known from session context

Process:

  1. Treat the input as Single prompt mode unless it clearly needs Repromptverse.
  2. Detect the target runtime (table above). Carry the runtime label through the rest of the lane.
  3. Render the Goal Command Card first, with Runtime populated from step 2.
  4. Infer the user's real intent from the rough prompt: desired outcome, hidden constraint, success signal, and likely risk.
  5. Build the rich expanded prompt first, using the normal RePrompter structure: goal/task, context, assumptions, requirements, constraints, execution notes, and success criteria.
  6. Compress that expanded prompt into a dense one-line goal summary. This should feel like a summary of a long XML prompt, not a slightly polished copy of the user's rough sentence. The compression rule is identical across runtimes — both Codex's alpha /goal and Claude Code's v2.1.139+ /goal consume <objective> as a single argument.
  7. Generate an exact copy-paste command: /goal <summary of expanded prompt>.
  8. Do not put the full XML or Markdown document after /goal; only the compressed summary belongs in the command.
  9. Include the expanded prompt basis after the command so the user can inspect what was compressed or send it as a follow-up normal message after the goal is set.
  10. Tell the user to run the exact /goal <summary of expanded prompt> command in the runtime chosen at step 2.
  11. Do not claim RePrompter can automatically intercept /goal; slash commands are user-invoked in both Codex and Claude Code unless the local runtime adds a separate hook.

Goal Command Card

Both runtimes shape the slash command as /goal <objective>. Render this card before the generated command:

FieldContent
Goal CommandExact one-line /goal <summary of expanded prompt> command
Compressed FromExpanded RePrompter prompt
ObjectiveOne sentence naming the reprompted intent the runtime should pursue
RuntimeCodex CLI, Claude Code CLI (≥ v2.1.139), or Hermes Agent — whichever was detected in step 2 above
Mode/goal preflight
Paste IntoCodex TUI prompt, Claude Code TUI prompt, or Hermes TUI prompt, as-is
Risk Levellow / medium / high, based on blast radius
Missing InputsUp to 3 unresolved unknowns; use documented assumptions for reasonable defaults and write none when the prompt is ready
Verification2-4 checks the agent should run while pursuing the goal
QualityBefore score → after score, with the weakest remaining dimension

Then output:

text
/goal {dense single-line summary of the expanded prompt}

Then show the expanded prompt basis:

xml
<goal>{specific outcome}</goal>
<context>
- {known repo/runtime/user context}
</context>
<assumptions>
- {reasonable default applied because this autonomous goal should not block on a low-value question}
</assumptions>
<requirements>
- {measurable requirement}
</requirements>
<constraints>
- {boundary or non-goal}
</constraints>
<execution_notes>
- Start with discovery before edits.
- Keep changes scoped and reversible.
- Run the verification checks listed in the Goal Command Card.
</execution_notes>
<success_criteria schema_version="1">
<criterion id="{kebab-case-id}" verification_method="manual">
<description>{testable pass condition}</description>
</criterion>
</success_criteria>

Runtime-specific operational notes

The compression flow is shared, but the two /goal surfaces have small behavioral differences worth surfacing in the expanded prompt's <execution_notes> block:

Claude Code CLI (≥ v2.1.139):

  • /goal sets a thread-level persistent objective that survives /resume, terminal close, and context compaction. Only one goal per session — setting a new /goal replaces the previous one.
  • After each turn a separate fast evaluator model (Haiku) checks the completion condition against the transcript. If not met, the runtime triggers another turn without user input.
  • The evaluator only judges what Claude surfaces in the transcript, so the expanded prompt should require the agent to print artifact paths, file contents, or test results — proof must be visible.
  • Pause / resume controls: /goal pause and /goal resume (handy for long-running goals interrupted by ad-hoc work).
  • Optional budget constraints (token or wall-clock) prevent runaway costs.
  • `/goal` requires hooks. When disableAllHooks or allowManagedHooksOnly is set in settings.json, /goal is unavailable. v2.1.139 silently hung in this case; v2.1.140 changed the failure mode to a clear error message but did not make /goal work under those settings. If you operate in a managed environment that blocks hooks, the /goal preflight lane cannot run on Claude Code until hooks are permitted — use Single mode in that case.

Codex CLI:

  • /goal is an experimental alpha feature gated by features.goals = true in ~/.codex/config.toml. The local alpha binary exposes Usage: /goal <objective>, ThreadGoal.objective, tokenBudget, /goal pause, /goal resume, and /goal clear.
  • Codex's /goal is invoked the same way (/goal <objective>), but config-gated — a fresh session is required after enabling.

Hermes Agent:

  • /goal sets a persistent objective that continues across turns until the runtime's goal judge considers it complete, the user pauses/clears it, or the configured turn budget is reached.
  • Goal state survives /resume, and user messages preempt the continuation loop.
  • Useful controls: /goal status, /goal pause, /goal resume, and /goal clear.
  • Default continuation budget is bounded (goals.max_turns, documented default 20), so the expanded prompt should make success criteria and verification visible.
  • Hermes supports /goal in both CLI and messaging-command surfaces; RePrompter still only emits the copy-paste command and does not intercept slash commands.

The Card's Risk Level and Verification fields apply equally to all supported /goal runtimes.

Setup check

Pick the block matching the detected runtime.

Codex CLI:

bash
npm install -g @openai/codex@latest
codex features list | grep '^goals'

If the feature exists but is disabled, configure:

toml
[features]
goals = true

Then start a fresh Codex session so the slash-command surface reloads.

Claude Code CLI:

bash
claude --version
# Expect "2.1.139" or later. If older, upgrade:
# curl -sL https://claude.ai/install.sh | bash
# or follow the install path you used originally.

No config flag is required — /goal is enabled by default once Claude Code is at v2.1.139 or later. However, /goal depends on Claude Code's hooks layer: if disableAllHooks or allowManagedHooksOnly is set in ~/.claude/settings.json, the command is unavailable on any version. v2.1.139 silently hung in that case; v2.1.140 surfaces a clear error message instead. Upgrading does not re-enable /goal under hook-blocking settings — permitting hooks is the only way to use /goal on Claude Code. Managed environments that block hooks should use Single mode for goal-shaped work.

Hermes Agent:

bash
hermes --version
# Expect a release with persistent goals support (v0.13.0 / 2026.5.7 or later).

No feature flag is required for normal /goal use. Optional tuning lives in Hermes config:

toml
[goals]
max_turns = 20

Format: Workflow script (Improve output)

When the user says "compile to workflow", "build a workflow script", "workflow preflight", "make a workflow", "run via workflow tool", or "dynamic workflow", reprompt the task and compile it into a runnable Claude dynamic Workflow script. This is the execution-compilation sibling of the /goal preflight lane: RePrompter builds the expanded prompt first, then emits a .workflow.js the user runs via the Workflow tool — RePrompter does not run it.

This lane is the same surface as Repromptverse Option H; use this lane when the user wants the compiled script directly, and Option H when Phase 3 auto-picks the Workflow tool during a Repromptverse run.

Compatibility

Single Claude-native surface: requires the Workflow tool in the current toolset. There is no /goal-style command — the output is a Workflow({ scriptPath, args }) invocation. Other runtimes (Codex, Grok, Hermes, OpenClaw) use their own Repromptverse options (D/F/G/C) and the /goal preflight lane instead.

Runtime detection

SignalRuntime
A tool named Workflow is present in the current toolsetClaude dynamic Workflow tool — proceed with this lane
No Workflow toolFall back to Repromptverse (Option B/A/etc.) or /goal preflight

Process

  1. Treat the input as a team task. Run routeIntent — a workflow-lane trigger returns mode: "workflow".
  2. Infer the real intent and build the rich expanded prompt (the XML basis below) with all eight base tags + <assumptions> + <success_criteria>. Because Workflow preflight is autonomous execution, skip clarification questions when a reasonable default exists and document the default in <assumptions>.
  3. Reprompt one prompt per role (each owns ONE domain, no overlap), exactly as Repromptverse Phase 2.
  4. Compile to a .workflow.js via scripts/workflow-command.js (buildWorkflowCommand): pure-literal meta, schema-validated agent() returns, parallel()/pipeline() per the H1/H2 heuristic, runId/taskname from args, model omitted, filter(Boolean), bounded delta-retry (max 2/role).
  5. Render the Workflow Command Card first, then the emitted script, then the expanded-prompt basis.
  6. High-risk forbidden surfaces (prod/auth/secret/...) block emission — set blocked: true, script: null. There is no in-tool override; rescope the task (remove the high-risk surface) to compile a script. Same block-gate as /goal.
  7. Tell the user to run Workflow({ scriptPath, args }); resume an interrupted run with resumeFromRunId (cached agent() prefix short-circuits).

Workflow Command Card

FieldContent
Workflow CommandExact Workflow({ scriptPath, args: { taskname, runId } }) invocation
Compiled FromExpanded RePrompter prompt
ObjectiveOne sentence naming the reprompted intent
RuntimeClaude dynamic Workflow tool
ModeWorkflow preflight
Paste IntoWorkflow tool (scriptPath + args), as-is
Script Path/tmp/reprompter-workflow/rpt-{taskname}.workflow.js
Execution Patternparallel fan-out + bounded delta-retry (ultracode: + adversarial verify + completeness critic)
Budgetdirective total / inherit / none
Risk Levellow / medium / high
Missing InputsUp to 3 unresolved unknowns; use documented assumptions for reasonable defaults, or none
Verification2-4 checks the run should surface (per-role scores, missing roles)
QualityBefore score → after score

Then output the emitted script:

js
export const meta = {
name: "rpt-{taskname}",
description: "{one-line objective}",
phases: [
{ title: "Plan" },
{ title: "Execute" },
{ title: "Evaluate" },
],
}
const taskname = (args && args.taskname) || "{taskname}" // bare fallback == command args; only meta.name is prefixed (resume id stability)
const runId = (args && args.runId) || taskname
const FINDINGS_SCHEMA = {
type: "object",
additionalProperties: false,
required: ["role", "findings", "self_score"],
properties: {
role: { type: "string" },
findings: { type: "array", items: { type: "string" } },
self_score: { type: "integer", minimum: 1, maximum: 10 },
},
}
const AGENTS = [ /* one reprompted prompt per role; model omitted */ ]
phase("Plan")
log(`Workflow ${runId}: dispatching ${AGENTS.length} reprompted agents`)
phase("Execute")
const results = (await parallel(
AGENTS.map((a) => () => agent(a.prompt, { label: a.label, phase: "Execute", schema: FINDINGS_SCHEMA }))
)).filter(Boolean)
phase("Evaluate")
const ACCEPT = 8
const final = []
for (const r of results) {
let current = r, attempts = 0
while (current && current.self_score < ACCEPT && attempts < 2) {
attempts += 1
current = await agent(`Previous ${current.role} attempt scored ${current.self_score}/10 (need ${ACCEPT}). Fix the gaps; return the improved structured result.`,
{ label: `retry:${current.role}`, phase: "Evaluate", schema: FINDINGS_SCHEMA })
}
if (current) final.push(current)
}
return {
schema_version: "reprompter.workflow_outcome.v1",
runId, taskname,
results: final,
missing: AGENTS.length - final.length,
scores: final.map((f) => ({ role: f.role, score: f.self_score })),
}

Then the expanded-prompt basis (the reprompted XML that authors the workflow):

xml
<role>{Workflow architect for this domain}</role>
<context>
- Raw operator request, target = Claude dynamic Workflow tool, route mode/profile
</context>
<assumptions>
- {Documented default used instead of blocking workflow compilation on a low-value question}
</assumptions>
<task>{Compile the request into a runnable .workflow.js fan-out.}</task>
<motivation>{Why this matters}</motivation>
<requirements>
- One reprompted agent per role; schema returns are the source of truth.
- meta pure-literal; runId/taskname from args; bounded retry.
</requirements>
<constraints>
- No wall-clock/randomness in-script; model omitted; filter(Boolean).
- High-risk forbidden surfaces block emission (no in-tool override; rescope to proceed).
</constraints>
<output_format>A .workflow.js script + a Workflow Command Card.</output_format>
<success_criteria schema_version="1">
<criterion id="schema-returns-source-of-truth" verification_method="manual">
<description>In-run data flows through schema-validated agent() returns; tmp files are never read back as a handoff.</description>
</criterion>
</success_criteria>

Schema-truth + parent-written mirror

The emitted script returns a reprompter.workflow_outcome.v1 payload; it never reads /tmp/rpt-{taskname}-{role}.md back. The parent writes those tmp artifacts from the returned objects after the run completes, so the existing Status Line count, Phase-4 evaluation, and outcome-record.js --role flywheel path keep working unchanged — and the throwing wall-clock/randomness calls stay out of the sandbox.

Setup check

Confirm the Workflow tool is present in the current toolset (Claude dynamic Workflow runtime). If absent, use Repromptverse Option B/A or the /goal preflight lane instead.

Compile with the workflow compiler (scripts/workflow-command.js) on the rough task with an --out-dir: it writes workflow-command.json, the runnable rpt-{taskname}.workflow.js, workflow-command-card.json, and reprompter-expanded-prompt.md. Add --ultracode / --no-ultracode to force the emission tier.

See references/workflow-template.md and references/runtime/claude-workflow-runtime.md for the full template and runtime contract.


Deliver via headless-relay (post-output step)

The full headless-relay delivery step (offer once after a finished Single/Reverse prompt; relay to another model) lives in references/headless-relay.md. Read it whenever a prompt is finished and relay delivery may be offered.

All versions