writing-typescript

Name: writing-typescript
Author: alexei-led

5installs5forks

How to install writing-typescript?

alexei-led/cc-thingz/writing-typescript

$npx -y skills add alexei-led/cc-thingz --skill writing-typescript

Installs into the current project.

Summary

Use for .ts and .tsx, Node.js services, React apps, typed APIs, and TypeScript design advice. - Do not use for Go, Python, Rust, plain HTML/CSS/JS, or server-rendered templates. - Follow the repository's TypeScript version, tsconfig, package manager, framework, test runner,

Files · 1

View on GitHub

SKILL.md

1	# TypeScript Development
2
3	## Scope
4
5	- Use for `.ts` and `.tsx`, Node.js services, React apps, typed APIs, and TypeScript design advice.
6	- Do not use for Go, Python, Rust, plain HTML/CSS/JS, or server-rendered templates.
7	- Follow the repository's TypeScript version, tsconfig, package manager, framework, test runner, and lint rules.
8	- Do not add dependencies or switch frameworks unless the project already uses them or the user approves.
9
10	## Reference Reads
11
12	- Read only the references needed for the task.
13	- Read `references/principles.md` for non-trivial TypeScript changes or reviews.
14	- Read `references/patterns.md` for data models, validation, async flow, or module boundaries.
15	- Read `references/react.md` for `.tsx`, hooks, component state, forms, performance, or React tests.
16	- Read `references/testing.md` before adding or changing TypeScript tests.
17	- Read `references/linting.md` before changing lint config, lint commands, or slow lint workflows.
18
19	## Defaults
20
21	- Preserve strict typing; do not weaken compiler options to pass checks.
22	- Use `unknown` for untrusted input. Avoid `any`; isolate it only for unavoidable interop.
23	- Validate API, JSON, env, storage, and form data at the boundary before typed use.
24	- Use discriminated unions for variants, async state, and domain states.
25	- Use guard clauses and focused helpers. Avoid deep nesting, global state, and mixed concerns.
26	- Use the project's error conventions; prefer unions or `Result` for recoverable failures.
27	- Pass dependencies explicitly; avoid inheritance, singletons, and hidden module state.
28	- Avoid unsafe casts, non-null assertions, broad index signatures, boolean-flag state, and new app enums where literal unions fit.
29
30	## Comments and JSDoc
31
32	- Use JSDoc or TSDoc for exported APIs and non-obvious public properties or methods.
33	- Avoid merely restating property, parameter, or type names.
34	- Add implementation comments only for non-obvious constraints, invariants, side effects, tradeoffs, or interoperability quirks.
35	- Keep comments short. Move longer rationale to docs, issue links, or design notes.
36	- Do not comment obvious code.
37	- Keep tests readable without comments; add one only for unobvious fixtures, timers, concurrency, browser setup, or regression context.
38
39	## Testing and Verification
40
41	- For behavior changes, include success and failure tests. For React, cover affected user-visible states.
42	- Use focused test, typecheck, and lint commands for the changed file, package, or workspace while editing.
43	- Run the project's configured typecheck, tests, lint, and format checks for the changed package or workspace before final output.
44	- Keep coverage, end-to-end tests, and expensive debug diagnostics off the hot path unless they are the task.
45	- Report checks run, failures, and unchecked risks. Do not claim success without a clean check or an explicit reason it was skipped.
46
47	## Failure Handling
48
49	- If project root is unclear, identify the nearest `package.json` and `tsconfig.json`; in monorepos, state the selected package.
50	- If strict compiler options are absent, do not silently weaken new code. State the gap and keep the change locally type-safe.
51	- If validation needs a schema/form library not already used, ask before adding it; otherwise use a narrow type guard.
52	- If typecheck or tests fail, quote the exact diagnostic or failing assertion, state the cause, and fix the type/model boundary before widening types.
53	- Do not run destructive shell commands. For broad or risky changes, state the risk and ask before acting.
54
55	## Final Response
56
57	- Files changed:
58	- Checks:
59	- Skipped checks:
60	- Risks/follow-ups:

