code-quality-review

Name: code-quality-review
Author: samilozturk

29stars0forks

How to install code-quality-review?

samilozturk/agentlint/code-quality-review

$npx -y skills add samilozturk/agentlint --skill code-quality-review

Installs into the current project.

Summary

Review Agent Lint changes for strict TypeScript, docs consistency, and safe public-surface updates. Use when reviewing code changes, tightening implementation quality, or checking if docs/tests/context must change together. Trigger on "review", "lint", "typecheck", "docs consiste

Files · 1

View on GitHub

SKILL.md

1	# Skill: Code Quality Review
2
3	## When to Use
4
5	Use this skill when:
6	- reviewing a PR or local diff in this repo
7	- checking strict TypeScript and lint compliance
8	- validating docs/tests/context alignment for public surface changes
9	- looking for risky regressions in CLI, MCP, core, or shared packages
10
11	## Purpose
12
13	Apply Agent Lint's repository-specific review standards so changes stay type-safe, testable, documented, and aligned with public behavior.
14
15	## Scope
16
17	### Included
18	- TypeScript correctness
19	- public-surface drift
20	- docs/test alignment
21	- context-artifact maintenance triggers
22	- package boundary and dependency-flow checks
23
24	### Excluded
25	- subjective style nitpicks without repository evidence
26	- unrelated product strategy decisions
27
28	## Inputs
29
30	- `diff-summary`
31	- `touched-files`
32	- `public-surface-change`: yes/no
33	- `review-goal`
34
35	## Step-by-step Execution
36
37	1. Read the touched files and classify them by package and responsibility.
38	2. Check dependency direction: `shared <- core <- mcp` and `shared <- core <- cli`.
39	3. Look for strict-typing violations, missing tests, stale docs, or public-surface drift.
40	4. If CLI commands, MCP tools/resources, or supported clients changed, require docs/test updates in the same change.
41	5. If structure/config/dependency changes occurred, call out context-artifact updates as part of review.
42	6. Return findings ordered by risk: correctness, release/doc drift, maintainability.
43
44	## Output Contract
45
46	Return:
47	- blocking findings
48	- non-blocking improvements
49	- files/docs/tests that must be updated
50	- exact verification commands
51
52	## Verification Commands
53
54	```bash
55	pnpm run build
56	pnpm run release-status
57	pnpm run typecheck
58	pnpm run lint
59	pnpm run test
60	```
61
62	## Evidence Format
63
64	- finding severity
65	- affected file(s)
66	- why it matters in Agent Lint specifically
67	- recommended fix
68	- verification command(s)
69
70	## Safety / DONTs
71
72	- Do not suggest `any`, `@ts-ignore`, or band-aid casts.
73	- Do not ignore docs consistency when public surface changes.
74	- Do not add MCP-side file writes or stateful behavior.
75	- Do not recommend skipping verification for package or client-facing changes.
76
77	## Gotchas
78
79	- Public-surface changes often require README and docs-consistency test updates together.
80	- Context maintenance artifacts can drift after structural changes even when runtime code still works.
81	- A "small" change in `shared` or `core` can affect both published packages.
82	- Repo-specific constraints matter more than generic review advice.

People who liked this also viewed

6 picks

Type

code-quality-review

29stars0forks

View on GitHub

How to install code-quality-review?

samilozturk/agentlint/code-quality-review

$npx -y skills add samilozturk/agentlint --skill code-quality-review

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Skill: Code Quality Review
2
3	## When to Use
4
5	Use this skill when:
6	- reviewing a PR or local diff in this repo
7	- checking strict TypeScript and lint compliance
8	- validating docs/tests/context alignment for public surface changes
9	- looking for risky regressions in CLI, MCP, core, or shared packages
10
11	## Purpose
12
13	Apply Agent Lint's repository-specific review standards so changes stay type-safe, testable, documented, and aligned with public behavior.
14
15	## Scope
16
17	### Included
18	- TypeScript correctness
19	- public-surface drift
20	- docs/test alignment
21	- context-artifact maintenance triggers
22	- package boundary and dependency-flow checks
23
24	### Excluded
25	- subjective style nitpicks without repository evidence
26	- unrelated product strategy decisions
27
28	## Inputs
29
30	- `diff-summary`
31	- `touched-files`
32	- `public-surface-change`: yes/no
33	- `review-goal`
34
35	## Step-by-step Execution
36
37	1. Read the touched files and classify them by package and responsibility.
38	2. Check dependency direction: `shared <- core <- mcp` and `shared <- core <- cli`.
39	3. Look for strict-typing violations, missing tests, stale docs, or public-surface drift.
40	4. If CLI commands, MCP tools/resources, or supported clients changed, require docs/test updates in the same change.
41	5. If structure/config/dependency changes occurred, call out context-artifact updates as part of review.
42	6. Return findings ordered by risk: correctness, release/doc drift, maintainability.
43
44	## Output Contract
45
46	Return:
47	- blocking findings
48	- non-blocking improvements
49	- files/docs/tests that must be updated
50	- exact verification commands
51
52	## Verification Commands
53
54	```bash
55	pnpm run build
56	pnpm run release-status
57	pnpm run typecheck
58	pnpm run lint
59	pnpm run test
60	```
61
62	## Evidence Format
63
64	- finding severity
65	- affected file(s)
66	- why it matters in Agent Lint specifically
67	- recommended fix
68	- verification command(s)
69
70	## Safety / DONTs
71
72	- Do not suggest `any`, `@ts-ignore`, or band-aid casts.
73	- Do not ignore docs consistency when public surface changes.
74	- Do not add MCP-side file writes or stateful behavior.
75	- Do not recommend skipping verification for package or client-facing changes.
76
77	## Gotchas
78
79	- Public-surface changes often require README and docs-consistency test updates together.
80	- Context maintenance artifacts can drift after structural changes even when runtime code still works.
81	- A "small" change in `shared` or `core` can affect both published packages.
82	- Repo-specific constraints matter more than generic review advice.

People who liked this also viewed

6 picks

Type