| 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.
