@fprad0/skill-master-mcp 0.0.10 → 0.0.12
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +12 -1
- package/README.md +59 -10
- package/VERSION.md +3 -3
- package/bin/lib/client-config.mjs +293 -0
- package/bin/lib/menu-core.mjs +509 -131
- package/bin/lib/skill-installation.mjs +215 -0
- package/bin/skill-master-bootstrap-global.mjs +2 -1
- package/bin/skill-master-doctor.mjs +92 -32
- package/bin/skill-master-install-global-skills.mjs +4 -42
- package/bin/skill-master-install-project-skills.mjs +97 -0
- package/bin/skill-master-menu.mjs +91 -6
- package/bin/skill-master-register-clients.mjs +91 -115
- package/docs/operations/GUIA_MULTI_COMPUTADOR.md +262 -0
- package/docs/operations/GUIA_NPM_PUBLICO.md +147 -0
- package/docs/operations/MENU_VISUAL_EVIDENCE_2026-06-28.md +66 -0
- package/docs/operations/assets/menu-frame-compact.html +76 -0
- package/docs/operations/assets/menu-frame-compact.png +0 -0
- package/docs/operations/assets/menu-frame-large.html +84 -0
- package/docs/operations/assets/menu-frame-large.png +0 -0
- package/docs/operations/assets/menu-frame-running.html +80 -0
- package/docs/operations/assets/menu-frame-running.png +0 -0
- package/docs/operations/cross-platform-auth-transfer/ANALISE_COMPATIBILIDADE_MCP_2026-06-28.md +140 -0
- package/docs/operations/cross-platform-auth-transfer/README_TRANSFERENCIA.md +85 -0
- package/docs/operations/reborn-menu-cyberpunk-transfer/ANALISE_MENU_REBORN_CYBERPUNK_2026-06-28.md +174 -0
- package/docs/operations/reborn-menu-cyberpunk-transfer/HANDOFF_IMPLEMENTACAO_REBORN_CYBERPUNK_2026-06-28.md +119 -0
- package/docs/operations/reborn-menu-cyberpunk-transfer/ORDEM_DE_EXECUCAO_MENU_REBORN_CYBERPUNK.md +134 -0
- package/docs/operations/reborn-menu-cyberpunk-transfer/README_TRANSFERENCIA.md +84 -0
- package/docs/operations/reborn-menu-cyberpunk-transfer/README_TRANSFERENCIA_REBORN_PACKAGE.md +56 -0
- package/docs/operations/reborn-menu-cyberpunk-transfer/references/cyan-hud-frame-sheet.jpg +0 -0
- package/docs/operations/reborn-menu-cyberpunk-transfer/references/cyberpunk-pattern-sheet.jpg +0 -0
- package/docs/operations/reborn-menu-cyberpunk-transfer/references/fluid-workflow-windows.gif +0 -0
- package/docs/prompt-tasks/PROMPT_TASK_001_BOOTSTRAP_SKILL_MASTER_MCP.md +6 -0
- package/docs/prompt-tasks/PROMPT_TASK_002_AUTO_UPDATE_LAUNCHER.md +6 -0
- package/docs/prompt-tasks/PROMPT_TASK_003_REMOTE_MANIFEST_AND_RELEASES.md +6 -0
- package/docs/prompt-tasks/PROMPT_TASK_004_MULTI_USER_DISTRIBUTION.md +6 -0
- package/docs/prompt-tasks/PROMPT_TASK_005_SECURITY_AND_QUALITY_GATE.md +6 -0
- package/docs/prompt-tasks/PROMPT_TASK_006_MASTER_ACIONAMENTO_APRENDIZADO.md +83 -0
- package/docs/prompt-tasks/PROMPT_TASK_007_PERSONA_ORQUESTRADORA.md +88 -0
- package/docs/prompt-tasks/PROMPT_TASK_008_PROMPT_ROUTER_MODOS_ATIVACAO.md +156 -0
- package/docs/prompt-tasks/PROMPT_TASK_009_PIPELINE_APRENDIZADO_SUCESSO.md +105 -0
- package/docs/prompt-tasks/PROMPT_TASK_010_EVALS_GOVERNANCA_ATIVACAO.md +119 -0
- package/docs/prompt-tasks/PROMPT_TASK_011_MENU_NOTIFICACOES_NOTION.md +120 -0
- package/docs/prompt-tasks/PROMPT_TASK_012_MENU_CYBERPUNK_PIXEL_FRAME.md +123 -0
- package/docs/prompt-tasks/PROMPT_TASK_013_MENU_FLUID_DNA_ANIMATION.md +114 -0
- package/docs/prompt-tasks/PROMPT_TASK_014_MENU_FUNCTIONAL_PARITY_QA.md +157 -0
- package/docs/prompt-tasks/PROMPT_TASK_015_TRANSFER_RELEASE_HANDOFF.md +127 -0
- package/docs/prompt-tasks/PROMPT_TASK_016_CROSS_PLATFORM_MCP_AUTH_REGISTRATION.md +107 -0
- package/docs/prompt-tasks/PROMPT_TASK_018_NPM_PUBLISH_2FA_SETUP.md +80 -0
- package/docs/prompt-tasks/PROMPT_TASK_MASTER_EXECUTOR.md +6 -0
- package/docs/skill-candidates/v0.0.11/frontend-dev-guidelines/SKILL.md +399 -0
- package/docs/skill-candidates/v0.0.11/frontend-dev-guidelines/resources/common-patterns.md +331 -0
- package/docs/skill-candidates/v0.0.11/frontend-dev-guidelines/resources/complete-examples.md +872 -0
- package/docs/skill-candidates/v0.0.11/frontend-dev-guidelines/resources/component-patterns.md +502 -0
- package/docs/skill-candidates/v0.0.11/frontend-dev-guidelines/resources/data-fetching.md +767 -0
- package/docs/skill-candidates/v0.0.11/frontend-dev-guidelines/resources/file-organization.md +502 -0
- package/docs/skill-candidates/v0.0.11/frontend-dev-guidelines/resources/loading-and-error-states.md +501 -0
- package/docs/skill-candidates/v0.0.11/frontend-dev-guidelines/resources/performance.md +406 -0
- package/docs/skill-candidates/v0.0.11/frontend-dev-guidelines/resources/routing-guide.md +364 -0
- package/docs/skill-candidates/v0.0.11/frontend-dev-guidelines/resources/styling-guide.md +428 -0
- package/docs/skill-candidates/v0.0.11/frontend-dev-guidelines/resources/typescript-standards.md +418 -0
- package/docs/skill-candidates/v0.0.11/git-version-control-ops/SKILL.md +34 -0
- package/docs/skill-candidates/v0.0.11/go-engineering/SKILL.md +34 -0
- package/docs/skill-candidates/v0.0.11/java-engineering/SKILL.md +34 -0
- package/docs/skill-candidates/v0.0.11/javascript-engineering/SKILL.md +34 -0
- package/docs/skill-candidates/v0.0.11/json-contract-design/SKILL.md +34 -0
- package/docs/skill-candidates/v0.0.11/multi-client-mcp-ops/SKILL.md +36 -0
- package/docs/skill-candidates/v0.0.11/nextjs/SKILL.md +745 -0
- package/docs/skill-candidates/v0.0.11/nextjs/agents/openai.yaml +3 -0
- package/docs/skill-candidates/v0.0.11/nextjs/references/app-router-files.md +94 -0
- package/docs/skill-candidates/v0.0.11/python-engineering/SKILL.md +34 -0
- package/docs/skill-candidates/v0.0.11/ruby-engineering/SKILL.md +34 -0
- package/docs/skill-candidates/v0.0.11/senior-fullstack/SKILL.md +209 -0
- package/docs/skill-candidates/v0.0.11/senior-fullstack/references/architecture_patterns.md +103 -0
- package/docs/skill-candidates/v0.0.11/senior-fullstack/references/development_workflows.md +103 -0
- package/docs/skill-candidates/v0.0.11/senior-fullstack/references/tech_stack_guide.md +103 -0
- package/docs/skill-candidates/v0.0.11/senior-fullstack/scripts/code_quality_analyzer.py +114 -0
- package/docs/skill-candidates/v0.0.11/senior-fullstack/scripts/fullstack_scaffolder.py +114 -0
- package/docs/skill-candidates/v0.0.11/senior-fullstack/scripts/project_scaffolder.py +114 -0
- package/docs/skill-candidates/v0.0.11/shadcn/SKILL.md +573 -0
- package/docs/skill-candidates/v0.0.11/shadcn/agents/openai.yaml +3 -0
- package/docs/skill-candidates/v0.0.11/sql-postgresql-engineering/SKILL.md +34 -0
- package/docs/skill-candidates/v0.0.11/terminal-shell-ops/SKILL.md +34 -0
- package/docs/skill-candidates/v0.0.11/typescript-expert/SKILL.md +429 -0
- package/docs/skill-candidates/v0.0.11/typescript-expert/references/tsconfig-strict.json +92 -0
- package/docs/skill-candidates/v0.0.11/typescript-expert/references/typescript-cheatsheet.md +383 -0
- package/docs/skill-candidates/v0.0.11/typescript-expert/references/utility-types.ts +335 -0
- package/docs/skill-candidates/v0.0.11/typescript-expert/scripts/ts_diagnostic.py +203 -0
- package/docs/skill-candidates/v0.0.11/ui-component-primitives/SKILL.md +34 -0
- package/docs/skill-candidates/v0.0.11/web-mobile-design-systems/SKILL.md +34 -0
- package/docs/skill-candidates/v0.0.11/windows-linux-platform-ops/SKILL.md +34 -0
- package/docs/skill-candidates/v0.0.12/csharp-senior-master-engineering/SKILL.md +32 -0
- package/docs/skill-candidates/v0.0.12/css-senior-master-engineering/SKILL.md +32 -0
- package/docs/skill-candidates/v0.0.12/go-senior-master-engineering/SKILL.md +32 -0
- package/docs/skill-candidates/v0.0.12/html-senior-master-engineering/SKILL.md +32 -0
- package/docs/skill-candidates/v0.0.12/javascript-senior-master-engineering/SKILL.md +32 -0
- package/docs/skill-candidates/v0.0.12/json-senior-master-engineering/SKILL.md +32 -0
- package/docs/skill-candidates/v0.0.12/python-senior-master-engineering/SKILL.md +32 -0
- package/docs/skill-candidates/v0.0.12/react-senior-master-engineering/SKILL.md +32 -0
- package/docs/skill-candidates/v0.0.12/ruby-senior-master-engineering/SKILL.md +32 -0
- package/docs/skill-candidates/v0.0.12/senior-master-code-optimizer/SKILL.md +48 -0
- package/docs/skill-candidates/v0.0.12/sql-senior-master-engineering/SKILL.md +31 -0
- package/docs/skill-candidates/v0.0.12/typescript-senior-master-engineering/SKILL.md +35 -0
- package/examples/client-configs/claude-code.commands.md +11 -7
- package/manifests/channels/beta.json +7 -7
- package/manifests/channels/stable.json +8 -8
- package/package.json +14 -2
- package/scripts/render-menu-evidence.mjs +130 -0
- package/scripts/verify-menu-actions.mjs +117 -0
|
@@ -0,0 +1,203 @@
|
|
|
1
|
+
#!/usr/bin/env python3
|
|
2
|
+
"""
|
|
3
|
+
TypeScript Project Diagnostic Script
|
|
4
|
+
Analyzes TypeScript projects for configuration, performance, and common issues.
|
|
5
|
+
"""
|
|
6
|
+
|
|
7
|
+
import subprocess
|
|
8
|
+
import sys
|
|
9
|
+
import os
|
|
10
|
+
import json
|
|
11
|
+
from pathlib import Path
|
|
12
|
+
|
|
13
|
+
def run_cmd(cmd: str) -> str:
|
|
14
|
+
"""Run shell command and return output."""
|
|
15
|
+
try:
|
|
16
|
+
result = subprocess.run(cmd, shell=True, capture_output=True, text=True)
|
|
17
|
+
return result.stdout + result.stderr
|
|
18
|
+
except Exception as e:
|
|
19
|
+
return str(e)
|
|
20
|
+
|
|
21
|
+
def check_versions():
|
|
22
|
+
"""Check TypeScript and Node versions."""
|
|
23
|
+
print("\n📦 Versions:")
|
|
24
|
+
print("-" * 40)
|
|
25
|
+
|
|
26
|
+
ts_version = run_cmd("npx tsc --version 2>/dev/null").strip()
|
|
27
|
+
node_version = run_cmd("node -v 2>/dev/null").strip()
|
|
28
|
+
|
|
29
|
+
print(f" TypeScript: {ts_version or 'Not found'}")
|
|
30
|
+
print(f" Node.js: {node_version or 'Not found'}")
|
|
31
|
+
|
|
32
|
+
def check_tsconfig():
|
|
33
|
+
"""Analyze tsconfig.json settings."""
|
|
34
|
+
print("\n⚙️ TSConfig Analysis:")
|
|
35
|
+
print("-" * 40)
|
|
36
|
+
|
|
37
|
+
tsconfig_path = Path("tsconfig.json")
|
|
38
|
+
if not tsconfig_path.exists():
|
|
39
|
+
print("⚠️ tsconfig.json not found")
|
|
40
|
+
return
|
|
41
|
+
|
|
42
|
+
try:
|
|
43
|
+
with open(tsconfig_path) as f:
|
|
44
|
+
config = json.load(f)
|
|
45
|
+
|
|
46
|
+
compiler_opts = config.get("compilerOptions", {})
|
|
47
|
+
|
|
48
|
+
# Check strict mode
|
|
49
|
+
if compiler_opts.get("strict"):
|
|
50
|
+
print("✅ Strict mode enabled")
|
|
51
|
+
else:
|
|
52
|
+
print("⚠️ Strict mode NOT enabled")
|
|
53
|
+
|
|
54
|
+
# Check important flags
|
|
55
|
+
flags = {
|
|
56
|
+
"noUncheckedIndexedAccess": "Unchecked index access protection",
|
|
57
|
+
"noImplicitOverride": "Implicit override protection",
|
|
58
|
+
"skipLibCheck": "Skip lib check (performance)",
|
|
59
|
+
"incremental": "Incremental compilation"
|
|
60
|
+
}
|
|
61
|
+
|
|
62
|
+
for flag, desc in flags.items():
|
|
63
|
+
status = "✅" if compiler_opts.get(flag) else "⚪"
|
|
64
|
+
print(f" {status} {desc}: {compiler_opts.get(flag, 'not set')}")
|
|
65
|
+
|
|
66
|
+
# Check module settings
|
|
67
|
+
print(f"\n Module: {compiler_opts.get('module', 'not set')}")
|
|
68
|
+
print(f" Module Resolution: {compiler_opts.get('moduleResolution', 'not set')}")
|
|
69
|
+
print(f" Target: {compiler_opts.get('target', 'not set')}")
|
|
70
|
+
|
|
71
|
+
except json.JSONDecodeError:
|
|
72
|
+
print("❌ Invalid JSON in tsconfig.json")
|
|
73
|
+
|
|
74
|
+
def check_tooling():
|
|
75
|
+
"""Detect TypeScript tooling ecosystem."""
|
|
76
|
+
print("\n🛠️ Tooling Detection:")
|
|
77
|
+
print("-" * 40)
|
|
78
|
+
|
|
79
|
+
pkg_path = Path("package.json")
|
|
80
|
+
if not pkg_path.exists():
|
|
81
|
+
print("⚠️ package.json not found")
|
|
82
|
+
return
|
|
83
|
+
|
|
84
|
+
try:
|
|
85
|
+
with open(pkg_path) as f:
|
|
86
|
+
pkg = json.load(f)
|
|
87
|
+
|
|
88
|
+
all_deps = {**pkg.get("dependencies", {}), **pkg.get("devDependencies", {})}
|
|
89
|
+
|
|
90
|
+
tools = {
|
|
91
|
+
"biome": "Biome (linter/formatter)",
|
|
92
|
+
"eslint": "ESLint",
|
|
93
|
+
"prettier": "Prettier",
|
|
94
|
+
"vitest": "Vitest (testing)",
|
|
95
|
+
"jest": "Jest (testing)",
|
|
96
|
+
"turborepo": "Turborepo (monorepo)",
|
|
97
|
+
"turbo": "Turbo (monorepo)",
|
|
98
|
+
"nx": "Nx (monorepo)",
|
|
99
|
+
"lerna": "Lerna (monorepo)"
|
|
100
|
+
}
|
|
101
|
+
|
|
102
|
+
for tool, desc in tools.items():
|
|
103
|
+
for dep in all_deps:
|
|
104
|
+
if tool in dep.lower():
|
|
105
|
+
print(f" ✅ {desc}")
|
|
106
|
+
break
|
|
107
|
+
|
|
108
|
+
except json.JSONDecodeError:
|
|
109
|
+
print("❌ Invalid JSON in package.json")
|
|
110
|
+
|
|
111
|
+
def check_monorepo():
|
|
112
|
+
"""Check for monorepo configuration."""
|
|
113
|
+
print("\n📦 Monorepo Check:")
|
|
114
|
+
print("-" * 40)
|
|
115
|
+
|
|
116
|
+
indicators = [
|
|
117
|
+
("pnpm-workspace.yaml", "PNPM Workspace"),
|
|
118
|
+
("lerna.json", "Lerna"),
|
|
119
|
+
("nx.json", "Nx"),
|
|
120
|
+
("turbo.json", "Turborepo")
|
|
121
|
+
]
|
|
122
|
+
|
|
123
|
+
found = False
|
|
124
|
+
for file, name in indicators:
|
|
125
|
+
if Path(file).exists():
|
|
126
|
+
print(f" ✅ {name} detected")
|
|
127
|
+
found = True
|
|
128
|
+
|
|
129
|
+
if not found:
|
|
130
|
+
print(" ⚪ No monorepo configuration detected")
|
|
131
|
+
|
|
132
|
+
def check_type_errors():
|
|
133
|
+
"""Run quick type check."""
|
|
134
|
+
print("\n🔍 Type Check:")
|
|
135
|
+
print("-" * 40)
|
|
136
|
+
|
|
137
|
+
result = run_cmd("npx tsc --noEmit 2>&1 | head -20")
|
|
138
|
+
if "error TS" in result:
|
|
139
|
+
errors = result.count("error TS")
|
|
140
|
+
print(f" ❌ {errors}+ type errors found")
|
|
141
|
+
print(result[:500])
|
|
142
|
+
else:
|
|
143
|
+
print(" ✅ No type errors")
|
|
144
|
+
|
|
145
|
+
def check_any_usage():
|
|
146
|
+
"""Check for any type usage."""
|
|
147
|
+
print("\n⚠️ 'any' Type Usage:")
|
|
148
|
+
print("-" * 40)
|
|
149
|
+
|
|
150
|
+
result = run_cmd("grep -r ': any' --include='*.ts' --include='*.tsx' src/ 2>/dev/null | wc -l")
|
|
151
|
+
count = result.strip()
|
|
152
|
+
if count and count != "0":
|
|
153
|
+
print(f" ⚠️ Found {count} occurrences of ': any'")
|
|
154
|
+
sample = run_cmd("grep -rn ': any' --include='*.ts' --include='*.tsx' src/ 2>/dev/null | head -5")
|
|
155
|
+
if sample:
|
|
156
|
+
print(sample)
|
|
157
|
+
else:
|
|
158
|
+
print(" ✅ No explicit 'any' types found")
|
|
159
|
+
|
|
160
|
+
def check_type_assertions():
|
|
161
|
+
"""Check for type assertions."""
|
|
162
|
+
print("\n⚠️ Type Assertions (as):")
|
|
163
|
+
print("-" * 40)
|
|
164
|
+
|
|
165
|
+
result = run_cmd("grep -r ' as ' --include='*.ts' --include='*.tsx' src/ 2>/dev/null | grep -v 'import' | wc -l")
|
|
166
|
+
count = result.strip()
|
|
167
|
+
if count and count != "0":
|
|
168
|
+
print(f" ⚠️ Found {count} type assertions")
|
|
169
|
+
else:
|
|
170
|
+
print(" ✅ No type assertions found")
|
|
171
|
+
|
|
172
|
+
def check_performance():
|
|
173
|
+
"""Check type checking performance."""
|
|
174
|
+
print("\n⏱️ Type Check Performance:")
|
|
175
|
+
print("-" * 40)
|
|
176
|
+
|
|
177
|
+
result = run_cmd("npx tsc --extendedDiagnostics --noEmit 2>&1 | grep -E 'Check time|Files:|Lines:|Nodes:'")
|
|
178
|
+
if result.strip():
|
|
179
|
+
for line in result.strip().split('\n'):
|
|
180
|
+
print(f" {line}")
|
|
181
|
+
else:
|
|
182
|
+
print(" ⚠️ Could not measure performance")
|
|
183
|
+
|
|
184
|
+
def main():
|
|
185
|
+
print("=" * 50)
|
|
186
|
+
print("🔍 TypeScript Project Diagnostic Report")
|
|
187
|
+
print("=" * 50)
|
|
188
|
+
|
|
189
|
+
check_versions()
|
|
190
|
+
check_tsconfig()
|
|
191
|
+
check_tooling()
|
|
192
|
+
check_monorepo()
|
|
193
|
+
check_any_usage()
|
|
194
|
+
check_type_assertions()
|
|
195
|
+
check_type_errors()
|
|
196
|
+
check_performance()
|
|
197
|
+
|
|
198
|
+
print("\n" + "=" * 50)
|
|
199
|
+
print("✅ Diagnostic Complete")
|
|
200
|
+
print("=" * 50)
|
|
201
|
+
|
|
202
|
+
if __name__ == "__main__":
|
|
203
|
+
main()
|
|
@@ -0,0 +1,34 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: ui-component-primitives
|
|
3
|
+
description: "Design and implement reusable UI primitives and interaction components such as buttons, inputs, cards, modals, dropdowns, icons, toasts and navigation with accessibility and state clarity."
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# UI Component Primitives
|
|
7
|
+
|
|
8
|
+
Use this skill when the task is about reusable UI building blocks rather than page-level layout alone.
|
|
9
|
+
|
|
10
|
+
## Workflow
|
|
11
|
+
|
|
12
|
+
- Start from the interaction contract: trigger, focus, keyboard, dismissal and state changes.
|
|
13
|
+
- Define component API, variants and states before styling details.
|
|
14
|
+
- Treat modal, dropdown, popover and navigation primitives as accessibility-sensitive systems.
|
|
15
|
+
- Keep icons, labels, spacing and motion consistent with the design system.
|
|
16
|
+
- Validate both mouse and keyboard behavior.
|
|
17
|
+
|
|
18
|
+
## Coverage
|
|
19
|
+
|
|
20
|
+
- Components, primitives, modals, dropdowns, popovers, icons, buttons, forms and feedback.
|
|
21
|
+
- Variants, states, accessibility, composition and design-system reuse.
|
|
22
|
+
- Desktop and mobile interaction expectations.
|
|
23
|
+
|
|
24
|
+
## Reference Anchors
|
|
25
|
+
|
|
26
|
+
- WAI-ARIA APG: `https://www.w3.org/WAI/ARIA/apg/`
|
|
27
|
+
- Material Design components: `https://m3.material.io/components`
|
|
28
|
+
|
|
29
|
+
## Guardrails
|
|
30
|
+
|
|
31
|
+
- Do not ship inaccessible focus, escape or keyboard behavior.
|
|
32
|
+
- Do not let visual styling outrun interaction correctness.
|
|
33
|
+
- Do not duplicate primitives without a strong reason.
|
|
34
|
+
- Do not ignore empty, loading, disabled or error states.
|
|
@@ -0,0 +1,34 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: web-mobile-design-systems
|
|
3
|
+
description: "Shape coherent web, mobile and app-facing design systems with attention to layout, hierarchy, navigation, responsive behavior, visual language and product-level usability."
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Web Mobile Design Systems
|
|
7
|
+
|
|
8
|
+
Use this skill when the task spans layout, visual systems and product interaction across desktop and mobile surfaces.
|
|
9
|
+
|
|
10
|
+
## Workflow
|
|
11
|
+
|
|
12
|
+
- Begin from information hierarchy, navigation and user goal flow.
|
|
13
|
+
- Design responsive layout behavior before polishing isolated screens.
|
|
14
|
+
- Keep typography, spacing, surface hierarchy and motion consistent across breakpoints.
|
|
15
|
+
- Reuse patterns deliberately across web and mobile contexts while respecting platform differences.
|
|
16
|
+
- Validate readability, rhythm and interaction clarity on both narrow and wide layouts.
|
|
17
|
+
|
|
18
|
+
## Coverage
|
|
19
|
+
|
|
20
|
+
- Layout, web design, mobile, app surfaces, UX/UI systems and responsive behavior.
|
|
21
|
+
- Navigation, forms, cards, sections, density, hierarchy, motion and visual consistency.
|
|
22
|
+
- Design-system framing for product teams.
|
|
23
|
+
|
|
24
|
+
## Reference Anchors
|
|
25
|
+
|
|
26
|
+
- Material Design 3: `https://m3.material.io/`
|
|
27
|
+
- Apple Human Interface Guidelines: `https://developer.apple.com/design/human-interface-guidelines/`
|
|
28
|
+
|
|
29
|
+
## Guardrails
|
|
30
|
+
|
|
31
|
+
- Do not confuse visual complexity with product quality.
|
|
32
|
+
- Do not force desktop structure onto mobile flows.
|
|
33
|
+
- Do not treat responsiveness as a late patch.
|
|
34
|
+
- Do not sacrifice clarity for novelty.
|
|
@@ -0,0 +1,34 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: windows-linux-platform-ops
|
|
3
|
+
description: "Operate Windows and Linux developer environments with focus on filesystems, PATH, permissions, services, shells, package managers and cross-platform reliability."
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Windows Linux Platform Ops
|
|
7
|
+
|
|
8
|
+
Use this skill when the task depends on OS-specific environment behavior across Windows or Linux.
|
|
9
|
+
|
|
10
|
+
## Workflow
|
|
11
|
+
|
|
12
|
+
- Identify the target OS, shell, path conventions and permission model first.
|
|
13
|
+
- Treat filesystem, service, environment and package-manager differences explicitly.
|
|
14
|
+
- Prefer cross-platform instructions only when they are truly equivalent.
|
|
15
|
+
- Keep operator-facing paths, config locations and restart steps concrete.
|
|
16
|
+
- Validate on the real platform path when possible.
|
|
17
|
+
|
|
18
|
+
## Coverage
|
|
19
|
+
|
|
20
|
+
- Windows and Linux paths, permissions, PATH, services, package managers and shells.
|
|
21
|
+
- Config-file locations, CLI registration, restart/reload behavior and troubleshooting.
|
|
22
|
+
- Cross-platform readiness for developer tooling.
|
|
23
|
+
|
|
24
|
+
## Reference Anchors
|
|
25
|
+
|
|
26
|
+
- Windows docs: `https://learn.microsoft.com/windows/`
|
|
27
|
+
- Linux kernel docs: `https://www.kernel.org/doc/html/latest/`
|
|
28
|
+
|
|
29
|
+
## Guardrails
|
|
30
|
+
|
|
31
|
+
- Do not assume Linux semantics on Windows paths or permissions.
|
|
32
|
+
- Do not give cross-platform instructions that are only half-true.
|
|
33
|
+
- Do not omit restart/reload requirements for service or shell config changes.
|
|
34
|
+
- Do not hide elevated-privilege requirements.
|
|
@@ -0,0 +1,32 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: csharp-senior-master-engineering
|
|
3
|
+
description: "Senior master C# and .NET engineering for clean, fast, secure and maintainable C# applications, ASP.NET Core services, CLIs, libraries, data access and background workers. Use when writing, organizing, refactoring, optimizing, testing or hardening C# code."
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# C# Senior Master Engineering
|
|
7
|
+
|
|
8
|
+
Use this skill for C# and .NET work with production-grade expectations.
|
|
9
|
+
|
|
10
|
+
## Workflow
|
|
11
|
+
|
|
12
|
+
- Inspect solution structure, target framework, project files, dependency injection, configuration and test projects.
|
|
13
|
+
- Keep domain logic separate from controllers, transport, persistence and infrastructure.
|
|
14
|
+
- Use nullable reference types, async/await, cancellation tokens and dependency lifetimes deliberately.
|
|
15
|
+
- Prefer simple services and explicit models before complex inheritance or reflection.
|
|
16
|
+
- Validate with `dotnet test`, `dotnet build`, analyzers or targeted smoke execution.
|
|
17
|
+
|
|
18
|
+
## Optimization Rules
|
|
19
|
+
|
|
20
|
+
- Avoid sync-over-async, unnecessary allocations, repeated serialization, N+1 data access and overbroad service lifetimes.
|
|
21
|
+
- Use spans, pooling or low-level optimizations only when profiling or hot path evidence supports them.
|
|
22
|
+
- Keep LINQ readable and check generated database behavior when using ORMs.
|
|
23
|
+
|
|
24
|
+
## Security Rules
|
|
25
|
+
|
|
26
|
+
- Validate request/input boundaries, preserve auth/authorization, avoid injection and protect secrets in configuration.
|
|
27
|
+
- Use parameterized queries and safe serializers.
|
|
28
|
+
- Keep logging useful without exposing tokens, passwords or personal data.
|
|
29
|
+
|
|
30
|
+
## Completion Standard
|
|
31
|
+
|
|
32
|
+
- State behavior, validation, performance reasoning and remaining operational risks.
|
|
@@ -0,0 +1,32 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: css-senior-master-engineering
|
|
3
|
+
description: "Senior master CSS engineering for layout, responsive behavior, design systems, performance, accessibility and maintainable styling. Use when writing, organizing, refactoring, optimizing or hardening CSS, SCSS, modules, utility styles or component styling."
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# CSS Senior Master Engineering
|
|
7
|
+
|
|
8
|
+
Use this skill when styling must remain responsive, maintainable and efficient.
|
|
9
|
+
|
|
10
|
+
## Workflow
|
|
11
|
+
|
|
12
|
+
- Inspect the styling model: global CSS, modules, utility classes, CSS-in-JS, tokens or design system.
|
|
13
|
+
- Fix layout structure before adding decorative overrides.
|
|
14
|
+
- Use stable sizing constraints, logical properties, container-aware layouts and accessible focus states.
|
|
15
|
+
- Keep selectors predictable and avoid specificity escalation.
|
|
16
|
+
- Validate in relevant viewport sizes and interaction states.
|
|
17
|
+
|
|
18
|
+
## Optimization Rules
|
|
19
|
+
|
|
20
|
+
- Remove duplicate declarations, dead selectors, overbroad transitions and layout thrashing triggers.
|
|
21
|
+
- Prefer CSS variables and tokens for repeated design decisions.
|
|
22
|
+
- Avoid one-off hacks when a reusable component or layout primitive is clearer.
|
|
23
|
+
|
|
24
|
+
## Security Rules
|
|
25
|
+
|
|
26
|
+
- Avoid rendering untrusted content into CSS values.
|
|
27
|
+
- Do not use remote assets or fonts without considering privacy, reliability and CSP.
|
|
28
|
+
- Keep hidden content and focus order accessible.
|
|
29
|
+
|
|
30
|
+
## Completion Standard
|
|
31
|
+
|
|
32
|
+
- State layout impact, responsive behavior and validation evidence.
|
|
@@ -0,0 +1,32 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: go-senior-master-engineering
|
|
3
|
+
description: "Senior master Go engineering for clean package design, services, CLIs, concurrency, performance, security and maintainability. Use when writing, refactoring, organizing, testing or hardening Go code, APIs, workers or command-line tools."
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Go Senior Master Engineering
|
|
7
|
+
|
|
8
|
+
Use this skill for Go work that must be simple, explicit and reliable.
|
|
9
|
+
|
|
10
|
+
## Workflow
|
|
11
|
+
|
|
12
|
+
- Inspect `go.mod`, package boundaries, commands, tests and runtime entrypoints.
|
|
13
|
+
- Keep errors wrapped with context and returned deliberately.
|
|
14
|
+
- Treat `context.Context`, goroutine lifecycle, channels and cancellation as design concerns.
|
|
15
|
+
- Prefer concrete types until an interface removes real coupling.
|
|
16
|
+
- Validate with `go test ./...`, `go test -race` when concurrency changed, `go vet` or targeted command execution.
|
|
17
|
+
|
|
18
|
+
## Optimization Rules
|
|
19
|
+
|
|
20
|
+
- Avoid unnecessary allocations, reflection, global state, goroutine leaks and repeated network/database work.
|
|
21
|
+
- Keep packages small and cohesive; avoid deep folder taxonomies.
|
|
22
|
+
- Use benchmarks only when performance claims matter.
|
|
23
|
+
|
|
24
|
+
## Security Rules
|
|
25
|
+
|
|
26
|
+
- Validate external input, file paths, HTTP parameters and SQL arguments.
|
|
27
|
+
- Avoid command injection, unsafe temporary files and silent auth failures.
|
|
28
|
+
- Keep timeouts and cancellation explicit around external calls.
|
|
29
|
+
|
|
30
|
+
## Completion Standard
|
|
31
|
+
|
|
32
|
+
- Explain validation run, concurrency assumptions and operational risks.
|
|
@@ -0,0 +1,32 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: html-senior-master-engineering
|
|
3
|
+
description: "Senior master HTML engineering for semantic structure, accessibility, forms, metadata, SEO-safe markup, security and maintainability. Use when writing, organizing, refactoring, validating or hardening HTML documents, templates, components or generated markup."
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# HTML Senior Master Engineering
|
|
7
|
+
|
|
8
|
+
Use this skill when markup structure determines usability, accessibility or integration quality.
|
|
9
|
+
|
|
10
|
+
## Workflow
|
|
11
|
+
|
|
12
|
+
- Inspect the document, template system, framework and generated output path.
|
|
13
|
+
- Prefer semantic elements, clear heading order, labels, landmarks and valid nesting.
|
|
14
|
+
- Keep forms explicit: labels, names, autocomplete, validation messages and error associations.
|
|
15
|
+
- Preserve existing component conventions and server/client rendering assumptions.
|
|
16
|
+
- Validate with browser inspection, accessibility checks, tests or generated markup review when available.
|
|
17
|
+
|
|
18
|
+
## Optimization Rules
|
|
19
|
+
|
|
20
|
+
- Remove redundant wrapper elements, inaccessible clickable divs and invalid nesting.
|
|
21
|
+
- Keep markup readable and stable for styling and automation selectors.
|
|
22
|
+
- Avoid text or layout structures that break on small screens.
|
|
23
|
+
|
|
24
|
+
## Security Rules
|
|
25
|
+
|
|
26
|
+
- Escape untrusted text and attributes.
|
|
27
|
+
- Avoid unsafe inline script/style injection.
|
|
28
|
+
- Treat links, forms and embedded content as trust boundaries.
|
|
29
|
+
|
|
30
|
+
## Completion Standard
|
|
31
|
+
|
|
32
|
+
- State semantic, accessibility and validation impact.
|
|
@@ -0,0 +1,32 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: javascript-senior-master-engineering
|
|
3
|
+
description: "Senior master JavaScript and Node.js engineering for clean runtime behavior, async correctness, performance, security and maintainability. Use when writing, organizing, refactoring, optimizing, testing or hardening JavaScript in browser, Node.js, workers or tooling."
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# JavaScript Senior Master Engineering
|
|
7
|
+
|
|
8
|
+
Use this skill for JavaScript work where runtime behavior matters more than type-level design.
|
|
9
|
+
|
|
10
|
+
## Workflow
|
|
11
|
+
|
|
12
|
+
- Identify runtime first: browser, Node.js, worker, edge, CLI or test harness.
|
|
13
|
+
- Inspect `package.json`, module mode, bundler/test setup and current style.
|
|
14
|
+
- Keep async flows explicit: promises, retries, cancellation, streams, events and shutdown paths.
|
|
15
|
+
- Separate domain logic from transport, DOM, filesystem, database and process boundaries.
|
|
16
|
+
- Validate with existing one-shot scripts, tests, build or direct execution.
|
|
17
|
+
|
|
18
|
+
## Optimization Rules
|
|
19
|
+
|
|
20
|
+
- Remove avoidable promise waterfalls, duplicated serialization, repeated DOM queries, needless deep cloning and unused dependencies.
|
|
21
|
+
- Avoid hidden shared mutable state unless lifecycle is clear.
|
|
22
|
+
- Prefer platform APIs and existing utilities over new dependencies.
|
|
23
|
+
|
|
24
|
+
## Security Rules
|
|
25
|
+
|
|
26
|
+
- Avoid `eval`, unsafe HTML injection, unsafe shell composition and unvalidated JSON or URL input.
|
|
27
|
+
- Keep secrets out of client bundles, logs and error surfaces.
|
|
28
|
+
- Preserve CORS, auth, CSRF and permission boundaries.
|
|
29
|
+
|
|
30
|
+
## Completion Standard
|
|
31
|
+
|
|
32
|
+
- Report behavior, validation and compatibility risks plainly.
|
|
@@ -0,0 +1,32 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: json-senior-master-engineering
|
|
3
|
+
description: "Senior master JSON contract engineering for schemas, API payloads, config files, events, validation, compatibility, naming and integration safety. Use when designing, refactoring, validating or hardening JSON structures and machine-readable contracts."
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# JSON Senior Master Engineering
|
|
7
|
+
|
|
8
|
+
Use this skill for JSON contracts where compatibility and validation matter.
|
|
9
|
+
|
|
10
|
+
## Workflow
|
|
11
|
+
|
|
12
|
+
- Identify producers, consumers, versioning expectations and failure behavior.
|
|
13
|
+
- Define required, optional, nullable and deprecated fields explicitly.
|
|
14
|
+
- Keep names, casing, enum values, timestamps and identifiers consistent.
|
|
15
|
+
- Prefer JSON Schema or runtime validation where payloads cross trust boundaries.
|
|
16
|
+
- Validate with realistic examples, edge cases and backwards compatibility checks.
|
|
17
|
+
|
|
18
|
+
## Optimization Rules
|
|
19
|
+
|
|
20
|
+
- Remove redundant nesting, ambiguous duplicate fields and oversized payload fragments.
|
|
21
|
+
- Keep config files readable and stable for diffs.
|
|
22
|
+
- Avoid schemas that are stricter than the real producer or looser than the consumer can handle.
|
|
23
|
+
|
|
24
|
+
## Security Rules
|
|
25
|
+
|
|
26
|
+
- Reject unexpected fields when trust boundaries require it.
|
|
27
|
+
- Do not accept unsafe URLs, paths, commands or serialized code through JSON.
|
|
28
|
+
- Avoid leaking secrets in examples and fixtures.
|
|
29
|
+
|
|
30
|
+
## Completion Standard
|
|
31
|
+
|
|
32
|
+
- State compatibility impact, schema behavior and validation examples.
|
|
@@ -0,0 +1,32 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: python-senior-master-engineering
|
|
3
|
+
description: "Senior master Python engineering for clean, fast, secure and maintainable Python services, CLIs, scripts, APIs, automation, packages and data workflows. Use when writing, refactoring, organizing, typing, optimizing, testing or hardening Python code."
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Python Senior Master Engineering
|
|
7
|
+
|
|
8
|
+
Use this skill for Python work that needs production-grade clarity and safety.
|
|
9
|
+
|
|
10
|
+
## Workflow
|
|
11
|
+
|
|
12
|
+
- Inspect runtime version, dependency manager, entrypoints, package layout and test commands.
|
|
13
|
+
- Keep imports, I/O, environment reads, file access, subprocess calls and network calls explicit.
|
|
14
|
+
- Use type hints where they clarify contracts; avoid type noise inside obvious local code.
|
|
15
|
+
- Prefer standard library tools unless a dependency is already established or clearly justified.
|
|
16
|
+
- Validate with focused tests, direct script execution, `pytest`, type checks or package build when available.
|
|
17
|
+
|
|
18
|
+
## Optimization Rules
|
|
19
|
+
|
|
20
|
+
- Remove unnecessary loops, repeated I/O, repeated parsing, hidden global state and expensive work at import time.
|
|
21
|
+
- Use generators, streaming or batching where data size makes it useful.
|
|
22
|
+
- Keep error handling precise; never hide import/runtime failures behind broad `except`.
|
|
23
|
+
|
|
24
|
+
## Security Rules
|
|
25
|
+
|
|
26
|
+
- Validate untrusted input, file paths, JSON, YAML, subprocess args and database parameters.
|
|
27
|
+
- Avoid shell interpolation, unsafe pickle use and logging secrets.
|
|
28
|
+
- Keep permissions, tokens and environment assumptions visible.
|
|
29
|
+
|
|
30
|
+
## Completion Standard
|
|
31
|
+
|
|
32
|
+
- State what was validated and what runtime assumptions remain.
|
|
@@ -0,0 +1,32 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: react-senior-master-engineering
|
|
3
|
+
description: "Senior master React engineering for component architecture, rendering performance, state design, accessibility, security and maintainability. Use when writing, organizing, refactoring, optimizing, testing or hardening React components, hooks, pages and UI systems."
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# React Senior Master Engineering
|
|
7
|
+
|
|
8
|
+
Use this skill for React code that must be ergonomic, fast and predictable.
|
|
9
|
+
|
|
10
|
+
## Workflow
|
|
11
|
+
|
|
12
|
+
- Inspect framework, React version, routing, state model, component system and test setup.
|
|
13
|
+
- Keep rendering data flow explicit: props, state, effects, server/client boundaries and async loading.
|
|
14
|
+
- Prefer composition over prop drilling and avoid global state unless the shared lifecycle is real.
|
|
15
|
+
- Preserve existing design-system conventions.
|
|
16
|
+
- Validate with typecheck, tests, build and browser or Playwright checks when UI behavior changed.
|
|
17
|
+
|
|
18
|
+
## Optimization Rules
|
|
19
|
+
|
|
20
|
+
- Fix unnecessary re-renders by improving state shape, component boundaries and derived data flow before adding memoization.
|
|
21
|
+
- Avoid effects for pure derivation; keep side effects idempotent and cleanup-safe.
|
|
22
|
+
- Use `useDeferredValue`, transitions or framework-native data loading only when they match the user experience.
|
|
23
|
+
|
|
24
|
+
## Security Rules
|
|
25
|
+
|
|
26
|
+
- Avoid unsafe HTML injection and untrusted URL rendering.
|
|
27
|
+
- Preserve auth, route guards, CSRF assumptions and server/client data boundaries.
|
|
28
|
+
- Keep secrets out of client bundles.
|
|
29
|
+
|
|
30
|
+
## Completion Standard
|
|
31
|
+
|
|
32
|
+
- State UI behavior changed, accessibility impact, render/performance reasoning and validation evidence.
|
|
@@ -0,0 +1,32 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: ruby-senior-master-engineering
|
|
3
|
+
description: "Senior master Ruby engineering for clean, expressive, secure and maintainable Ruby scripts, gems, CLIs, services and Rails-adjacent code. Use when writing, organizing, refactoring, optimizing, testing or hardening Ruby code."
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Ruby Senior Master Engineering
|
|
7
|
+
|
|
8
|
+
Use this skill for Ruby work that needs clear behavior and runtime safety.
|
|
9
|
+
|
|
10
|
+
## Workflow
|
|
11
|
+
|
|
12
|
+
- Inspect Ruby version, Gemfile, entrypoints, tests and app style first.
|
|
13
|
+
- Preserve idiomatic Ruby readability without hiding behavior behind excessive metaprogramming.
|
|
14
|
+
- Keep side effects, filesystem access, shell calls, network calls and database calls isolated.
|
|
15
|
+
- Prefer small objects or functions when they reduce coupling; avoid ceremony for small scripts.
|
|
16
|
+
- Validate with existing tests, `bundle exec`, direct CLI execution or targeted smoke checks.
|
|
17
|
+
|
|
18
|
+
## Optimization Rules
|
|
19
|
+
|
|
20
|
+
- Remove repeated queries, repeated parsing, hidden global mutation and unnecessary gem additions.
|
|
21
|
+
- Keep allocation-heavy loops and string building intentional in hot paths.
|
|
22
|
+
- Match project style instead of importing patterns from other ecosystems.
|
|
23
|
+
|
|
24
|
+
## Security Rules
|
|
25
|
+
|
|
26
|
+
- Validate file paths, shell args, params and serialized data.
|
|
27
|
+
- Avoid unsafe `eval`, unsafe YAML loading and shell interpolation.
|
|
28
|
+
- Keep secrets out of logs and exceptions.
|
|
29
|
+
|
|
30
|
+
## Completion Standard
|
|
31
|
+
|
|
32
|
+
- Report behavior, runtime version assumptions and validation evidence.
|
|
@@ -0,0 +1,48 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: senior-master-code-optimizer
|
|
3
|
+
description: "Senior master code optimization and hardening across languages. Use when asked to write, refactor, organize, simplify, speed up, secure, test, reduce complexity, or improve code quality in TypeScript, JavaScript, Python, Go, SQL, JSON, Ruby, React, HTML, CSS, C# or mixed systems."
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Senior Master Code Optimizer
|
|
7
|
+
|
|
8
|
+
Use this skill as the general engineering gate before making broad code quality changes.
|
|
9
|
+
|
|
10
|
+
## Operating Standard
|
|
11
|
+
|
|
12
|
+
- Inspect the real project structure, entrypoints, dependency model, tests and conventions before editing.
|
|
13
|
+
- Optimize for correctness first, then simplicity, then performance, then cleverness.
|
|
14
|
+
- Remove accidental complexity: duplicated branches, needless wrappers, broad abstractions, dead code and unclear naming.
|
|
15
|
+
- Keep behavior stable unless the user explicitly asked for behavior change.
|
|
16
|
+
- Treat security as part of code quality: validate inputs, isolate side effects, avoid secret exposure and preserve auth boundaries.
|
|
17
|
+
- Prefer smaller functions with explicit responsibilities, but do not split code into noisy fragments without a real readability or testability gain.
|
|
18
|
+
- Validate with the narrowest trustworthy commands available: typecheck, lint, tests, build, query plan, smoke script or direct execution.
|
|
19
|
+
|
|
20
|
+
## Language Routing
|
|
21
|
+
|
|
22
|
+
- TypeScript: use `typescript-senior-master-engineering` with `typescript-expert` when type safety or build behavior matters.
|
|
23
|
+
- JavaScript: use `javascript-senior-master-engineering` for runtime, async, Node.js or browser behavior.
|
|
24
|
+
- Python: use `python-senior-master-engineering` for services, scripts, CLIs, APIs and automation.
|
|
25
|
+
- Go: use `go-senior-master-engineering` for package design, concurrency, services and CLIs.
|
|
26
|
+
- SQL: use `sql-senior-master-engineering` for schemas, queries, migrations and data integrity.
|
|
27
|
+
- JSON: use `json-senior-master-engineering` for contracts, schemas, config and integration payloads.
|
|
28
|
+
- Ruby: use `ruby-senior-master-engineering` for Ruby scripts, gems, services and Rails-adjacent code.
|
|
29
|
+
- React: use `react-senior-master-engineering` for components, state, rendering, accessibility and frontend performance.
|
|
30
|
+
- HTML: use `html-senior-master-engineering` for semantic markup, accessibility and document structure.
|
|
31
|
+
- CSS: use `css-senior-master-engineering` for layout, responsive behavior, maintainable styling and performance.
|
|
32
|
+
- C#: use `csharp-senior-master-engineering` for .NET, ASP.NET Core, services, CLIs and libraries.
|
|
33
|
+
|
|
34
|
+
## Change Discipline
|
|
35
|
+
|
|
36
|
+
- Start with the smallest coherent patch that resolves the issue.
|
|
37
|
+
- Prefer project-native utilities, style and test commands over introducing new tools.
|
|
38
|
+
- Avoid speculative rewrites. Refactor only where it reduces risk, duplication, latency, memory use or maintenance cost.
|
|
39
|
+
- Keep public contracts stable unless migration is part of the task.
|
|
40
|
+
- Explain residual risks plainly. Do not claim code is bug-free; report what was actually validated.
|
|
41
|
+
|
|
42
|
+
## Review Checklist
|
|
43
|
+
|
|
44
|
+
- Behavior: inputs, outputs, errors, edge cases and backwards compatibility remain clear.
|
|
45
|
+
- Performance: avoid unnecessary allocations, repeated I/O, repeated parsing, N+1 queries and avoidable re-renders.
|
|
46
|
+
- Security: sanitize boundaries, preserve permissions, avoid injection, avoid unsafe deserialization and never leak secrets.
|
|
47
|
+
- Maintainability: names, modules, functions and tests make future changes easier.
|
|
48
|
+
- Validation: one-shot checks passed or the reason they were not run is explicit.
|