{"owner":"goplus","repo":"xgo","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["CLAUDE.md"],"skills":{"CLAUDE.md":"# XGo Project AI Assistant Guide\n\n## Workflow\n\n### Adding New Syntax Features\n\nWhen implementing new language syntax, follow this three-phase approach:\n\n**IMPORTANT**: Each phase must be implemented in a separate pull request. Do NOT mix phases in a single PR. This separation ensures:\n- Clear review focus (grammar vs semantics vs documentation)\n- Easier rollback if issues are found\n- Better git history and maintainability\n- Allows grammar to be reviewed independently from implementation details\n\n#### Phase 1: Grammar Definition (First Pull Request)\n**Scope**: AST, parser, printer, and required AST consumer modifications ONLY\n- **AST**: Define new node types in `ast/` directory (if needed - often existing nodes can be reused)\n- **Parser**: Implement parsing rules in `parser/` directory to recognize the new syntax\n- **Printer**: Add formatting support for new syntax (inverse of parsing) in `printer/` directory\n- **AST Consumers**: Audit manually maintained consumers such as `ast.Walk`, `ast/filter.go`, parser expression validation, and `x/format`\n- **Testing**: Add test cases in `parser/_testdata/` for new syntax and focused unit tests for affected AST consumers\n  - **Note**: Printer reuses parser test cases and also has printer-specific cases in `printer/_testdata/`\n- **What NOT to include**: Do NOT add any code generation or semantic logic in `cl/` package - that belongs in Phase 2\n\n#### Phase 2: Semantic Implementation (Second Pull Request)\n**Scope**: Code generation via `cl` package and `gogen` module ONLY\n- **Code Generation**: Implement semantics using `github.com/goplus/gogen` package\n- **Type Safety**: Leverage gogen's type information maintenance for semantic correctness\n- **Testing**: Add comprehensive test cases in `cl/_testxgo/` covering various usage scenarios\n- **Prerequisite**: Phase 1 PR must be merged before starting Phase 2\n\nWhen submitting a new PR to the `gogen` repository for a change, also submit a PR to the `xgo` repository that updates the `gogen` module to the latest code from the corresponding `gogen` branch. The xgo PR's go.mod/go.sum must pin the gogen dependency to the feature branch's commit (not to a released version), so the two PRs represent a coherent, reviewable change set.\n\n#### Phase 3: Documentation (Third Pull Request)\n**Scope**: User-facing documentation updates ONLY\n- **Quick Start Guide**: Add feature documentation to `doc/docs.md` with practical examples\n- **Table of Contents**: Update TOC in quick start to include new feature section\n- **Language Specification**: Update specification documents (see Language Specification Structure below)\n- **Examples**: Provide clear, runnable code examples demonstrating the feature\n- **Prerequisite**: Phase 2 PR must be merged before starting Phase 3\n\n### Communication Protocol\n- When I request syntax additions, first confirm the exact grammar specification\n- Always consider backward compatibility with existing Go code\n- For ambiguous requirements, ask clarifying questions about:\n  - Precedence and associativity rules\n  - Error handling expectations\n  - Integration with existing type system\n\n## Technical Specifications\n\n### Compiler Architecture\n- **Target**: XGo compiles to Go code, not machine code\n- **Foundation**: Built on `github.com/goplus/gogen` for robust Go AST generation\n- **Key Benefit**: gogen maintains type information, ensuring both syntactic and semantic correctness\n\n## Quality Standards\n\n### Code Requirements\n\n- Maintain full compatibility with existing Go ecosystem\n- Ensure new syntax doesn't break existing XGo/Go code\n- Follow Go idioms in generated code\n- Provide comprehensive error messages\n- **Code Formatting**: Run `go fmt` on any changed source files before committing\n\n### Documentation Expectations\n\n- Update language specification documents\n- Add examples to Quick Start guide\n- Document any limitations or special considerations\n\n### Testing Requirements\n\n- **Phase 1**: 100% test coverage for new syntax parsing in `parser/_testdata/` and focused tests for affected AST consumers\n- **Phase 2**: Comprehensive test coverage for semantic implementation in `cl/_testxgo/` covering:\n  - Common usage scenarios\n  - Edge cases and error conditions\n  - Integration with existing type system\n- **Phase 3**: Documentation validation\n  - Ensure all code examples in documentation are runnable and correct\n  - Verify documentation accurately reflects implemented behavior\n  - Check that TOC links work correctly\n- **Coverage rule**: Unit test coverage **must not decrease** across any PR. Run `go test ./... -cover` before and after your changes and compare. If coverage drops for any package, add tests to compensate before submitting.\n"},"files":{"CLAUDE.md":"# XGo Project AI Assistant Guide\n\n## Workflow\n\n### Adding New Syntax Features\n\nWhen implementing new language syntax, follow this three-phase approach:\n\n**IMPORTANT**: Each phase must be implemented in a separate pull request. Do NOT mix phases in a single PR. This separation ensures:\n- Clear review focus (grammar vs semantics vs documentation)\n- Easier rollback if issues are found\n- Better git history and maintainability\n- Allows grammar to be reviewed independently from implementation details\n\n#### Phase 1: Grammar Definition (First Pull Request)\n**Scope**: AST, parser, printer, and required AST consumer modifications ONLY\n- **AST**: Define new node types in `ast/` directory (if needed - often existing nodes can be reused)\n- **Parser**: Implement parsing rules in `parser/` directory to recognize the new syntax\n- **Printer**: Add formatting support for new syntax (inverse of parsing) in `printer/` directory\n- **AST Consumers**: Audit manually maintained consumers such as `ast.Walk`, `ast/filter.go`, parser expression validation, and `x/format`\n- **Testing**: Add test cases in `parser/_testdata/` for new syntax and focused unit tests for affected AST consumers\n  - **Note**: Printer reuses parser test cases and also has printer-specific cases in `printer/_testdata/`\n- **What NOT to include**: Do NOT add any code generation or semantic logic in `cl/` package - that belongs in Phase 2\n\n#### Phase 2: Semantic Implementation (Second Pull Request)\n**Scope**: Code generation via `cl` package and `gogen` module ONLY\n- **Code Generation**: Implement semantics using `github.com/goplus/gogen` package\n- **Type Safety**: Leverage gogen's type information maintenance for semantic correctness\n- **Testing**: Add comprehensive test cases in `cl/_testxgo/` covering various usage scenarios\n- **Prerequisite**: Phase 1 PR must be merged before starting Phase 2\n\nWhen submitting a new PR to the `gogen` repository for a change, also submit a PR to the `xgo` repository that updates the `gogen` module to the latest code from the corresponding `gogen` branch. The xgo PR's go.mod/go.sum must pin the gogen dependency to the feature branch's commit (not to a released version), so the two PRs represent a coherent, reviewable change set.\n\n#### Phase 3: Documentation (Third Pull Request)\n**Scope**: User-facing documentation updates ONLY\n- **Quick Start Guide**: Add feature documentation to `doc/docs.md` with practical examples\n- **Table of Contents**: Update TOC in quick start to include new feature section\n- **Language Specification**: Update specification documents (see Language Specification Structure below)\n- **Examples**: Provide clear, runnable code examples demonstrating the feature\n- **Prerequisite**: Phase 2 PR must be merged before starting Phase 3\n\n### Communication Protocol\n- When I request syntax additions, first confirm the exact grammar specification\n- Always consider backward compatibility with existing Go code\n- For ambiguous requirements, ask clarifying questions about:\n  - Precedence and associativity rules\n  - Error handling expectations\n  - Integration with existing type system\n\n## Technical Specifications\n\n### Compiler Architecture\n- **Target**: XGo compiles to Go code, not machine code\n- **Foundation**: Built on `github.com/goplus/gogen` for robust Go AST generation\n- **Key Benefit**: gogen maintains type information, ensuring both syntactic and semantic correctness\n\n## Quality Standards\n\n### Code Requirements\n\n- Maintain full compatibility with existing Go ecosystem\n- Ensure new syntax doesn't break existing XGo/Go code\n- Follow Go idioms in generated code\n- Provide comprehensive error messages\n- **Code Formatting**: Run `go fmt` on any changed source files before committing\n\n### Documentation Expectations\n\n- Update language specification documents\n- Add examples to Quick Start guide\n- Document any limitations or special considerations\n\n### Testing Requirements\n\n- **Phase 1**: 100% test coverage for new syntax parsing in `parser/_testdata/` and focused tests for affected AST consumers\n- **Phase 2**: Comprehensive test coverage for semantic implementation in `cl/_testxgo/` covering:\n  - Common usage scenarios\n  - Edge cases and error conditions\n  - Integration with existing type system\n- **Phase 3**: Documentation validation\n  - Ensure all code examples in documentation are runnable and correct\n  - Verify documentation accurately reflects implemented behavior\n  - Check that TOC links work correctly\n- **Coverage rule**: Unit test coverage **must not decrease** across any PR. Run `go test ./... -cover` before and after your changes and compare. If coverage drops for any package, add tests to compensate before submitting.\n"},"items":[{"name":"CLAUDE.md","path":"CLAUDE.md","title":"CLAUDE.md","content":"# XGo Project AI Assistant Guide\n\n## Workflow\n\n### Adding New Syntax Features\n\nWhen implementing new language syntax, follow this three-phase approach:\n\n**IMPORTANT**: Each phase must be implemented in a separate pull request. Do NOT mix phases in a single PR. This separation ensures:\n- Clear review focus (grammar vs semantics vs documentation)\n- Easier rollback if issues are found\n- Better git history and maintainability\n- Allows grammar to be reviewed independently from implementation details\n\n#### Phase 1: Grammar Definition (First Pull Request)\n**Scope**: AST, parser, printer, and required AST consumer modifications ONLY\n- **AST**: Define new node types in `ast/` directory (if needed - often existing nodes can be reused)\n- **Parser**: Implement parsing rules in `parser/` directory to recognize the new syntax\n- **Printer**: Add formatting support for new syntax (inverse of parsing) in `printer/` directory\n- **AST Consumers**: Audit manually maintained consumers such as `ast.Walk`, `ast/filter.go`, parser expression validation, and `x/format`\n- **Testing**: Add test cases in `parser/_testdata/` for new syntax and focused unit tests for affected AST consumers\n  - **Note**: Printer reuses parser test cases and also has printer-specific cases in `printer/_testdata/`\n- **What NOT to include**: Do NOT add any code generation or semantic logic in `cl/` package - that belongs in Phase 2\n\n#### Phase 2: Semantic Implementation (Second Pull Request)\n**Scope**: Code generation via `cl` package and `gogen` module ONLY\n- **Code Generation**: Implement semantics using `github.com/goplus/gogen` package\n- **Type Safety**: Leverage gogen's type information maintenance for semantic correctness\n- **Testing**: Add comprehensive test cases in `cl/_testxgo/` covering various usage scenarios\n- **Prerequisite**: Phase 1 PR must be merged before starting Phase 2\n\nWhen submitting a new PR to the `gogen` repository for a change, also submit a PR to the `xgo` repository that updates the `gogen` module to the latest code from the corresponding `gogen` branch. The xgo PR's go.mod/go.sum must pin the gogen dependency to the feature branch's commit (not to a released version), so the two PRs represent a coherent, reviewable change set.\n\n#### Phase 3: Documentation (Third Pull Request)\n**Scope**: User-facing documentation updates ONLY\n- **Quick Start Guide**: Add feature documentation to `doc/docs.md` with practical examples\n- **Table of Contents**: Update TOC in quick start to include new feature section\n- **Language Specification**: Update specification documents (see Language Specification Structure below)\n- **Examples**: Provide clear, runnable code examples demonstrating the feature\n- **Prerequisite**: Phase 2 PR must be merged before starting Phase 3\n\n### Communication Protocol\n- When I request syntax additions, first confirm the exact grammar specification\n- Always consider backward compatibility with existing Go code\n- For ambiguous requirements, ask clarifying questions about:\n  - Precedence and associativity rules\n  - Error handling expectations\n  - Integration with existing type system\n\n## Technical Specifications\n\n### Compiler Architecture\n- **Target**: XGo compiles to Go code, not machine code\n- **Foundation**: Built on `github.com/goplus/gogen` for robust Go AST generation\n- **Key Benefit**: gogen maintains type information, ensuring both syntactic and semantic correctness\n\n## Quality Standards\n\n### Code Requirements\n\n- Maintain full compatibility with existing Go ecosystem\n- Ensure new syntax doesn't break existing XGo/Go code\n- Follow Go idioms in generated code\n- Provide comprehensive error messages\n- **Code Formatting**: Run `go fmt` on any changed source files before committing\n\n### Documentation Expectations\n\n- Update language specification documents\n- Add examples to Quick Start guide\n- Document any limitations or special considerations\n\n### Testing Requirements\n\n- **Phase 1**: 100% test coverage for new syntax parsing in `parser/_testdata/` and focused tests for affected AST consumers\n- **Phase 2**: Comprehensive test coverage for semantic implementation in `cl/_testxgo/` covering:\n  - Common usage scenarios\n  - Edge cases and error conditions\n  - Integration with existing type system\n- **Phase 3**: Documentation validation\n  - Ensure all code examples in documentation are runnable and correct\n  - Verify documentation accurately reflects implemented behavior\n  - Check that TOC links work correctly\n- **Coverage rule**: Unit test coverage **must not decrease** across any PR. Run `go test ./... -cover` before and after your changes and compare. If coverage drops for any package, add tests to compensate before submitting.\n","category":"root","tokens":1175}]}