sickn33/agentic-awesome-skills · warning · Error
Name is required
Error message
Name is required
What it means
The field-level guard in fp-refactor's validateUser: the input is an object but `name` is absent or not a string. Like its siblings, it demonstrates field-by-field throws the skill later replaces.
Source
Thrown at skills/fp-refactor/SKILL.md:73
#### Before (Imperative)
```typescript
function parseJSON(input: string): unknown {
try {
return JSON.parse(input);
} catch (error) {
throw new Error(`Invalid JSON: ${error}`);
}
}
function validateUser(data: unknown): User {
try {
if (!data || typeof data !== 'object') {
throw new Error('Data must be an object');
}
const obj = data as Record<string, unknown>;
if (typeof obj.name !== 'string') {
throw new Error('Name is required');
}
if (typeof obj.age !== 'number') {
throw new Error('Age must be a number');
}
return { name: obj.name, age: obj.age };
} catch (error) {
throw error;
}
}
// Usage with nested try-catch
function processUserInput(input: string): User | null {
try {
const data = parseJSON(input);
const user = validateUser(data);
return user;
} catch (error) {
console.error('Failed to process user:', error);View on GitHub (pinned to 58d857988f)
Solutions
- Align the field name with the producer's contract (check OpenAPI/schema)
- Normalize input keys before validation
- Move the check into a schema (zod object({ name: z.string() })) at the boundary
Example fix
// before
if (typeof obj.name !== 'string') throw new Error('Name is required')
// after
const nameOk = isRecord(data) && typeof data.name === 'string' && data.name.length > 0
return nameOk ? E.right(data as User) : E.left('Name is required') Defensive patterns
Strategy: type-guard
Validate before calling
const hasName = (x: unknown) => isRecord(x) && typeof x.name === 'string' && x.name.length > 0
Type guard
const hasName = (x: unknown): x is { name: string } =>
typeof x === 'object' && x !== null && typeof (x as any).name === 'string' Prevention
- Keep field names locked to a shared schema contract
- Normalize payload keys (camelCase/snake_case) before validation
When it happens
Trigger: validateUser({ age: 30 }), validateUser({ name: 123 }), or payloads where name was serialized under a different key (Name, fullName).
Common situations: API contract renames; optional fields omitted by clients; numbers auto-coerced by CSV import; localization forms using different field names.
Understand the failure class
Background: Schema validation failed / invalid input schema: payload rejected because its shape doesn't match the expected schema — this error's family across 28 libraries.
Related errors
AI-assisted analysis of sickn33/agentic-awesome-skills@58d857988f (2026-08-26).
Data as JSON: /api/errors/c339f64849c5756c.
Report an issue: GitHub.