Own how your organization uses AI.

Before you adopt anything, you want to know what it looks like at 2am. This walkthrough takes you through the operator CLI the same way an on-call engineer would: check service health, inspect the database, audit scheduled work, tail the logs, then review config. Every command is read-only, every answer is a single CLI call, and nothing here needs a dashboard.

1. Check service health

   Runs infra services status and then --detailed to show the agent and MCP server processes the platform supervises, with pids, ports, and health. This is the first thing you reach for when something feels wrong.

   What you see You see the systemprompt MCP server running as a supervised process, plus any configured agents, with health and lifecycle hooks for start/stop/restart/cleanup.

   Run it — 01-services.sh

   ./demo/infrastructure/01-services.sh Copy path

   Or run the individual commands below:

   systemprompt infra services status

   Copy

   systemprompt infra services status --detailed

   Copy

2. Inspect the Postgres schema

   Walks the database from the outside in: connection info, table list, schema of governance_decisions, indexes, row counts, size, a live read-only SQL query, migration status, and schema validation. Nothing is hidden behind an ORM.

   What you see You see the real schema, a live SELECT against governance_decisions grouped by decision, and a passing migration and schema validation check.

   Run it — 02-database.sh

   ./demo/infrastructure/02-database.sh Copy path

   Or run the individual commands below:

   systemprompt infra db info

   Copy

   systemprompt infra db status

   Copy

   systemprompt infra db tables

   Copy

   systemprompt infra db describe governance_decisions

   Copy

   systemprompt infra db indexes

   Copy

   systemprompt infra db count governance_decisions

   Copy

3. Audit scheduled background jobs

   Lists every registered background job, shows one job's schedule and config, then prints execution history. This is how you answer "what runs on its own, and did the last run succeed?"

   What you see You see the registered jobs, a specific job's cron schedule and configuration, and the last N executions with status and duration.

   Run it — 03-jobs.sh

   ./demo/infrastructure/03-jobs.sh Copy path

   Or run the individual commands below:

   systemprompt infra jobs list

   Copy

   systemprompt infra jobs show "$JOB_NAME"

   Copy

   systemprompt infra jobs history

   Copy

4. Tail logs, traces, and AI requests

   Runs infra logs view, summary, search, then trace list, request list, and tools list. Application logs, per-request traces, AI call logs, and MCP tool executions are all first-class and queryable from one CLI.

   What you see You see recent log lines, a level-aggregated summary, keyword search, execution traces, AI request records, and MCP tool call history — enough to debug any failure end-to-end.

   Run it — 04-logs.sh

   ./demo/infrastructure/04-logs.sh Copy path

   Or run the individual commands below:

   systemprompt infra logs view --since 1h --limit 10

   Copy

   systemprompt infra logs summary --since 24h

   Copy

   systemprompt infra logs search "extension" --since 24h

   Copy

   systemprompt infra logs trace list --limit 5

   Copy

   systemprompt infra logs request list --limit 5

   Copy

   systemprompt infra logs tools list --limit 5

   Copy

5. Review runtime configuration

   Shows the merged config, the files it came from, validation status, runtime values, filesystem paths, and the active AI provider. Config is files on disk you can diff, not a mystery service.

   What you see You see the effective configuration, the source files that produced it, a green validation check, and the current AI provider binding.

   Run it — 05-config.sh

   ./demo/infrastructure/05-config.sh Copy path

   Or run the individual commands below:

   systemprompt admin config show

   Copy

   systemprompt admin config list

   Copy

   systemprompt admin config validate

   Copy

   systemprompt admin config runtime show

   Copy

   systemprompt admin config paths show

   Copy

   systemprompt admin config provider list

   Copy

Staff engineers want to know what actually happens when an agent goes off-script. This walkthrough fires real PreToolUse hooks against the governance endpoint: a clean admin call passes all three rules, a user-scope agent gets denied at the scope and blocklist layers, and plaintext AWS keys, GitHub PATs, and PEM private keys are blocked before they reach a tool. Every decision lands in an audit table you can query, capped by rate limits you can inspect and hooks you can extend.

