| name | new-process |
| description | Scaffold a new banking process in the wiki. Ask the user for the process name, draft a one-line description, a slug and an ID abbreviation for them to confirm, then create the process as a single strongly-typed JSON document with an empty overview. Use this whenever the user wants to create or set up a new process, start a process from scratch, or add a process to the wiki — even if they don't explicitly say "new-process". |
New Process
You scaffold a brand-new banking process in the Processminer wiki — its single
strongly-typed JSON document at wiki/processes/<slug>.json, carrying the
process meta and an empty overview. You capture no content: no steps, no
overview prose, no elements. When you finish, the process appears in the app
empty, ready for qer-session or a specialist skill to fill in.
Keep this fast: name → confirm → document created. Nothing more.
What you create
wiki/processes/<slug>.json one strongly-typed JSON document:
meta process identity (id, slug, title, …)
content the overview — created empty
(typed element arrays are added later, as
specialists author elements via createElement)
The flow
Step 1 — Name. Ask the user for the process name. That is the only thing
you ask for. (If the user's opening message already gives both a name and a
one-line description of the process, skip the question and go straight to
Step 2 with that description as your draft — don't ask for what you already
have.)
Step 2 — Derive, draft, confirm.
-
Call deriveProcessMeta({ name }) with the process name. It returns
JSON with a deterministic slug (kebab-case), a guaranteed-valid
PROC abbreviation (always 2–6 uppercase letters — you never have to
form or fix it), a slugTaken flag, a list of non-colliding
suggestedSlugs, and a confirmTemplate string. Use exactly what
it returns — never invent or "correct" the slug or abbreviation.
If slugTaken is true, a process with this slug already exists. Do
not confirm or scaffold — tell the user plainly that the name collides with
an existing process, offer the suggestedSlugs (or a different name), and
return to Step 1.
-
Draft a one-line description — one plain sentence on what the process
does. This is the one judgement item; the slug and abbreviation are not.
-
Present the confirmation by taking the returned confirmTemplate
verbatim and replacing {{description}} with your one-line description.
Relay it exactly — do not reformat it into a table or restyle the labels.
It renders as:
- **Description:** <the one-line description>
- **Slug:** `<slug>`
- **Abbreviation:** `<PROC>`
Then offer exactly these three choices — never just two.
"""
[Y] Yes — accept · [E] Edit — I have corrections · [R] Rewrite — redo the description
"""
- [Y] — confirmed; go to Step 3.
- [E] — the SME gives specific corrections; apply them, show the bullets
again, ask again.
- [R] — the description missed the mark; redraft it from scratch with
one or two sharper questions, then re-present.
Loop until the user accepts. Create nothing until they confirm.
Step 3 — Scaffold. Once the user confirms, use the scaffolder. It creates the files deterministically — do not create
these files by hand:
use the scaffoldProcess({ slug, PROC, title, description }) tool
The tool creates the process document wiki/processes/<slug>.json with the
process meta (identity) and an empty overview (content) — the overview
fields are left blank (qer-session's OVERVIEW step fills them later). It validates the slug and
abbreviation and refuses to overwrite an existing process. On success it returns
a closing field — the canonical success message (see Step 4). If it exits
with an error, relay that error to the user and stop.
Step 4 — Done. On success, say nothing about the JSON document or paths —
relay the tool's returned closing field verbatim as your entire
message. Do not paraphrase it, add to it, or mention any other part of the
tool's output. (For reference, it reads:)
"""
{process} has been successfully created, and the app has switched to it.
The process is empty — every section is ready to be filled. The fastest way to start is to upload a process document: click ⬆ Upload document in the top bar and drag in a PDF, Word or Markdown file. I'll review it, summarise it, and extract its content into the wiki.
Prefer to talk it through instead? Just ask me to run a documentation session and I'll guide you through it question by question.
"""
Scope
You only scaffold. You do not capture process content, overview prose, or any
elements — that is the job of qer-session and the specialist skills.
