design-context

A project-level design brief captures your brand voice, target audience, personality, and accessibility constraints into a single .design-context.md file. This canonical file acts as a source of truth so downstream design work remains aligned and avoids generic outputs.

You capture brand voice and accessibility constraints by running an interactive 5-7 question Q&A session. The skill asks about your audience, primary use case, personality, tone, anti-references, and constraints, then persists the answers into a .design-context.md file at your project root.

The best way to document brand personality and anti-references is by generating a .design-context.md file at the project root. This provides a canonical design brief that automated design skills can read, ensuring all generated work respects your established brand guidelines and avoids unwanted styles.

Yes, you can update an existing design brief safely. The skill respects your current .design-context.md file and offers review and update flows rather than blind appends, only overwriting the existing file if you explicitly provide a force command.

Yes, the skill scans your repository before generating a design brief. It explores common locations like public assets, Tailwind config, landing pages, and package.json to summarize existing project context before asking you targeted questions about your brand.

You should not use an interactive design brief generator when you already have a rigid, non-negotiable design schema or if you need to bypass the 5-7 question Q&A process. The skill requires interactive input and repository exploration to function properly.