1. Walk the full hook → allow → execute path

   POSTs a PreToolUse hook for developer_agent calling mcp__systemprompt__systemprompt — the CLI-wrapper tool exposed by the systemprompt MCP server — sees governance return allow, then actually invokes the tool via the CLI with {command: "admin agents list"} so you watch the same request land in the real agent runtime. This is the Claude Code hook workflow end to end.

   What you see An allow response from /hooks/govern, a live agents listing returned by the systemprompt MCP server, and a matching row in governance_decisions tied to session demo-happy-path.

   Run it — 01-happy-path.sh

   ./demo/governance/01-happy-path.sh Copy path

   Or run the individual commands below:

   systemprompt plugins mcp call systemprompt systemprompt -a '{"command":"admin agents list"}' 2>&1

   Copy

   systemprompt infra db query

   Copy

2. Deny a genuinely user-scope caller reaching for an admin MCP tool

   Fires a hook with the user-scope plugin token (demo/.token.user, minted by preflight for demo_user, whose DB role is `user`) against the admin-only mcp__systemprompt__list_agents tool. Governance derives scope from the caller's live DB role, so this resolves to User scope and scope_check denies — the backup line of defense behind tool mapping. The script asserts the real permissionDecision and fails loudly if it is not deny.

   What you see An asserted deny response citing scope_check, plus the matching deny row in governance_decisions — proof that even if tool mapping is bypassed, governance still holds for a real user-scope identity.

   Run it — 02-refused-path.sh

   ./demo/governance/02-refused-path.sh Copy path

   Or run the individual commands below:

   systemprompt infra db query

   Copy

3. Query the decisions table and break down cost by agent

   Runs infra db query against governance_decisions to pull the last five decisions with agent, scope, policy, and reason, then calls analytics costs breakdown --by agent. This is the evidence you hand to a compliance reviewer.

   What you see A table showing the allow and deny records from the previous steps with policy names and reasons, plus per-agent cost totals.

   Run it — 03-audit-trail.sh

   ./demo/governance/03-audit-trail.sh Copy path

   Or run the individual commands below:

   systemprompt infra db query "SELECT decision, tool_name, agent_id, agent_scope, policy, reason FROM governance_decisions ORDER BY created_at DESC LIMIT 5"

   Copy

   systemprompt analytics costs breakdown --by agent

   Copy

4. Allow a clean admin call and show every rule that fired

   POSTs a PreToolUse hook for developer_agent calling Read with a plain file path, then dumps the evaluated_rules column. You see scope_check, secret_scan, and rate_limit each return PASS — not a black-box allow.

   What you see The API returns permissionDecision: allow and the audit row lists all three rules with PASS reasons.

   Run it — 04-governance-happy.sh

   ./demo/governance/04-governance-happy.sh Copy path

   Or run the individual commands below:

   systemprompt infra db query

   Copy

5. Deny an admin tool and a destructive tool for a real user-scope token

   Fires two hook calls with the user-scope plugin token (demo/.token.user, DB role `user`): one reaches for an admin-only MCP tool (scope_check denies), the other calls a destructive non-admin-prefixed tool, delete_records, which passes scope_check and is denied by tool_blocklist (destructive names are blocked for user/non-admin scope; admins are exempt). Each response is asserted to be deny, and the two audit rows read policy=scope_check and policy=tool_blocklist respectively.

   What you see Two asserted deny responses with distinct policy IDs, logged to governance_decisions so you can see the reason Claude Code would surface to the agent.

   Run it — 05-governance-denied.sh

   ./demo/governance/05-governance-denied.sh Copy path

   Or run the individual commands below:

   systemprompt infra db query

   Copy

