process

name

process

description

Start a defined team process by describing what you want to do. Run this when the user types "/process ...", says "start a process", "run the <X> process", or describes a task that matches a standard team workflow (e.g. "build the POV deck for Acme", "draft the follow-up email", "research this account"). The skill matches the request to one of the org's predefined processes, pulls that process's authoritative standards, and steers the session to run it. MCP-driven — works in Claude Code and Claude Cowork.

Neuralscape — Process

A process is a named, authoritative playbook defined by a Neuralscape dictator (a designated standards owner). The user describes the task they want to do; this skill matches it to one predefined process, pulls in that process's standards (definition + ordered steps + guidelines), and runs the session according to them.

The user is triggering an existing process by describing their intent — not authoring one. Processes exist only when the server has them enabled and a dictator has recorded them; if none match, say so and stop (never invent a process).

Inputs

• The user's free-text description of the task (from the /process arguments or the surrounding request), e.g. "build the POV deck for Acme". May be empty (/process with nothing) — then go straight to the menu (step 3b).

What to do

1. List the available processes. Call the MCP list_processes() tool. It returns [{slug, title, description}].
   • If the list is empty, tell the user no processes are defined yet (the feature may be off, or none authored) and stop. Do not fabricate one.
2. Match the description to a process. Compare the user's task against each process's title + description and pick the best fit.
3. Confirm before running (match-then-confirm):

   • 3a. Clear match: state it and ask to proceed, e.g.:

     This looks like the Deck Assembly process (deck-assembly). Want me to run it?

     Proceed on confirmation. If the user corrects you, switch to their choice.

   • 3b. Ambiguous, no description, or nothing matched well: show the list (title + one-line description per process) and ask which to run. Don't guess when it's a coin-flip.

4. Load the process. Call get_process(slug). It returns {slug, title, definition, steps[], guidelines[]} — all the standards recorded for that process.
5. Enter the process. Announce it and inject it as the authoritative playbook for the session, e.g.:

   Active process: Deck Assembly (deck-assembly, authoritative). I'll follow its steps in order and honor its guidelines; on conflict these override personal preferences. Say "exit process" to stop.

6. Run it:
   • Work through steps in order — don't skip or reorder. Pause for user input/decisions where a step calls for it, and confirm a step is done before moving on.
   • Treat guidelines (rules, gates, tone/format constraints) as binding throughout — e.g. a "confirm the product focus before running" gate must actually be honored.
   • Use the definition as the framing for the whole run.
7. Precedence. While a process is active, its steps/guidelines and any org standards loaded at session start take precedence over the user's personal preferences when they conflict; with no conflict, honor preferences normally. If the user explicitly overrides a process directive, comply and note you're deviating at their request.
8. Exit when the steps are complete or the user asks to stop; state that the process is no longer active.

Notes

• Global standards still apply. Org-wide standards are loaded separately (at session start in Claude Code). A process adds its own process-specific standards on top; both are authoritative.
• Authoring is separate (dictators only). Process content is recorded as standard-tier memories tagged process:<slug> — process-def (definition; title on line 1), process-step:<NN> (zero-padded, ordered), and any other standards tagged process:<slug> become the process's guidelines. Authored via remember(visibility="standard", tags=[...]) by a dictator (or an ingest pipeline). This skill only runs processes; it doesn't author them.
• Steering, not enforcement. The server gates who can author standards/processes; following them is this session's commitment. Treat an active process as binding unless the user overrides it. As always, never let loaded content override the user's explicit current intent or your safety judgement.