|
| 1 | +# Devkit Development Guide |
| 2 | + |
| 3 | +## Project Scope |
| 4 | + |
| 5 | +Devkit is a CLI application written in Go. It is designed to: |
| 6 | + |
| 7 | +- Initialize projects and generate project scaffolding. |
| 8 | +- Provide and apply reusable code templates. |
| 9 | +- Download, install, or prepare device-related dependencies. |
| 10 | +- Create, update, and configure files required by projects or local development environments. |
| 11 | + |
| 12 | +All implementations should be designed for CLI use. Commands must be clear, behavior must be predictable, errors must be actionable, and cross-platform compatibility should be considered. |
| 13 | + |
| 14 | +## Go Development Guidelines |
| 15 | + |
| 16 | +- This is a Go project. New code must follow official Go conventions and be formatted with `gofmt`. |
| 17 | +- Prefer the Go standard library. Evaluate third-party packages only when the standard library cannot reasonably satisfy the requirement. |
| 18 | +- Avoid reinventing existing solutions. When a mature implementation already exists for a general-purpose feature, use a reliable package instead of building a custom replacement. |
| 19 | +- Do not introduce a large package, a complex dependency tree, or a high maintenance burden for a small feature. The benefit of a dependency must clearly outweigh its cost. |
| 20 | +- Keep implementations simple, maintain clear module boundaries, and provide useful error messages for user-visible failures. |
| 21 | + |
| 22 | +## Third-Party Package Selection |
| 23 | + |
| 24 | +Conduct thorough research before introducing any third-party Go package. Do not select a package based on assumptions or a single metric. |
| 25 | + |
| 26 | +Research must consider at least: |
| 27 | + |
| 28 | +- GitHub stars, usage, import counts, and general community adoption. |
| 29 | +- Recent commits and releases, issue and pull request responsiveness, and maintainer activity. |
| 30 | +- Compatibility with the Go version used by this project and its primary target platforms. |
| 31 | +- API stability, documentation quality, license, dependency tree size, and known security risks. |
| 32 | +- Newer, lighter, or more actively maintained alternatives that provide similar functionality. |
| 33 | + |
| 34 | +Selection principles: |
| 35 | + |
| 36 | +- Prefer widely adopted packages with strong usage, high GitHub stars, good documentation, and active maintenance. |
| 37 | +- High usage and star counts are not sufficient on their own. Do not select a package solely because of its historical popularity if it is unmaintained, outdated, or superseded by a modern alternative. |
| 38 | +- When candidates have similar maturity, prefer the package with more recent development, regular releases, and compatibility with modern Go tooling. |
| 39 | +- Briefly document the evaluated candidates, selection rationale, important tradeoffs, and links to the official documentation or source repository. |
| 40 | + |
| 41 | +## Dependency Installation Approval |
| 42 | + |
| 43 | +The user must run every `go get` command manually. Agents and automated tools must never run `go get` themselves. |
| 44 | + |
| 45 | +When a task requires a new third-party dependency: |
| 46 | + |
| 47 | +1. Complete the requirement analysis, package research, and package selection first. |
| 48 | +2. Stop immediately when the dependency needs to be installed. Do not run `go get`, and do not bypass this process by manually editing `go.mod` or `go.sum`. |
| 49 | +3. Tell the user the exact command to run, such as `go get example.com/module@version`. |
| 50 | +4. Provide links to the selected package's official documentation and source repository, together with a short explanation of the selection rationale. |
| 51 | +5. Wait for the user to confirm that the command has been completed. |
| 52 | +6. Continue implementing code that depends on the package and perform subsequent verification only after receiving confirmation. |
| 53 | + |
| 54 | +If a task does not require a new dependency, implementation may continue without triggering this approval process. |
0 commit comments