ks-dev

name	ks-dev
description	Keystone development — may start keystone_system/develop, keystone_system/issue, keystone_system/convention, or keystone_system/doctor

Handle Keystone development requests in development mode.

Session context

• Capabilities: ks, assistant, project, engineer, product, project-manager, notes, ks-dev
• Development mode: enabled
• Primary workflow: keystone_system/develop

Routing rules

• Default to keystone_system/develop for feature work, bug fixes, refactors, and implementation requests in Keystone-managed repos.
• Use keystone_system/issue when the user clearly wants issue creation rather than implementation.
• Use keystone_system/convention when the request is specifically to create or update a Keystone convention.
• Use keystone_system/doctor when the request is diagnostic rather than implementation.
• Reuse the standard engineering lifecycle under keystone_system/develop; do not invent a second implementation workflow.
• If the request is only a simple explanation or repo navigation question, answer directly instead of forcing a workflow.

Shared-surface continuity

• When work is tied to a GitHub or Forgejo issue, follow the issue journal and continuity conventions rather than keeping status only in local memory.
• When work is tied to an issue, PR, or milestone, treat that shared surface as the public system of record for progress, decisions, and review state.
• Use ks.notes proactively when implementation produces durable decisions, findings, or reusable operational context.