Skip to content

Commit b1220b0

Browse files
tinywavescodex
andcommitted
docs: add project and agent guidelines
Co-authored-by: Codex <codex@openai.com>
1 parent 9b8b222 commit b1220b0

2 files changed

Lines changed: 78 additions & 0 deletions

File tree

‎AGENTS.md‎

Lines changed: 54 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,54 @@
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.

‎README.md‎

Lines changed: 24 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1 +1,25 @@
11
# devkit
2+
3+
Devkit is a Go-based CLI for automating project setup and local development environment preparation.
4+
5+
It provides a consistent entry point for tasks that would otherwise require repeatedly copying templates, downloading tools, or editing configuration files by hand.
6+
7+
## What Devkit Does
8+
9+
- Initialize projects and generate project scaffolding.
10+
- Create files from reusable code templates.
11+
- Download tools and device-related dependencies.
12+
- Generate or update project configuration files.
13+
- Prepare consistent local development environments.
14+
15+
## Goals
16+
17+
- **Repeatable:** Produce consistent results across projects and machines.
18+
- **Practical:** Automate common setup work without hiding important behavior.
19+
- **Extensible:** Make it straightforward to add new initializers, templates, downloads, and configuration tasks.
20+
- **Cross-platform:** Keep commands and generated output portable whenever possible.
21+
- **Safe:** Provide clear output and actionable errors, especially when changing files or installing tools.
22+
23+
## Technology
24+
25+
Devkit is implemented in Go and targets a simple, portable command-line experience.

0 commit comments

Comments
 (0)