People who liked this also viewed

6 picks

Type

writing-typescript

5installs5forks

View on GitHub

How to install writing-typescript?

alexei-led/cc-thingz/writing-typescript

$npx -y skills add alexei-led/cc-thingz --skill writing-typescript

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# TypeScript Development
2
3	## Scope
4
5	- Use for `.ts` and `.tsx`, Node.js services, React apps, typed APIs, and TypeScript design advice.
6	- Do not use for Go, Python, Rust, plain HTML/CSS/JS, or server-rendered templates.
7	- Follow the repository's TypeScript version, tsconfig, package manager, framework, test runner, and lint rules.
8	- Do not add dependencies or switch frameworks unless the project already uses them or the user approves.
9
10	## Reference Reads
11
12	- Read only the references needed for the task.
13	- Read `references/principles.md` for non-trivial TypeScript changes or reviews.
14	- Read `references/patterns.md` for data models, validation, async flow, or module boundaries.
15	- Read `references/react.md` for `.tsx`, hooks, component state, forms, performance, or React tests.
16	- Read `references/testing.md` before adding or changing TypeScript tests.
17	- Read `references/linting.md` before changing lint config, lint commands, or slow lint workflows.
18
19	## Defaults
20
21	- Preserve strict typing; do not weaken compiler options to pass checks.
22	- Use `unknown` for untrusted input. Avoid `any`; isolate it only for unavoidable interop.
23	- Validate API, JSON, env, storage, and form data at the boundary before typed use.
24	- Use discriminated unions for variants, async state, and domain states.
25	- Use guard clauses and focused helpers. Avoid deep nesting, global state, and mixed concerns.
26	- Use the project's error conventions; prefer unions or `Result` for recoverable failures.
27	- Pass dependencies explicitly; avoid inheritance, singletons, and hidden module state.
28	- Avoid unsafe casts, non-null assertions, broad index signatures, boolean-flag state, and new app enums where literal unions fit.
29
30	## Comments and JSDoc
31
32	- Use JSDoc or TSDoc for exported APIs and non-obvious public properties or methods.
33	- Avoid merely restating property, parameter, or type names.
34	- Add implementation comments only for non-obvious constraints, invariants, side effects, tradeoffs, or interoperability quirks.
35	- Keep comments short. Move longer rationale to docs, issue links, or design notes.
36	- Do not comment obvious code.
37	- Keep tests readable without comments; add one only for unobvious fixtures, timers, concurrency, browser setup, or regression context.
38
39	## Testing and Verification
40
41	- For behavior changes, include success and failure tests. For React, cover affected user-visible states.
42	- Use focused test, typecheck, and lint commands for the changed file, package, or workspace while editing.
43	- Run the project's configured typecheck, tests, lint, and format checks for the changed package or workspace before final output.
44	- Keep coverage, end-to-end tests, and expensive debug diagnostics off the hot path unless they are the task.
45	- Report checks run, failures, and unchecked risks. Do not claim success without a clean check or an explicit reason it was skipped.
46
47	## Failure Handling
48
49	- If project root is unclear, identify the nearest `package.json` and `tsconfig.json`; in monorepos, state the selected package.
50	- If strict compiler options are absent, do not silently weaken new code. State the gap and keep the change locally type-safe.
51	- If validation needs a schema/form library not already used, ask before adding it; otherwise use a narrow type guard.
52	- If typecheck or tests fail, quote the exact diagnostic or failing assertion, state the cause, and fix the type/model boundary before widening types.
53	- Do not run destructive shell commands. For broad or risky changes, state the risk and ask before acting.
54
55	## Final Response
56
57	- Files changed:
58	- Checks:
59	- Skipped checks:
60	- Risks/follow-ups:

People who liked this also viewed

6 picks

Type