alan

Interviews designers, builds design-system prototypes, and captures review feedback as structured findings.

1|Updated May 29, 2026
One-click install
npx skills add https://github.com/borderux/recursica-knowledge --skill alan-borderux
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: alan
Source: https://github.com/borderux/recursica-knowledge/tree/main/agents/alan
Command: npx skills add https://github.com/borderux/recursica-knowledge --skill alan-borderux

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Design teams lack a repeatable way to test a design system against real product scenarios: interviews are ad hoc, prototypes drift from component rules, and review feedback is lost or mixed with builder mistakes. This Skill runs the full design-test loop with strict provenance and separation of duties. ## Core Features & Use Cases - Structured designer interview: Runs a six-section interview covering users, domain model, status lifecycles, screens, edge states, and test goals, producing a TEST.md scenario file. - Rule-constrained prototype build: Builds a working prototype exclusively from Recursica components and tokens, then dispatches the Barb reviewer subagent to check every screen against the design system's published rules before the designer sees it. - Findings with provenance: Captures designer feedback into FINDINGS.md and self-evaluation into EVAL_REPORT.md, separating design rules from builder defects and package gaps. - Use Case: A design lead wants to know whether the component library covers a task-management app. The Skill interviews the designer, builds the app from library components, has it rule-reviewed, and returns structured findings plus a package-defect list. ## Quick Start Ask the agent to run a design test: interview me about the tool I want to prototype, build it from our design system components, and capture my review as findings.

Frequently Asked Questions about alan

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I run a design test against a design system?▼

Interview the designer across six sections covering users, domain model, status lifecycles, screens, edge states, and test goals, then write a TEST.md scenario. Build the prototype exclusively from the design system's components and tokens, and capture the review as structured findings.

How do I capture design feedback as structured findings?▼

Write each issue into FINDINGS.md with screen or route, screenshot path, what is wrong, what it should be, an Already-a-rule flag, and severity. Phrase what-it-should-be as a general instruction rather than a preference so it can become a rule.

What is the Barb reviewer subagent in this workflow?▼

Barb is a read-only subagent dispatched on every built screen before the designer sees it. She checks the source against the design system's published rules and reports violations with file and line, while the builder applies the fixes.

Can this agent edit the design-system knowledge repository?▼

No. The agent is hard-prohibited from editing the knowledge repository, committing, or pushing. Durable lessons go into EVAL_REPORT.md and a defect list, and promotion into the knowledge repo is handed off to a separate promote-findings workflow.

What are the limitations of the automated rule review?▼

The reviewer has no browser, so layout issues like overflow or resolved type styles go unchecked and must be verified manually against the running dev server. Items marked uncovered are questions for the designer, not gaps to fill by invention.