6. Block an AWS key, a GitHub PAT, and a private key in tool input

   Sends four PreToolUse hooks as admin-scope developer_agent: a Bash curl carrying AKIA..., a Write dropping ghp_... into .env, a Write piping a PEM key into id_rsa, and a clean Read as control. Secret detection overrides scope.

   What you see Three denies (secret_scan) and one allow, all attributed to an admin agent in the audit table — proof the safety net holds against prompt-injection exfiltration.

   Run it — 06-secret-breach.sh

   ./demo/governance/06-secret-breach.sh Copy path

   Or run the individual commands below:

   systemprompt infra db query

   Copy

7. Exceed the rate-limit policy and watch governance deny

   Shows the HTTP rate-limit config, then reads the governance rate_limit policy (requests_per_window / window_secs) and fires that many PreToolUse calls plus an overshoot from one fresh session_id against /hooks/govern. The sliding-window limiter trips inside the policy pipeline and starts returning deny.

   What you see A live allow vs deny tally for one session, followed by an audit query attributing every deny to policy=rate_limit with a RateLimitWindow reason — proof the limiter actually fires, not just that it's configured.

   Run it — 07-rate-limiting.sh

   ./demo/governance/07-rate-limiting.sh Copy path

   Or run the individual commands below:

   systemprompt admin config rate-limits show

   Copy

   systemprompt infra db query

   Copy

8. List, validate, and fire a hook end-to-end

   Lists every PreToolUse, PostToolUse, and lifecycle hook across installed plugins and validates the wiring, then POSTs a synthetic PostToolUse to /hooks/track — the exact wire path Claude Code uses to report a local hook fire — and reads the inserted row back out of plugin_usage_events.

   What you see A validated hook inventory plus a fresh plugin_usage_events row keyed on a one-shot session_id — proof the hook-tracking path is wired into the audit store, not just the manifest.

   Run it — 08-hooks.sh

   ./demo/governance/08-hooks.sh Copy path

   Or run the individual commands below:

   systemprompt core hooks list

   Copy

Staff engineers evaluating an agent runtime want three things: to see what's configured, to watch one actually do work, and to trust that every call is auditable. This walkthrough starts at agent discovery, drills into the config and tool scopes that separate an admin agent from a user-scoped one, sends a live message that triggers real MCP tool use, and ends at the execution trace and A2A registry. By the last step you have seen events, artifacts, cost attribution, and service discovery for a single prompt.

1. Discover the agents the platform ships with

   Lists every configured agent via admin agents list, shows process status, then prints the full config for developer_agent (admin scope) and associate_agent (user scope) side by side so you can see exactly how a scoped-down role differs from a privileged one.

   What you see Two-row agent roster, a running-agent status table, and two concrete YAML configs with oauth scopes, port, endpoint, and skill assignments.

   Run it — 01-list-agents.sh

   ./demo/agents/01-list-agents.sh Copy path

   Or run the individual commands below:

   systemprompt admin agents list

   Copy

   systemprompt admin agents status

   Copy

   systemprompt admin agents show developer_agent

   Copy

   systemprompt admin agents show associate_agent

   Copy

2. Validate configs and inspect tool scopes

   Shows live process status, then validates both developer_agent and associate_agent and enumerates the MCP tools each one can actually call. The difference is the point: the user-scoped associate cannot reach admin-only MCP tools because the governance scope_check rule denies them at the hook.

   What you see A process status table plus validated configs and two tool inventories that diverge exactly at the admin-only MCP surface.

   Run it — 02-agent-config.sh

   ./demo/agents/02-agent-config.sh Copy path

   Or run the individual commands below:

   systemprompt admin agents validate "$agent" --profile "$PROFILE" 2>&1 | sed 's/^/  /'

   Copy

   systemprompt admin agents status

   Copy

   systemprompt admin agents tools developer_agent

   Copy

   systemprompt admin agents tools associate_agent

   Copy

