|
| 1 | +# GitHub Game - Copilot Instructions |
| 2 | + |
| 3 | +## Project Overview |
| 4 | +This is a GitHub CLI Extension written in Go that allows users to play various games (coin toss, rock paper scissors, tic tac toe) through the GitHub CLI. It's built using Go and the GitHub CLI extension framework, leveraging the Cobra command library for CLI functionality and Charm libraries for terminal UI rendering. |
| 5 | + |
| 6 | +## Code Standards |
| 7 | + |
| 8 | +### Required Before Commit |
| 9 | +- All tests must pass: `go test ./...` |
| 10 | +- Code must be properly formatted: `go fmt ./...` |
| 11 | +- Linting must pass: `golangci-lint run` |
| 12 | +- Ensure documentation is up-to-date for any new commands or features |
| 13 | +- Verify that any new game implementation follows the established patterns |
| 14 | + |
| 15 | +### Go Patterns |
| 16 | +- Follow standard Go idioms and best practices |
| 17 | +- Use GoDoc comments for all exported functions, types, and packages: |
| 18 | + ```go |
| 19 | + // FunctionName does something specific |
| 20 | + // with these parameters and returns this result |
| 21 | + func FunctionName() {} |
| 22 | + ``` |
| 23 | +- Error handling should follow Go conventions (return errors rather than using exceptions) |
| 24 | +- Use meaningful variable and function names that describe their purpose |
| 25 | +- Keep functions small and focused on a single responsibility |
| 26 | +- Separate interface definitions from implementations where appropriate |
| 27 | + |
| 28 | +## Development Flow |
| 29 | + |
| 30 | +- Build: `go build` |
| 31 | +- Test: `go test ./...` |
| 32 | +- Lint: `golangci-lint run` |
| 33 | +- Format: `go fmt ./...` |
| 34 | +- Run: `gh game <subcommand>` (e.g., `gh game cointoss`) |
| 35 | + |
| 36 | +## Repository Structure |
| 37 | +- `/cmd`: Main command implementations and CLI structure |
| 38 | + - Command files for each game and core CLI functionality |
| 39 | +- `/internal`: Internal packages not intended for external use |
| 40 | + - Game logic implementations |
| 41 | + - Utility functions |
| 42 | +- `/pkg`: Public libraries that could potentially be used by other projects |
| 43 | +- `/test`: Test utilities and fixtures |
| 44 | +- `main.go`: Entry point for the application |
| 45 | +- `README.md`: Project documentation |
| 46 | +- `LICENSE`: MIT license file |
| 47 | +- `go.mod` & `go.sum`: Go module declarations and dependency tracking |
| 48 | + |
| 49 | +## Key Guidelines |
| 50 | + |
| 51 | +1. **User Experience Focus**: |
| 52 | + - Games should be intuitive and easy to play |
| 53 | + - Provide clear instructions and feedback to the user |
| 54 | + - Handle errors gracefully with helpful messages |
| 55 | + |
| 56 | +2. **Command Structure**: |
| 57 | + - New games should be added as subcommands to the main `gh game` command |
| 58 | + - Maintain consistency in command structure and naming |
| 59 | + |
| 60 | +3. **Terminal UI**: |
| 61 | + - Use the Charm libraries (lipgloss, etc.) for consistent UI rendering |
| 62 | + - Ensure games are playable in different terminal environments |
| 63 | + - Consider accessibility in UI design (e.g., color contrast) |
| 64 | + |
| 65 | +4. **Testing**: |
| 66 | + - Write unit tests for game logic |
| 67 | + - Include integration tests for command behavior |
| 68 | + - Mock external dependencies when testing |
| 69 | + |
| 70 | +5. **Documentation**: |
| 71 | + - Update README when adding new games or features |
| 72 | + - Include usage examples for each game |
| 73 | + - Document any complex algorithms or design decisions |
0 commit comments