Skip to content

Commit 83ec435

Browse files
russellwheatleyrussellwheatley
authored
chore: skill with validation commands for TS/JS development (#9012)
* chore: skill with validation commands for TS/JS development * chore: update ordering of commands * chore: add reference api and compare types scripts to validation * chore: remove duplication
1 parent ef89d7b commit 83ec435

1 file changed

Lines changed: 133 additions & 0 deletions

File tree

‎.agents/skills/ts-js-validation/SKILL.md‎

Lines changed: 133 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,133 @@
1+
---
2+
name: ts-js-validation
3+
description: Validate TypeScript and JavaScript changes in React Native Firebase by running the root prepare, TypeScript compile, API reference, Jest, formatting, and compare-types scripts. Use when a developer updates TS/JS code and wants the standard RNFB validation pass before handing off or committing.
4+
metadata:
5+
owner_team: react-native-firebase
6+
maintainer: russell.wheatley
7+
status: draft
8+
tags: typescript,javascript,testing,validation,formatting,react-native-firebase
9+
last_reviewed: "2026-05-08"
10+
version: "0.1.0"
11+
---
12+
13+
# React Native Firebase TS/JS Validation
14+
15+
## Scope
16+
17+
Use this skill to validate changes to TypeScript or JavaScript code in the React Native Firebase monorepo.
18+
19+
It is for developer-facing validation after editing package JS/TS sources, type tests, Jest tests, or shared TypeScript configuration. It runs the standard root validation commands that catch generated package setup issues, TypeScript errors, consumer type regressions, API reference regressions, Jest failures, formatting drift, and firebase-js-sdk type parity drift.
20+
21+
## Triggers
22+
23+
Use this skill when the user asks for:
24+
25+
- testing TS or JS changes
26+
- validating TypeScript or JavaScript edits before commit or handoff
27+
- running the standard JS validation pass for RNFB
28+
- checking whether package JS/TS changes compile and pass Jest
29+
- formatting package JS/TS code and then running validation
30+
31+
## Out-of-scope boundaries
32+
33+
Do not use this skill for:
34+
35+
- Android Java/Kotlin formatting or build validation
36+
- iOS Objective-C, Objective-C++, C++, Swift, or pod validation
37+
- documentation-only changes that do not affect JS/TS behavior
38+
- release validation that requires the full platform, emulator, Detox, or packaging matrix
39+
- migrating a package from JavaScript to TypeScript; use the TypeScript refactor or migration skills instead
40+
41+
## Defaults
42+
43+
Set one clear default path so the agent does not choose randomly between options.
44+
45+
- Default tool or method: run the canonical command sequence below from the repository root
46+
- Fallback when default fails: if a command fails, stop the sequence, inspect the failure, fix issues only when the user asked for fixes or the fix is clearly in the current change set, then rerun the failed command and any later commands
47+
- Why this default exists: `lerna:prepare`, both TypeScript compiles, API reference generation, Jest, formatting, and compare-types cover the JS/TS surfaces most likely to regress in this monorepo
48+
49+
## Command sequence
50+
51+
Run these root `package.json` scripts in order:
52+
53+
1. `yarn lerna:prepare`
54+
2. `yarn tsc:compile`
55+
3. `yarn tsc:compile:consumer`
56+
4. `yarn reference:api`
57+
5. `yarn tests:jest`
58+
6. `yarn format:js`
59+
7. `yarn compare:types`
60+
61+
## Gotchas
62+
63+
- `yarn format:js` writes changes across `packages/**/*.{js,ts,tsx}`. Check the diff after formatting and do not revert user changes.
64+
- Run commands from the repository root so workspace resolution, root `tsconfig.json`, and Jest configuration are consistent.
65+
- `yarn lerna:prepare` may rebuild or refresh package artifacts needed before TypeScript or tests run.
66+
- `yarn tsc:compile` checks the repository TypeScript project, while `yarn tsc:compile:consumer` checks the consumer-facing TypeScript project. Run both.
67+
- `yarn reference:api` runs TypeDoc and should come after consumer TypeScript compilation.
68+
- `yarn tests:jest` is the root Jest entrypoint. If it fails, report the failing test file or suite and the first actionable error rather than dumping the full output.
69+
- `yarn compare:types` installs dependencies under `.github/scripts/compare-types` before running the type parity comparison. Keep it last.
70+
- If validation is slow, keep the command running rather than replacing it with a narrower command unless the user explicitly asks for targeted validation.
71+
72+
## Workflow
73+
74+
1. Confirm the task is TS/JS validation and note any specific changed package or test files the user mentioned.
75+
2. Check whether the worktree has unrelated dirty files if the current task includes code edits or commit preparation.
76+
3. Run the command sequence from the repository root.
77+
4. If `yarn format:js` changes files, include those formatting changes in the validation context and inspect the relevant diff before continuing.
78+
5. If a command fails:
79+
- stop before running later commands
80+
- identify whether the failure belongs to the current TS/JS changes, pre-existing repo state, or missing local setup
81+
- fix current-change failures when authorized, then rerun the failed command and continue the remaining sequence
82+
6. Return a concise result with the commands run, pass/fail status, and any remaining blockers.
83+
84+
## Validation loop
85+
86+
Use this loop before finalizing:
87+
88+
1. Run the command sequence.
89+
2. If validation fails because of current TS/JS changes and fixing is in scope, fix the issue and rerun the failed command plus all later commands.
90+
3. If validation fails for unrelated or environment-specific reasons, stop and report the blocker with the command that failed and the shortest useful error summary.
91+
4. Only report success when every command in the sequence completes successfully.
92+
93+
## Output format
94+
95+
Use this template:
96+
97+
```markdown
98+
# TS/JS Validation
99+
100+
## Summary
101+
- passed | failed | blocked
102+
- one-sentence validation verdict
103+
104+
## Commands
105+
- `yarn lerna:prepare`: passed | failed | not run
106+
- `yarn tsc:compile`: passed | failed | not run
107+
- `yarn tsc:compile:consumer`: passed | failed | not run
108+
- `yarn reference:api`: passed | failed | not run
109+
- `yarn tests:jest`: passed | failed | not run
110+
- `yarn format:js`: passed | failed | changed files
111+
- `yarn compare:types`: passed | failed | not run
112+
113+
## Findings
114+
- failing suite, compiler error, or setup blocker if any
115+
116+
## Next actions
117+
1. next required action, only if validation did not fully pass
118+
```
119+
120+
## Constraints
121+
122+
- Keep responses factual and grounded in command output.
123+
- Do not skip any command in the default sequence unless the user explicitly narrows validation.
124+
- Do not claim validation passed unless `compare:types` ran after any formatting changes.
125+
- Do not revert unrelated local changes.
126+
- Avoid broad refactors while fixing validation failures.
127+
128+
## Additional resources
129+
130+
Load files only when needed:
131+
132+
- Read `package.json` if command names or script definitions need to be confirmed.
133+
- Read affected package `package.json`, `type-test.ts`, or nearby `__tests__/` files only when a failure needs package-specific diagnosis.

0 commit comments

Comments
 (0)