@iamdevlinph/codex-kit 1.1.2 → 1.1.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +17 -0
- package/assets/TEMPLATE_AGENTS.md +7 -1
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -43,6 +43,23 @@ The root orchestrator plans, routes, integrates, and validates. It handles clear
|
|
|
43
43
|
small changes directly and delegates broader discovery, implementation, or review
|
|
44
44
|
according to the installed `SUBAGENT_ROUTING.md` policy.
|
|
45
45
|
|
|
46
|
+
## Project guidance included
|
|
47
|
+
|
|
48
|
+
The canonical [project guidance template](TEMPLATE_AGENTS.md) provides reusable
|
|
49
|
+
defaults for coding agents across these themes:
|
|
50
|
+
|
|
51
|
+
- instruction scope, local adaptation, and specialized project skills;
|
|
52
|
+
- minimal changes that follow the repository's existing architecture and conventions;
|
|
53
|
+
- repository discovery plus consistent, accessible user-facing design;
|
|
54
|
+
- semantic structure, readable naming, purposeful comments, and named domain constants;
|
|
55
|
+
- focused testing, conservative dependency management, and meaningful validation;
|
|
56
|
+
- durable planning, repository safety, and concise completion reporting.
|
|
57
|
+
|
|
58
|
+
`project init` installs the template as a reference, not as a replacement for
|
|
59
|
+
existing active guidance. During reconciliation, Codex merges only applicable
|
|
60
|
+
rules into the project's `AGENTS.md` and preserves its local organization and
|
|
61
|
+
adaptations.
|
|
62
|
+
|
|
46
63
|
## Commands
|
|
47
64
|
|
|
48
65
|
| Action | Command |
|
|
@@ -92,6 +92,10 @@ conditional procedures into validated project skills.
|
|
|
92
92
|
- Reuse existing constants, schemas, enums, shared types, and components before
|
|
93
93
|
creating duplicates. Add reusable domain values at their existing source of
|
|
94
94
|
truth instead of scattering magic strings.
|
|
95
|
+
- Replace numeric literals that encode domain rules, limits, durations, units,
|
|
96
|
+
or protocol values with descriptively named constants. Universally obvious
|
|
97
|
+
structural values, such as basic indexes or empty-state values, may remain
|
|
98
|
+
inline.
|
|
95
99
|
- Promote repeated closed-set domain values used in production control flow to
|
|
96
100
|
feature-owned immutable runtime constants. Where the language supports it,
|
|
97
101
|
derive static types from that runtime source; keep incidental presentation,
|
|
@@ -184,7 +188,9 @@ conditional procedures into validated project skills.
|
|
|
184
188
|
contains or what a helper guarantees at the call site without opening its
|
|
185
189
|
implementation. Avoid vague transformation names such as `normalized`,
|
|
186
190
|
`processed`, `result`, or `data` when a value- or behavior-specific name is
|
|
187
|
-
available.
|
|
191
|
+
available. Prefer clear structure, and simplify or extract complex logic before
|
|
192
|
+
relying on comments. Use comments to explain non-obvious purpose, constraints,
|
|
193
|
+
invariants, tradeoffs, or workarounds, not to narrate statements.
|
|
188
194
|
- Keep naming conventions consistent within each code-owned object, schema,
|
|
189
195
|
type, and module. Do not mix identifier casing styles in the same
|
|
190
196
|
representation unless required by an external contract or framework.
|