quest-design

name	quest-design
description	Confirm quest intent before creating a new quest or refining an idea into a worker-ready quest. Invoke when a user asks to create, file, refine, scope, or prepare a quest, or before materially rewriting quest title/description/tags as part of refinement. Do not use for routine quest feedback, claiming, completion, verification checks, or other bookkeeping.

Quest Design

Use this skill before creating a quest or refining an idea quest into a worker-ready quest.

The goal is to give the user one concise chance to correct the agent's understanding before quest text is written. When the user clearly wants a quest created and dispatched, combine this with /leader-dispatch: use the compact proposal shape below so one confirmation can approve quest text, Journey, and dispatch plan. After approval, the leader must write the approved Journey to the board before or with dispatch. After successful quest creation or refinement, include a lightweight non-blocking thread reminder when prior discussion may belong to the new quest thread: Thread reminder: attach any prior messages that clearly belong to this quest to q-N with takode thread attach.

Before proposing quest text, explicitly check whether the new or refined quest is a true follow-up to earlier work. Use explicit follow-up relationships for true follow-ups, bug fixes, successors, redesigns, or user-approved next quests that came from prior findings. Leave incidental mentions, loose background context, copied examples, and broad references to auto-detected backlinks instead.

When a follow-up relationship is relevant, include it in the approval surface as a dedicated line such as Relationship: follow-up of [q-1023](quest:q-1023). After the user confirms, persist it when creating the quest with quest create ... --follow-up-of q-1023, or when refining an existing quest with quest edit q-N --follow-up-of q-1023. If a relationship was recorded by mistake, use quest edit q-N --clear-follow-up-of.

Scope

Use /quest-design before:

• quest create
• refining an idea quest with quest edit or quest transition --status refined
• materially rewriting title, description, or tags as part of quest refinement

Do not use /quest-design for routine quest operations:

• quest show, quest list, quest grep, quest history, or quest tags
• quest claim
• adding feedback to an existing quest
• addressing feedback
• completing a quest or checking User review checks
• verification inbox moves
• board updates
• lifecycle/status bookkeeping after an already-approved workflow

Required Response

Do not write the quest yet. First respond with the narrowest confirmation surface that can safely move the request forward. Treat the visible chat proposal like a TLDR for approval: it should give the user what they need to approve, correct, or choose, not make them read the worker-facing quest body. Include concise goal/Journey/scheduling information and add detail only when it resolves ambiguity, states a user-visible tradeoff, asks for confirmation of a risky assumption, or changes the approval decision. Put detailed grounding, evidence, acceptance bullets, non-goals, fallback mechanics, and worker-facing context in the quest record instead. When the confirmation asks the user to choose, include the complete decision context in the thread before any needs-input notification; notification summaries, notification UI options, and --suggest choices are only attention/reply affordances.

Best case: if the user clearly wants quest creation plus immediate dispatch and the request is already understood, include both:

• the proposed quest draft: title, Goal / Acceptance, tags when useful, and only optional sections that add non-overlapping approval value
• the proposed explicit relationship, when relevant: Relationship: follow-up of [q-N](quest:q-N)
• the proposed Quest Journey/scheduling draft from /leader-dispatch: phase sequence, concise non-standard phase reasons when useful, worker choice or fresh-spawn intent, and dispatch/queueing plan

One user confirmation can approve both the quest draft and the Journey/scheduling plan. Do not add a separate confirmation round just to restate understanding, and do not require a separate board-presentation approval ceremony.

Use one source of truth for the requested work. Prefer a single Goal / Acceptance section that serves as both your understanding and the proposed quest's acceptance criteria. If you already wrote a concise understanding, either make that text the Goal / Acceptance section or replace it with one expanded Goal / Acceptance; do not restate the same work again as a separate quest description, Scope paragraph, The worker should list, default Expected Output / Acceptance section, or full quest-body paste.

Use the compact proposal shape when it fits:

• Proposed Quest
• Goal / Acceptance
• optional Context / Evidence
• optional Out Of Scope
• optional Open Questions
• Journey, only when dispatch or Journey approval is in scope
• Scheduling, only when dispatch or queueing is in scope

Treat that shape as a menu, not a form to fill out. Do not reproduce every heading or explanatory bullet when the decision can be made from a shorter packet. Default to a short approval packet, but preserve judgment: expand only for a real relationship, open question, unusual phase reason, user-visible boundary, queueing/capacity choice, or another fact the user needs to approve or correct.

Add separate sections only when they carry non-overlapping approval information, such as Relationship, Context / Evidence, Out Of Scope, Open Questions, Invariants / Must Preserve, Journey, non-standard phase notes, and Scheduling. Open questions and assumptions are optional and should only cover decisions not already implied by Goal / Acceptance or the user's stated facts. Omit optional sections entirely when they add no new approval value. Detailed worker grounding belongs in the quest record, not in the chat approval surface.

For Journey notes, omit standard tracked-code phase notes by default: alignment, implement, code-review, and port only need notes for unusual phase-specific work. Explain non-standard phases concisely: why the phase is needed and what evidence, scenario, outcome, or durable state it covers.

When a proposal includes multiple non-standard phase notes, format them as bullets keyed by phase, for example - Execute: ... and - Outcome Review: .... Keep the phase list, phase notes, and scheduling plan visually separate so the approval surface is easy to scan before the user confirms.

Clarification-needed case: ask the material questions using the quest framing below. After the user clarifies and no major ambiguity remains, the next response should include both the proposed quest draft and proposed Journey/scheduling draft together. More than two confirmation rounds should happen only when new, genuine ambiguity remains.

When you only need quest text approval and dispatch is not in scope, use the same compact spirit and omit Journey and Scheduling:

Proposed Quest

• Title, when ready.
• Tags, when useful.
• Relationship, when relevant.

Goal / Acceptance

• Intended goal and acceptance checks for the quest.
• Clean bullets when the request has multiple parts.

Context / Evidence

• Optional. Include only material prior quests, source examples, screenshots, logs, user reports, or artifact paths.

Out Of Scope

• Optional. Include only exclusions that prevent likely misunderstanding.

Open Questions

• Ask only the highest-leverage questions that could materially change the quest.
• Omit this section entirely when nothing remains unclear.

End with:

---

Please confirm or correct.

Waiting

After sending the confirmation, stop and wait for the user.

If you are acting as a leader/orchestrator and the confirmation asks a blocking question, send the confirmation as a normal leader response with the correct first-line thread marker ([thread:main] or [thread:q-N]), then run takode notify needs-input "<brief summary>" so the user notices. The confirmation text must be self-contained enough to answer, including options and tradeoffs when relevant. For obvious short choices, add one to three --suggest <answer> flags, but never use suggestions instead of the written confirmation context. Do not use Thread Waiting or takode notify waiting as the only representation of this user wait. Normal worker and reviewer sessions should use ordinary chat.

If you are creating another approval surface while an older prompt is still unresolved, do not reuse or rely on the older notification. New blocking prompt -> new takode notify needs-input; after creating it, link the board row with --wait-for-input when applicable. Thread Waiting is only for non-user waits and is never a substitute for the notification.

If the user corrects the understanding and ambiguity remains, repeat the same structure with the updated understanding. If the user clarifies enough to remove the ambiguity, draft the quest and Journey/scheduling plan together instead of sending a separate restated-understanding-only round.

Only after the user confirms should you create or refine the quest. When you create or refine the quest, keep subsequent quest-specific activity in [thread:q-N] and attach clearly quest-specific prior discussion with takode thread attach.