Skip to content

Commit d3fac6a

Browse files
NathanWalkerNathanWalker
authored
chore: AGENTS.md with workspace skills (#11346)
[skip ci]
1 parent 70264e9 commit d3fac6a

30 files changed

Lines changed: 348 additions & 101 deletions

‎.agent/skills/feat/SKILL.md‎

Lines changed: 45 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,45 @@
1+
---
2+
name: feat
3+
description: Build a feature or enhancement end-to-end (GitHub issue or free-text description → plan → implement → test → PR). Use anytime you need to add functionality to a package in this workspace.
4+
argument-hint: [issue-number-or-description]
5+
---
6+
7+
# Feature Workflow
8+
9+
Conventions this workflow depends on (read the ones your change touches before writing code):
10+
11+
- [CorePlatformModules.md](./references/CorePlatformModules.md) — required before touching `packages/core` (platform-split files, handwritten `.d.ts`).
12+
- [CodeComments.md](./references/CodeComments.md) — comment rules for all TypeScript edits.
13+
- [WritingUnitTests.md](./references/WritingUnitTests.md) — test expectations and environment constraints.
14+
- [CONTRIBUTING.md](./references/CONTRIBUTING.md) — commit message format.
15+
16+
## Phase 1: Understand
17+
18+
- If given a GitHub issue number, fetch it: `gh issue view <number> --json title,body,labels,comments`. Otherwise treat the input as a free-text description; if empty, ask for one.
19+
- Summarize the user-facing goal, acceptance criteria, and edge cases before touching code.
20+
21+
## Phase 2: Ground in the codebase
22+
23+
- Find an existing module or feature similar to what you are building and use it as the pattern to follow — reference it by path in your plan.
24+
- Map the touch surface: which package, which modules, and for `packages/core` whether the change lands in `-common.ts`, both platform files, or all three — plus the neighboring `.d.ts`.
25+
26+
## Phase 3: Plan
27+
28+
Present a short plan before implementing: files to create/edit with a one-liner each, the test strategy, and any public API changes (these require `.d.ts` updates). Prefer the simplest solution that reuses existing patterns.
29+
30+
## Phase 4: Implement
31+
32+
- Follow the referenced conventions. Keep `.ios.ts` / `.android.ts` in parity; never leave one side diverged.
33+
- Public API changes update the neighboring `.d.ts` in the same change, with JSDoc in the `.d.ts`.
34+
35+
## Phase 5: Test
36+
37+
- Add or extend colocated `*.spec.ts` specs for shared-logic changes.
38+
- Run the focused tests first (`npx nx run core:test -t 'Name'`), then the full package target (`npx nx run core:test`) — it must be green.
39+
- Behavior that needs the real native runtime is covered in `apps/automated`, not unit tests; note it for the PR's manual test scenarios instead.
40+
41+
## Phase 6: Finish
42+
43+
- Format: `npx nx format:write`.
44+
- Commit with the conventional format, e.g. `feat(core): <subject>`.
45+
- Open the PR with `gh`, following [the PR template](../../../.github/PULL_REQUEST_TEMPLATE.md): reference the issue and include tests for the change.

‎.agent/skills/feat/references/CONTRIBUTING.md‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
../../../../tools/notes/CONTRIBUTING.md

‎.agent/skills/feat/references/CodeComments.md‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
../../../../tools/notes/CodeComments.md

‎.agent/skills/feat/references/CorePlatformModules.md‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
../../../../tools/notes/CorePlatformModules.md

‎.agent/skills/feat/references/WritingUnitTests.md‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
../../../../tools/notes/WritingUnitTests.md

‎.agent/skills/fix/SKILL.md‎

Lines changed: 45 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,45 @@
1+
---
2+
name: fix
3+
description: Debug and fix a bug end-to-end (GitHub issue or free-text report → trace → root cause → fix → test → PR). Use anytime you need to fix broken, throwing, or misbehaving code in this workspace.
4+
argument-hint: [issue-number-or-description]
5+
---
6+
7+
# Bug Fix Workflow
8+
9+
Conventions this workflow depends on (read the ones your change touches before writing code):
10+
11+
- [CorePlatformModules.md](./references/CorePlatformModules.md) — required before touching `packages/core` (platform-split files, handwritten `.d.ts`).
12+
- [CodeComments.md](./references/CodeComments.md) — comment rules for all TypeScript edits.
13+
- [WritingUnitTests.md](./references/WritingUnitTests.md) — test expectations and environment constraints.
14+
- [CONTRIBUTING.md](./references/CONTRIBUTING.md) — commit message format.
15+
16+
## Phase 1: Get the bug
17+
18+
- If given a GitHub issue number, fetch it: `gh issue view <number> --json title,body,labels,comments`. Otherwise collect the report from the user.
19+
- Extract the reproduction steps, environment (platform, versions), and any stack trace or error message — these point at the files to read first.
20+
21+
## Phase 2: Trace the code path
22+
23+
- Follow the failure from entry point to the error site. For `packages/core`, read BOTH platform files — a bug on one platform often means the implementations diverged.
24+
- Keep claims honest: distinguish what you proved by reading code (quote `file:line`) from what you suspect. Do not present a hunch as the root cause.
25+
26+
## Phase 3: Root cause
27+
28+
- Confirm the mechanism before fixing. When the logic is unit-testable, write a failing spec that reproduces the bug — it becomes the proof and the regression guard.
29+
- Grep for the same pattern elsewhere in the package; a bug rarely lives in only one place. List every instance found.
30+
31+
## Phase 4: Fix
32+
33+
- Apply the smallest change that fixes the root cause, not the symptom. Fix all instances found in the spread check.
34+
- Keep `.ios.ts` / `.android.ts` in parity; if the fix changes a public API, update the neighboring `.d.ts` in the same change.
35+
36+
## Phase 5: Verify
37+
38+
- The failing spec from Phase 3 must go green, and the full package target (`npx nx run core:test`) must pass.
39+
- Behavior only observable on a real device/simulator belongs in `apps/automated`; note it for the PR's manual test scenarios.
40+
41+
## Phase 6: Finish
42+
43+
- Format: `npx nx format:write`.
44+
- Commit with the conventional format, e.g. `fix(core): <subject>`.
45+
- Open the PR with `gh`, following [the PR template](../../../.github/PULL_REQUEST_TEMPLATE.md): reference the issue and include the regression test.

‎.agent/skills/fix/references/CONTRIBUTING.md‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
../../../../tools/notes/CONTRIBUTING.md

‎.agent/skills/fix/references/CodeComments.md‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
../../../../tools/notes/CodeComments.md

‎.agent/skills/fix/references/CorePlatformModules.md‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
../../../../tools/notes/CorePlatformModules.md

‎.agent/skills/fix/references/WritingUnitTests.md‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
../../../../tools/notes/WritingUnitTests.md

0 commit comments

Comments
 (0)