Using Sphere Workflow

This skill is the bootstrap entrypoint for the sphere-workflow plugin.

Use it to classify the request first, then invoke only the next needed go-sphere skill. Do not load every bundled skill preemptively.

Routing Rules

1. If the user explicitly names a skill, use that skill.
2. If the request spans multiple lifecycle stages, start at the earliest missing artifact.
3. If the request is already narrowed to a single stage, invoke only that stage skill.
4. If the task will modify go-sphere scaffold contracts, schemas, services, or generation commands, route into sphere-feature-workflow.
5. If the task is about pulling upstream layout changes into an existing project, or adopting a pre-contract project, route into sphere-layout-sync — not sphere-feature-workflow.
6. If the task is about the protoc-gen-* plugins themselves rather than the .proto contracts they consume, route into protoc-plugin-engineering — not proto-api-generator.
7. If the work is only filling in missing methods in one service file from an existing generated interface, route into proto-service-generator — not sphere-feature-workflow.
8. If the task is auditing or simplifying existing Go code for over-design, over-optimization, or over-defensive checks rather than adding a feature, route into go-simplify — not sphere-feature-workflow.

Stage Handoffs