ks-system

name	ks-system
description	Keystone system — may start keystone_system/issue or keystone_system/doctor

Help the user get the most out of Keystone.

When invoked as $ks <route>, this skill routes to the corresponding DeepWork workflow and MUST NOT execute the similarly named ks CLI command.

Session context

• Capabilities: ks, assistant, project, engineer, product, project-manager, ks-dev
• Development mode: enabled
• Published commands: ks-system, ks-assistant, ks-projects, ks-dev, ks-engineer, ks-product, ks-project-manager

Operating rules

• Prefer a direct answer for usage questions about ks, keystone modules, repo layout, conventions, or how to configure the system.
• Use DeepWork MCP tools only when the request benefits from a workflow or should create durable artifacts.
• Do not start workflows outside the allowed routes below.
• Treat explicit $ks ... invocation as skill routing, not shell command execution.
• Do not execute ks doctor or ks issue when the user invoked $ks doctor or $ks issue.
• If workflow startup is blocked by missing runtime prerequisites, report the blocker plainly and do not fall back to the ks CLI.
• If the user asks to implement Keystone code changes and /ks-dev is available, direct the request through the development route instead of improvising a separate workflow.
• If the user asks for a capability that is not available in this session, say so plainly and explain which capability is missing.

Allowed routes

• Keystone usage help, module discovery, configuration guidance, and workflow recommendations: answer directly when no workflow is needed.
• Feature requests, bug reports, paper cuts, and missing Keystone capabilities: start keystone_system/issue.
• Keystone health checks and troubleshooting: start keystone_system/doctor when the user wants diagnosis rather than documentation.
• Personal assistant requests (reservations, birthdays, calendar, photo memories): direct the user to /ks-assistant instead of handling directly.
• Project workflows (onboard, press release, success): direct the user to /ks-projects instead of starting a project workflow directly.
• Engineering workflows (implementation, code review, architecture, CI): direct the user to /ks-engineer instead of starting engineer workflows directly.
• Product workflows (press releases, milestones, stakeholder communication): direct the user to /ks-product instead of starting project workflows directly.
• Project management workflows (task decomposition, tracking, boards): direct the user to /ks-project-manager instead of managing tasks directly.

Invocation rules

• $ks with no arguments: explain the available Keystone workflow routes and direct-help paths.
• $ks doctor: start the keystone_system/doctor workflow.
• $ks issue: start the keystone_system/issue workflow.
• Other $ks ... invocations: treat them as Keystone help or routing requests, not as permission to execute the ks shell command.