3. Send a real message and let the agent work

   Creates a context, messages developer_agent with "List all agents running on this platform" in blocking mode, then retrieves the structured artifact it produced. This is the only step that spends money and the only one that exercises the full runtime — A2A message → agent server → AI call → MCP tool use → artifact.

   What you see A reply, an artifact attached to the context, a structured response with tool use events, and a dashboard link scoped to the exact session_id so you can replay the whole thing visually.

   Run it — 03-agent-messaging.sh

   ./demo/agents/03-agent-messaging.sh Copy path

   Or run the individual commands below:

   systemprompt core artifacts show "$ARTIFACT_ID" --full --profile "$PROFILE" 2>&1 | head -50 | sed 's/^/  /'

   Copy

   systemprompt infra logs trace show "$TRACE_ID" --all --profile "$PROFILE" 2>&1 | head -60 | sed 's/^/  /'

   Copy

   systemprompt analytics costs breakdown --by agent --profile "$PROFILE" 2>&1 | head -30 | sed 's/^/  /'

   Copy

4. Replay what just happened

   Pulls the most recent execution traces, expands the latest one to show every event, lists artifacts produced during the run, and breaks cost down by agent. Nothing is mocked — this reads the same tables the dashboard reads.

   What you see The trace shows AI requests, MCP tool calls with arguments, latency per step, and a dollar figure attributed to developer_agent.

   Run it — 04-agent-tracing.sh

   ./demo/agents/04-agent-tracing.sh Copy path

   Or run the individual commands below:

   systemprompt infra logs trace list --limit 5

   Copy

   systemprompt infra logs trace show "$TRACE_ID" --all

   Copy

   systemprompt core artifacts list

   Copy

   systemprompt analytics costs breakdown --by agent

   Copy

5. See the agents as discoverable services

   Queries the A2A gateway registry so you can see how other agents and external callers discover these workers, then tails the process logs for each agent. A2A is what makes this a platform rather than a single chatbot.

   What you see The registry shows both developer_agent and associate_agent registered with the A2A gateway, and the per-agent logs pull live stdout from the running processes.

   Run it — 05-agent-registry.sh

   ./demo/agents/05-agent-registry.sh Copy path

   Or run the individual commands below:

   systemprompt admin agents registry --profile "$PROFILE" 2>&1 | head -30 | sed 's/^/  /' || info "Registry unavailable — agents may need restart."

   Copy

   systemprompt admin agents logs developer_agent

   Copy

   systemprompt admin agents logs associate_agent

   Copy

MCP is where agents meet real systems, which is exactly where enterprise reviews stall: who is connected, who called what, and what stops a misbehaving model from exfiltrating a secret. This walkthrough starts at the server inventory, then fires a governance hook with a clean payload and a payload containing an AWS key to show allow and deny decisions hitting the audit tables, and ends in the execution analytics view where every tool call is already counted.

1. Inventory the connected MCP servers

   Prints runtime status for every MCP server the platform is connected to, then lists the tools exposed by each one — anchored on the systemprompt server — so you can see what an agent actually has on its tool bar.

   What you see You see which MCP servers are live, their transport and health, and the exact tool names and schemas available to any agent wired into them.

   Run it — 01-mcp-servers.sh

   ./demo/mcp/01-mcp-servers.sh Copy path

   Or run the individual commands below:

   systemprompt plugins mcp status

   Copy

   systemprompt plugins mcp tools

   Copy

   systemprompt plugins mcp tools --server systemprompt

   Copy

2. Fire the governance hook, clean then dirty

   POSTs to /hooks/govern twice — once with a benign Read on /src/main.rs and once with a Bash command containing an AWS access key — then calls a tool through the authenticated MCP path and queries the governance_decisions and user_activity tables directly.

   What you see The first call returns permissionDecision allow, the second returns deny with the secret_scan rule as the reason, and the audit tables show both decisions plus the MCP access event rows the dashboard renders.

   Run it — 02-mcp-access-tracking.sh

   ./demo/mcp/02-mcp-access-tracking.sh Copy path

   Or run the individual commands below:

   systemprompt infra db query

   Copy

