improved flow and catch linting failures

[buzzdan]

This pull request introduces several improvements to the linter-driven Go development workflow, focusing on explicit skill invocation, enhanced linter-to-skill routing, stricter quality gates, and improved documentation for design and refactoring patterns. The changes ensure that skills are invoked programmatically (not just referenced), clarify how linter errors map to remediation steps, and add detailed design guidance for handling common linter failures. Additionally, the mcp__ide__getDiagnostics tool is now permitted in all relevant agents and commands, enabling better diagnostic integration.

Key changes include:

Skill Invocation and Tooling Consistency

• All relevant agents, commands, and skills now explicitly allow the mcp__ide__getDiagnostics tool, ensuring consistent access to IDE diagnostics across the workflow. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10]
• Added <skill_invocation> sections to all major skills, requiring that skills (e.g., @testing, @refactoring) be invoked via the Skill tool, not just referenced in text. Clear tables show the mapping between notation and tool calls. [1] [2] [3]

Linter Error Routing and Design Patterns

• Introduced comprehensive linter error routing tables and documentation, mapping specific linter failures to the correct skill and remediation pattern (e.g., argument-limit → options struct, function-result-limit → result type, file-length-limit → file splitting/god object decomposition). [1] [2] [3] [4]
• Added detailed examples and step-by-step guidance for handling common design-related linter failures, including code snippets for before/after refactoring.

Workflow and Quality Gate Enhancements

• The linter-driven development skill now enforces that all new types have corresponding test files and >0% coverage before progressing past implementation. Leaf types require 100% coverage, and warnings are issued if coverage is below 80%.
• The iterative fix loop now includes orchestrator checks for "god objects" (>15 methods per type), requiring storification and service extraction before proceeding. [1] [2] [3]
• The workflow is only considered complete when all extracted leaf types have tests with 100% coverage and no god objects remain.

Documentation and Usability Improvements

• Updated agent and command descriptions to clarify the use of the Skill tool for invoking skills, not just referencing them. [1] [2] [3]
• Added structured references and tables to help users understand linter categories, severity, and routing.

These changes collectively make the Go linter-driven workflow more robust, explicit, and maintainable by enforcing best practices and ensuring all automation is performed through well-defined skill invocations.