Reusable baseline files for repositories that should be easy for Codex agents to inspect, modify, build, review, and release.
The kit has two modes:
-`agent-quickstart.md`: shortest prompts and decision tree for Codex agents.
-`new-repository.md`: agent workflow for a fresh repository.
-`existing-project.md`: agent workflow for upgrading an existing repository.
The files are intentionally universal. They do not assume Electron, React, Node, or any single stack. Node examples are included only because many Codex projects use them.
## Agent Goal
Give every repository the same predictable anchor points:
```text
.
|-- AGENTS.md
|-- .codex/
| `-- project.md
|-- .gitea/
| `-- workflows/
| `-- build.yml
|-- docs/
| |-- release-checklist.md
| `-- security-review.md
|-- blueprint.md
|-- blueprint.json
|-- README.md
|-- SECURITY.md
|-- CHANGELOG.md
`-- .gitignore
```
Use only the files that fit the project. For a tiny script repo, `AGENTS.md`, `README.md`, `SECURITY.md`, and `CHANGELOG.md` may be enough. For an app or releasable tool, add the runner, release checklist, and README blueprint workflow.
When working with private repositories on `git.wilkensxl.de`, Codex agents may find a local `GITEA_TOKEN` environment variable on the machine.
Use `GITEA_TOKEN` only for read-oriented Gitea API checks unless the user explicitly asks for a write action. Typical safe checks include repository metadata, workflow run status, and package-read visibility. Never print the token, commit it, or copy it into workflow files.
Example status endpoint:
```text
GET https://git.wilkensxl.de/api/v1/repos/REPOSITORY_OWNER/REPOSITORY_NAME/actions/runs
Authorization: token GITEA_TOKEN
```
`REGISTRY_TOKEN` is still the intended secret name for CI package publishing inside `.gitea/workflows/build.yml`.
After pushing commits that add or change a Gitea workflow, Codex agents must check the resulting workflow run before finishing. If the run is still pending or in progress, report that status and keep checking when the user expects the agent loop to continue. If the run fails, inspect the failing job/logs, fix the issue when it is in scope, commit, push, and check the next run.