3. Zoom out to the execution analytics

   Lists the tools exposed by the systemprompt MCP server, pulls the last ten MCP tool execution log entries, and prints usage stats and seven-day trends. This closes the loop from "a call happened" to "here is how the fleet is being used."

   What you see A per-server tool inventory, a chronological tool execution log with latencies, and aggregate counts and trends broken down by tool name.

   Run it — 03-mcp-tool-execution.sh

   ./demo/mcp/03-mcp-tool-execution.sh Copy path

   Or run the individual commands below:

   systemprompt plugins mcp tools -s systemprompt

   Copy

   systemprompt infra logs tools list --limit 10

   Copy

   systemprompt analytics tools stats

   Copy

   systemprompt analytics tools trends --since 7d

   Copy

If you can't answer "what did my agents do today and what did it cost?" you can't run them in production. This walkthrough starts at the 24-hour overview and drills down: which agents are busy, what each model is costing, and the raw request stream with latency and token counts. The same telemetry powers the dashboard, so nothing here is a toy view.

1. Open the 24h and 7d overview

   Runs analytics overview for the last 24 hours and then --since 7d. One command gives you the same top-of-funnel numbers the admin dashboard shows — request volume, agent activity, cost, errors.

   What you see You see a 24h and 7d snapshot of request count, active agents, total cost, and error rate in a single table.

   Run it — 01-overview.sh

   ./demo/analytics/01-overview.sh Copy path

   Or run the individual commands below:

   systemprompt analytics overview

   Copy

   systemprompt analytics overview --since 7d

   Copy

2. Drill into agent performance

   Aggregate stats, a ranked list of every agent with metrics, 7-day trends, and a deep-dive into developer_agent. This is how you find the one agent quietly burning budget or failing silently.

   What you see You see a per-agent table with request count, success rate, and latency, a 7-day trend line, and a per-agent deep dive for developer_agent.

   Run it — 02-agent-analytics.sh

   ./demo/analytics/02-agent-analytics.sh Copy path

   Or run the individual commands below:

   systemprompt analytics agents stats

   Copy

   systemprompt analytics agents list

   Copy

   systemprompt analytics agents trends --since 7d

   Copy

   systemprompt analytics agents show developer_agent

   Copy

3. Break cost down by model and agent

   Prints the cost summary, then breaks it down by model and by agent, then shows 7-day trends. This is your finance conversation: Haiku is 80% of calls and 12% of cost; Opus is the opposite.

   What you see You see total spend, cost split by model, cost split by agent, and a 7-day cost trend — attributable to the row.

   Run it — 03-cost-analytics.sh

   ./demo/analytics/03-cost-analytics.sh Copy path

   Or run the individual commands below:

   systemprompt analytics costs summary

   Copy

   systemprompt analytics costs breakdown --by model

   Copy

   systemprompt analytics costs breakdown --by agent

   Copy

   systemprompt analytics costs trends --since 7d

   Copy

4. Inspect the raw request stream

   Shows request stats, the last 24 hours of individual AI calls, the model usage distribution, and 7-day volume trends. Every row is a real request you can click through to the full audit log.

   What you see You see request-level rows with model, latency, and token counts, the model distribution, and a 7-day volume trend.

   Run it — 04-request-analytics.sh

   ./demo/analytics/04-request-analytics.sh Copy path

   Or run the individual commands below:

   systemprompt analytics requests stats

   Copy

   systemprompt analytics requests list --since 24h

   Copy

   systemprompt analytics requests models

   Copy

   systemprompt analytics requests trends --since 7d

   Copy

5. Zoom into sessions — stats, trends, and live

   Runs analytics sessions stats, a 7-day trend line, and the live active-session view. Sessions answer "who's using it right now" and "is usage trending up".

   What you see Aggregate session counts, a 7-day trend, and a live list of sessions currently open against the platform.

   Run it — 05-session-analytics.sh

   ./demo/analytics/05-session-analytics.sh Copy path

   Or run the individual commands below:

   systemprompt analytics sessions stats

   Copy

   systemprompt analytics sessions trends --since 7d

   Copy

   systemprompt analytics sessions live

   Copy

