@iamdevlinph/codex-kit 1.1.1 → 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 +18 -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,
|
|
@@ -109,6 +113,17 @@ conditional procedures into validated project skills.
|
|
|
109
113
|
forms, dialogs, and page layouts) and identify their design-system primitives,
|
|
110
114
|
tokens, spacing, typography, responsive behavior, interactions, states, and
|
|
111
115
|
accessibility conventions. Reuse applicable components and patterns.
|
|
116
|
+
- For new or materially changed user-facing interfaces, preserve accessibility
|
|
117
|
+
as a baseline: prefer semantic elements and native controls; provide accessible
|
|
118
|
+
names, labels, instructions, errors, and state; support keyboard operation,
|
|
119
|
+
logical focus order, visible focus, and appropriate focus management; provide
|
|
120
|
+
meaningful text alternatives; maintain readable typography and sufficient
|
|
121
|
+
contrast; and never rely on color alone to communicate meaning. Use ARIA only
|
|
122
|
+
when native semantics are insufficient, and keep ARIA roles, properties, and
|
|
123
|
+
states valid and synchronized with behavior.
|
|
124
|
+
- When practical, verify changed interaction paths with the repository's
|
|
125
|
+
accessibility tooling and a manual keyboard/focus check. Report any unavailable
|
|
126
|
+
checks or known limitations.
|
|
112
127
|
- If no written standard exists but trustworthy repeated precedent does, derive
|
|
113
128
|
concise durable guidance in the project: always-on conventions belong in
|
|
114
129
|
`AGENTS.md`; feature-specific decisions and approved exceptions belong in
|
|
@@ -173,7 +188,9 @@ conditional procedures into validated project skills.
|
|
|
173
188
|
contains or what a helper guarantees at the call site without opening its
|
|
174
189
|
implementation. Avoid vague transformation names such as `normalized`,
|
|
175
190
|
`processed`, `result`, or `data` when a value- or behavior-specific name is
|
|
176
|
-
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.
|
|
177
194
|
- Keep naming conventions consistent within each code-owned object, schema,
|
|
178
195
|
type, and module. Do not mix identifier casing styles in the same
|
|
179
196
|
representation unless required by an external contract or framework.
|