Menu
Create a new ticket from scratch — intake backend first, mirror downstream after
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Capability discovery — the canonical answer to 'what can you do?' and 'what do I say to ...?'
Close skill — draft resolution comment, sync backends, redirect to next task
Start skill — begin task with optional backend sync
End-of-day wrap-up skill — daily summary and status update
Morning brief skill — prioritized daily summary
Reconcile skill — detect wiki/backend drift and let the User resolve it via four moves
| name | new-ticket |
| description | Create a new ticket from scratch — intake backend first, mirror downstream after |
| risk_class | hard |
| confirm_action | new-ticket.create |
Create a brand-new ticket for something just found or thought of (bug, small
feature, improvement, admin task). Unlike /push, which lifts an existing
wiki page into an external backend, /new-ticket originates the work — it
creates the intake-side ticket, ingests the resulting page into the wiki,
and optionally mirrors to a downstream backend.
Trigger on any of:
/new-ticket/new-ticket "<title> — <one-line description>"$ARGUMENTS — optional seed text. If present and substantive, parse into a
title and description. If empty or too terse, gather them in Step 2.
Run via Bash:
rubber-ducky workspace intake show --json
The response either has a populated intake block (proceed to Step 2) or
null (run the first-run setup below).
First-run setup (one question at a time, with progress markers):
Run rubber-ducky backend list --json to see configured backends, so the
questions can offer real choices. If no backends are configured, stop:
"No backends are configured yet. Run /connect <name> first — I need at
least one to know where new tickets should land."
Then ask, one question per turn, prefixing each with its position so the user knows the commitment up front:
Question 1 of 3. Where should new tickets originate? Pick one of your configured backends: .
Question 2 of 3. What's the project / board / repo identifier in where intake lands? (e.g., an Asana project GID, a Jira project key, a GitHub
owner/repo.)
Question 3 of 3. Should new tickets also be mirrored into a second backend after intake (e.g., Asana → Jira)? If yes, name the backend; if not, say "no". (If yes, I'll ask for the mirror project in a follow-up.)
If the user answers "yes" to Q3, ask one more turn:
Follow-up. What's the project / repo identifier in ?
Persist after each answer so a mid-flow abort doesn't lose progress:
rubber-ducky workspace intake set --primary-backend <name> --primary-project <id>
rubber-ducky workspace intake set --mirror-to <name> --mirror-project <id>
(Or --clear-mirror if the user later wants to drop mirroring.)
Once the intake block is populated, proceed to Step 2.
If $ARGUMENTS is substantive, parse it into a title and a description and
confirm the title back to the user: "Title: <title>. OK?" Apply any
edits.
Otherwise, prompt one question at a time:
Question 1 of 2. What's the title? (Keep it tight — a TODO-style line, not a sentence.)
Question 2 of 2. Quick description — what's the bug or the work? (One or two lines is fine; I'll expand as needed in the draft.)
If the workspace has tag conventions or label sets the user routinely picks
between (read wiki/references/ and UBIQUITOUS_LANGUAGE.md for any
"controlled vocabulary" hints), ask one short follow-up to cover them.
Otherwise skip. Don't interview — every additional question is friction the
user has to repeat for every new ticket.
Invoke the ticket-writer sub-agent against intake.primary_backend:
Agent({
subagent_type: "ticket-writer",
prompt: "Draft a <primary_backend> ticket. Source: inline self-authored. Title: <title>. Body: <description>. Created via /new-ticket on <today>."
})
Walk the user through any NEEDS_INPUT placeholders the agent emits, one at
a time. The "ship it" shortcut accepts all defaults.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
NEW TICKET PREVIEW — <primary_backend>
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Target: <primary_backend> / <primary_project>
Assignee: me
Status: <initial status>
Title: <title>
Description:
------------
<body>
------------
After creation:
→ Ingest as wiki task page
→ Offer to mirror to <mirror_to> (if configured)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Confirm? (yes / no / edit)
Nothing is written before the user says yes.
/new-ticket reverses the historical "create externally first, ingest
second" flow: instead it creates the wiki task page locally and then
calls rubber-ducky push to externalize it. This means the external
create rides on the existing push gate — one CLI-enforced primitive,
zero new write paths.
Create the wiki page locally (no external write yet):
rubber-ducky page create task "<title>"
The page lands at wiki/tasks/<slug>.md with the description and
any tags / priority you elicited in Steps 2–3 set in frontmatter.
Issue a confirm-token for the push. The descriptor is
<primary_backend>.push so per-action overrides in
settings.confirm.<primary_backend>.push apply:
TOKEN=$(rubber-ducky --no-json confirm request \
--action <primary_backend>.push \
--preview "$PREVIEW_TEXT")
Push — consumes the token, calls the backend, stamps
<primary_backend>_ref / pushed / updated, audit-logs:
rubber-ducky --json push wiki/tasks/<slug>.md \
--backend <primary_backend> \
--confirm-token "$TOKEN"
A missing / expired / action-mismatched token causes push to exit
non-zero before any external call.
Capture the new ticket's identifier and URL from push's JSON output
(ref, url).
Backends with intake-form automations: some workspaces have
Smartsheet or similar tooling that rewrites fields after creation
(status reset, identifier assignment). If the user's intake involves
that, expect a brief delay and a possible field override; mention it
in the confirmation summary so the user isn't surprised, and offer a
follow-up update_tasks call manually if the override is the wrong
shape.
If intake.mirror_to is set in workspace.md, ask:
Mirror to <mirror_to> now? (yes / no / later)
/push <wiki-page-path> and let the push flow handle
preview, confirmation, execute, and back-link.rubber-ducky asap add "Mirror [[<wiki page>]] to <mirror_to>"
If mirror_to is unset, skip this step entirely.
push already appended its own [write-back] push → ... line. Add a
summary that names this as a /new-ticket invocation so future
investigation can find it via grep:
rubber-ducky log append "[new-ticket] <primary_backend> (<ref>) — created via /new-ticket; mirror: <yes/no/later/none>"
Read active_task on today's daily page; if set, end with a one-liner
pointing back. Otherwise omit.
<primary>-first. Want me to create
there and mirror after, or override?" If they override, honor it and log
the exception in log.md./new-ticket reads intake config fresh every
time; if the user wants to reconfigure intake, point them at
rubber-ducky workspace intake set (or /connect <backend> for credential
changes).A short confirmation line naming the created ticket, the wiki page path, and the mirror outcome. Optional one-line redirect to the active task.