6. Break down content and traffic

   analytics content stats, top pages, 7-day content trends, traffic sources, geo distribution, and device breakdown. Same binary that governs agents also tells you where your readers come from.

   What you see Content engagement stats, top pages, traffic source and geo split, and a device breakdown for the public site.

   Run it — 06-content-traffic.sh

   ./demo/analytics/06-content-traffic.sh Copy path

   Or run the individual commands below:

   systemprompt analytics traffic "$sub"

   Copy

   systemprompt analytics content stats

   Copy

   systemprompt analytics content top --profile "$PROFILE" 2>&1

   Copy

   systemprompt analytics content trends --since 7d

   Copy

7. Inspect agent conversations

   Prints conversation stats, 7-day trends, and the 20 most recent conversations. Every agent session is a conversation you can list and replay — no black-box chat log.

   What you see Counts and a 7-day trend for conversations, plus a list of the 20 most recent with agent, status, and turn count.

   Run it — 07-conversations.sh

   ./demo/analytics/07-conversations.sh Copy path

   Or run the individual commands below:

   systemprompt analytics conversations stats

   Copy

   systemprompt analytics conversations trends --since 7d

   Copy

   systemprompt analytics conversations list

   Copy

8. Close the loop on tool usage

   analytics tools stats, a ranked list of tools with per-tool metrics, and a 7-day trend. Tells you which MCP tools your agents are actually reaching for and whether usage is shifting.

   What you see Per-tool call counts, latency, and error rate, plus a 7-day trend showing whether any tool is spiking or quietly dying.

   Run it — 08-tool-analytics.sh

   ./demo/analytics/08-tool-analytics.sh Copy path

   Or run the individual commands below:

   systemprompt analytics tools stats

   Copy

   systemprompt analytics tools list

   Copy

   systemprompt analytics tools trends --since 7d

   Copy

Before trusting a platform with production agents, you want to know how user identity actually works. This walkthrough lists the user directory, drills into a single user's role, confirms the current authenticated session and profile, then demonstrates the IP-ban lever end to end — add, verify, remove — so you know the abuse-response path is real and reversible.

1. List, count, stat, and search the user directory

   Runs admin users list, count, stats, and search admin to show the full directory, aggregate counts, and a keyword lookup. This is the baseline inventory every reviewer asks for.

   What you see A paginated user list, a total count, a stats summary, and matching rows for the admin search term.

   Run it — 01-user-listing.sh

   ./demo/users/01-user-listing.sh Copy path

   Or run the individual commands below:

   systemprompt admin users list

   Copy

   systemprompt admin users count

   Copy

   systemprompt admin users stats

   Copy

   systemprompt admin users search "admin"

   Copy

2. Drill into a single user and read their role assignment

   Grabs the first user ID from admin users list and pipes it into admin users show. You see the role, scope, and metadata the governance layer will key off of.

   What you see A full user record with role, scope, and audit fields — the data governance rules match against.

   Run it — 02-role-management.sh

   ./demo/users/02-role-management.sh Copy path

   Or run the individual commands below:

   systemprompt admin users list

   Copy

   systemprompt admin users show "$USER_ID"

   Copy

   systemprompt admin users stats

   Copy

3. Prove the current session and list available profiles

   Calls admin session show to display who the CLI is authenticated as, then admin session list to show every profile the operator can switch into. This is how you confirm blast radius before running anything mutating.

   What you see Current session identity with auth source, plus the full list of named profiles available for switching.

   Run it — 03-session-management.sh

   ./demo/users/03-session-management.sh Copy path

   Or run the individual commands below:

   systemprompt admin session show

   Copy

   systemprompt admin session list

   Copy

4. Add, verify, and revoke an IP ban end to end

   Lists current bans, adds 192.168.99.99 with a reason, lists again to confirm, then removes it and lists a third time. A full mutation cycle in one script, leaving no residue behind.

   What you see The test IP appears in the ban list after add, disappears after remove, and the before and after lists match — the abuse-response lever is real and reversible.

   Run it — 04-ip-ban.sh

   ./demo/users/04-ip-ban.sh Copy path

   Or run the individual commands below:

   systemprompt admin users ban list

   Copy

   systemprompt admin users ban add "$TEST_IP" --reason "demo test" --profile "$PROFILE" 2>&1 | sed 's/^/  /' || true

   Copy

   systemprompt admin users ban remove "$TEST_IP" --yes --profile "$PROFILE" 2>&1 | sed 's/^/  /' || true

   Copy

