TypeScript project structure, strict tsconfig, module resolution, path aliases, shared types, and monorepo patterns
90
84%
Does it follow best practices?
Impact
100%
1.09xAverage score across 5 eval scenarios
Passed
No known issues
{
"instruction": "Put shared types in a common location imported by both client and server",
"relevant_when": "Agent builds a fullstack TypeScript application with client and server",
"context": "Types shared between frontend and backend (API request/response shapes, entity types, string union types) must be defined once in a shared directory and imported by both sides. No duplicate interface definitions. Use string union types instead of TypeScript enum for values that cross the serialization boundary. Dates in shared types should be string (ISO 8601) not Date, since JSON serialization converts Date to string.",
"sources": [
{
"type": "file",
"filename": "skills/typescript-project-structure/SKILL.md",
"tile": "tessl-labs/typescript-project-structure@0.2.0"
}
],
"checklist": [
{
"name": "shared-types-exist",
"rule": "A shared types file or directory exists (e.g., shared/types.ts or packages/shared/) that is imported by both client and server code",
"relevant_when": "Agent builds a fullstack TypeScript application"
},
{
"name": "no-duplicate-interfaces",
"rule": "The same interface or type is NOT defined in both client and server code — entity types and API shapes are defined once in the shared location",
"relevant_when": "Agent builds a fullstack TypeScript application with types used on both sides"
},
{
"name": "union-types-not-enum",
"rule": "String enums that cross the client/server boundary use union types (type Status = 'active' | 'inactive') rather than TypeScript enum",
"relevant_when": "Agent defines status or category types shared between client and server"
}
]
}evals
scenario-1
scenario-2
scenario-3
scenario-4
scenario-5
skills
typescript-project-structure
verifiers