You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: AGENTS.md
+8-1Lines changed: 8 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,4 +12,11 @@ Instructions for Codex when working in this repository:
12
12
- Where appropriate, add new unit and e2e tests.
13
13
- Never change the `next-env.d.ts` file.
14
14
- Never, ever change the blog contents because that is my personal writing and should never change.
15
-
15
+
- For distinct feature requests, create a new branch before making commits. Branch names must use the format `tc/name-of-feature`, where `tc` is fixed and `name-of-feature` is a short kebab-case description of the feature.
16
+
- Never, ever commit directly to the `main` or `master` branch. If the current branch is `main` or `master`, create and switch to a valid feature branch before committing any feature work.
17
+
- You may use `git` commands such as `git add`, `git checkout -b`, `git switch -c`, `git commit`, and `git push` as part of feature delivery, but only when working from a non-`main` and non-`master` branch.
18
+
- For the normal pull request workflow, you do not need to ask permission before using routine branch/PR commands such as `git checkout -b`, `git switch -c`, `git add`, `git commit`, `git push`, and `gh pr create`, as long as you still follow the branch, validation, and non-`main`/non-`master` rules in this file.
19
+
- For new feature work, prefer a pull request workflow: create the feature branch, implement the change, validate locally, push the branch, and open a pull request.
20
+
- Do not open a pull request until both `npm run test` and `npm run build` have completed successfully locally. If either validation fails, fix the issue before creating the pull request.
21
+
- Pull requests should include a detailed description of the changes, including the purpose of the feature, the main implementation details, any tests or validation performed, and any follow-up notes that would help with review.
22
+
- If the user explicitly says not to create a pull request, or explicitly asks for changes without branch creation or PR creation, skip the PR workflow and follow the user's instruction instead. In that case, you may still make the code changes locally, but do not open a PR unless the user later asks for one.
'Enrolling in a bootcamp takes some serious guts. Leaving behind a stable job and regular pay can be daunting. Even if your job is not stable or comfortable, going 12+ weeks without pay is extremely scary...',
'By the late afternoon on day five, I had squandered as many chances as a reasonable person could hope for. My buddies and I had hunted hard, and I was exhausted...',
'The stress was piling on. The "fires" were popping up left and right. Urgent phone calls had to be made. My head was spinning. I had to take a walk...',
'The order of operations is always the same. We park our trucks at odd angles in the alleyway behind the garage. The radio plays classic rock. We crack open beers immediately upon arrival...',
0 commit comments