"Skill" is a loaded word, so this walkthrough defines it by showing the whole supply chain. It starts with the skill lifecycle commands, moves to the content store that skills retrieve from, then to the managed file system that backs the content, then to the plugin package that bundles skills and hooks for distribution, and ends at contexts — the conversation containers every agent session binds to. By the end you can trace a skill from on-disk markdown to a live agent reply.

1. Walk the skill lifecycle

   Lists every database-synced skill alongside its on-disk config path, then walks services/skills/ on disk so you see each skill YAML that ships with the template and the structured header of the first one. This is the fastest way to answer "what does a skill look like on disk?".

   What you see You see the synced skill catalog with each skill's file path, and the concrete on-disk YAMLs under services/skills/ with the first one previewed.

   Run it — 01-skill-lifecycle.sh

   ./demo/skills/01-skill-lifecycle.sh Copy path

   Or run the individual commands below:

   systemprompt core skills list

   Copy

   systemprompt core skills show use_dangerous_secret

   Copy

2. Inspect the content skills retrieve from

   Lists the content store, searches it for "governance", ranks popular documentation entries, and prints ingestion status for the documentation source. Content is what gives a skill grounded answers instead of hallucinations.

   What you see You get a catalog of indexed content, a live keyword search result, a popularity ranking, and an ingestion health report for the documentation source.

   Run it — 02-content-management.sh

   ./demo/skills/02-content-management.sh Copy path

   Or run the individual commands below:

   systemprompt core content list

   Copy

   systemprompt core content search "governance"

   Copy

   systemprompt core content popular documentation

   Copy

   systemprompt core content status --source documentation

   Copy

3. Drop down to the files backing content

   Lists managed files, shows the upload configuration including size and type limits, and prints aggregate file statistics. This is the layer most content platforms hide — the script shows it is just another CLI surface.

   What you see You see the managed file inventory, the concrete upload policy the platform enforces, and total counts and size by type.

   Run it — 03-file-management.sh

   ./demo/skills/03-file-management.sh Copy path

   Or run the individual commands below:

   systemprompt core files list

   Copy

   systemprompt core files config

   Copy

4. Package skills into a plugin

   Lists core plugins, walks services/plugins/ on disk to preview each plugin YAML (including enterprise-demo and how it bundles skills, MCP servers, and hooks), lists and validates hooks, then lists loaded extensions and their capabilities. Plugins are the unit of distribution — this is how a skill reaches other installations.

   What you see You see the plugin manifests on disk, the hook inventory with a green validation result, and the extension capability table that tells you exactly what the runtime exposes.

   Run it — 04-plugin-management.sh

   ./demo/skills/04-plugin-management.sh Copy path

   Or run the individual commands below:

   systemprompt core plugins list

   Copy

   systemprompt core hooks list

   Copy

   systemprompt core hooks validate

   Copy

   systemprompt plugins list

   Copy

   systemprompt plugins capabilities

   Copy

5. Bind everything to a live context

   Lists existing contexts, creates a new one, shows it, renames it, deletes it, and re-lists to prove cleanup worked. Contexts are the conversation containers every agent session attaches to, so this is where skills, content, and artifacts meet at runtime.

   What you see You watch a full create-read-update-delete cycle against real storage, with the final list confirming the context was removed.

   Run it — 05-contexts.sh

   ./demo/skills/05-contexts.sh Copy path

   Or run the individual commands below:

   systemprompt core contexts list

   Copy

   systemprompt core contexts show "$CONTEXT_ID"

   Copy

   systemprompt core contexts edit "$CONTEXT_ID" --name "Renamed Demo Context"

   Copy

   systemprompt core contexts delete "$CONTEXT_ID"

   Copy

Most governance platforms stop at the API. Enterprise Demo also publishes systemprompt.io from the same Rust binary, using the same CLI, against the same database. This walkthrough inventories the content model, then runs the validator so you can see the publishing pipeline is real, typed, and CI-friendly.

1. Inspect the content model

   Lists the registered content types, templates, and static assets that drive the site. Everything the web extension renders is declared config you can diff in git — no hidden CMS.

   What you see You see the full set of content types, Tera templates, and asset bundles that compose systemprompt.io.

   Run it — 01-web-config.sh

   ./demo/web/01-web-config.sh Copy path

   Or run the individual commands below:

   systemprompt web $sub

   Copy

2. Show the sitemap and validate

   Prints the sitemap configuration and then runs web validate, which type-checks templates, asset references, and routing before anything ships. This is the same command wired into CI.

   What you see A green validation report plus the live sitemap structure — proof the site builds deterministically from config.

   Run it — 02-sitemap-validate.sh

   ./demo/web/02-sitemap-validate.sh Copy path

   Or run the individual commands below:

   systemprompt web sitemap show

   Copy

   systemprompt web validate

   Copy

Staff engineers don't trust benchmarks they can't reproduce. This walkthrough fires a real governance request, follows it through JWT validation, scope resolution, rule evaluation, and the async audit write — showing the typed Rust structs and sqlx-checked SQL at every stage. Then it runs 2,000 requests across three load profiles and prints real throughput, p50/p90/p99, and a capacity estimate in concurrent developers.

1. Trace one governance request end-to-end

   Fires a real PreToolUse governance call plus a PostToolUse track event, then queries governance_decisions and plugin_usage_events to show the typed IDs that landed, pulls the trace and request logs for the call, and prints the router-to-audit flow map annotated with the Rust struct at each stage. Every layer is compile-time checked — serde at the boundary, newtypes in the handler, sqlx::query! against the live schema.

   What you see You see the request payload, the response, the matching rows in governance_decisions and plugin_usage_events, the trace and request log entries, and a six-stage flow map from Axum router through JWT, scope resolution, rule engine, async audit write, and response.

   Run it — 01-request-tracing.sh

   ./demo/performance/01-request-tracing.sh Copy path

   Or run the individual commands below:

   systemprompt infra db query

   Copy

   systemprompt infra logs trace list --limit 3 --profile "$PROFILE" 2>&1 | grep -v "^\[profile"

   Copy

   systemprompt infra logs trace show "$TRACE_ID" --all --profile "$PROFILE" 2>&1 | grep -v "^\[profile" | head -30

   Copy

   systemprompt infra logs request list --limit 5 --profile "$PROFILE" 2>&1 | grep -v "^\[profile"

   Copy

   systemprompt infra logs view --level info --since 5m --profile "$PROFILE" 2>&1 | grep -v "^\[profile" | head -15

   Copy

   systemprompt plugins mcp call systemprompt systemprompt --args '{"command":"core skills list"}' --profile "$PROFILE" 2>/dev/null | head -1 > /dev/null

   Copy

2. Run a 2,000-request production load test

   Uses hey to drive 500 governance requests at 50 concurrent, 500 track requests at 50 concurrent, 1,000 sustained governance requests at 100 concurrent, and 5 MCP tool calls, then reads the Postgres pool stats and counts the audit rows that landed. This is what a single box does under real concurrency — no AI calls, pure platform infrastructure.

   What you see You see throughput in req/s and p50/p90/p99 latency for each of three load profiles, MCP tool call latency, live Postgres pool occupancy, a decisions-written audit query confirming zero dropped requests, and a capacity estimate in concurrent developers per instance.

   Run it — 02-load-test.sh

   ./demo/performance/02-load-test.sh Copy path

   Or run the individual commands below:

   systemprompt plugins mcp call systemprompt systemprompt --args '{"command":"core skills list"}' --profile "$PROFILE" 2>/dev/null | head -1 > /dev/null

   Copy

   systemprompt infra db query

   Copy