@equal-experts/kuat-react 0.13.0 → 0.13.1

package/agent-docs/external/kuat-agent-rules/kuat-docs/rules/foundations/content/numbers.md

@@ -0,0 +1,69 @@
+# Numbers
+
+Guidance for dates, times, currency, and other numbers in Equal Experts content.
+
+---
+
+## Quick Reference
+
+- **Dates:** Use a clear, unambiguous format; prefer written or ISO (YYYY-MM-DD) depending on context
+- **Times:** Use 24-hour or am/pm consistently; specify time zone when relevant
+- **Currency:** Use symbol or code (e.g. £, GBP) as appropriate; be consistent within a document
+- **Percentages:** Use the % symbol with the number (e.g. 45%)
+- **Large numbers:** Use commas (or spaces in some locales) for thousands
+
+---
+
+## Dates
+
+- Prefer a format that avoids ambiguity (e.g. 24 March 2025 or 2025-03-24)
+- In UK-facing content, day–month–year is standard (24 March 2025)
+- In technical or international contexts, ISO 8601 (YYYY-MM-DD) is often clearer
+- Spell out month names in body copy when space allows; abbreviate only in tables or tight UI (e.g. Mar 2025)
+
+---
+
+## Time
+
+- Be consistent within a document: either 24-hour (14:30) or 12-hour with am/pm (2:30 pm)
+- Specify time zone when the reader needs to act or compare across regions (e.g. "2:30 pm GMT")
+- Use "midday" and "midnight" where they're clearer than 12:00
+
+---
+
+## Currency
+
+- Use the appropriate symbol (£, $, €) or ISO code (GBP, USD, EUR) as fits the context
+- Be consistent: don't mix "£10" and "10 GBP" in the same piece unless one is clearly a label
+- For whole amounts, no decimal places unless it's pence/cents (e.g. £10 not £10.00 for ten pounds)
+
+---
+
+## Percentages
+
+- Use the % symbol with the number: 45%, 12.5%
+- In body copy, "45%" is usually preferable to "45 percent" unless you're writing for voice or very formal copy
+- For a range, "40–60%" (en dash, no space)
+
+---
+
+## Units of Measure
+
+- Use metric by default in UK/international content unless the audience or product uses imperial
+- Abbreviate when standard: kg, m, km, cm. Spell out in prose when it reads more naturally
+- Leave a space between number and unit: "5 kg", "12 cm"
+
+---
+
+## Large Numbers
+
+- Use commas as thousand separators in English (1,000,000) or a thin space where that's the convention
+- Keep formatting consistent in tables and lists
+- For very large numbers, consider "1.5 million" or "2.3 billion" in body copy
+
+---
+
+## Related Documentation
+
+- [Formatting](./formatting.md) - Capitalisation, lists
+- [Punctuation](./punctuation.md) - Dashes, spaces

package/agent-docs/external/kuat-agent-rules/kuat-docs/rules/foundations/content/punctuation.md

@@ -0,0 +1,75 @@
+# Punctuation
+
+Guidance for commas, dashes, apostrophes, and other punctuation in Equal Experts content.
+
+---
+
+## Quick Reference
+
+- **Commas:** Use to separate clauses and items in a list; avoid comma splices
+- **Apostrophes:** Use for possessives and contractions; don't use for plurals
+- **Dashes:** Use en dash for ranges (40–60); use em dash sparingly for a break in a sentence
+- **Hyphens:** Use in compound modifiers before a noun (e.g. well-known); follow standard compound rules
+- **Exclamation points:** Use rarely; one is enough
+
+---
+
+## Commas
+
+- Use a comma before "and" or "or" in a list of three or more items (Oxford comma) for clarity when it avoids ambiguity
+- Use commas to set off non-essential clauses
+- Don't join two independent clauses with only a comma (use a full stop, semicolon, or conjunction)
+
+---
+
+## Apostrophes
+
+- **Possessives:** Add 's for singular (team's, user's); add ' for plural already ending in s (users', teams')
+- **Contractions:** Use for standard contractions (don't, it's, we're)
+- **Plurals:** Do not use an apostrophe for plurals: "1990s" not "1990's"; "APIs" not "API's"
+
+---
+
+## Dashes and Hyphens
+
+- **En dash (–):** Use for ranges (40–60%, March–May, 9–5). Use unspaced in British style.
+- **Em dash (—):** Use sparingly for a strong break or aside. Prefer one em dash per sentence.
+- **Hyphen (-):** Use in compound modifiers before a noun: "well-known result", "up-to-date report". Don't hyphenate after the noun when the modifier follows: "the result is well known".
+- **Hyphen in compounds:** Follow standard usage (e.g. "email", "multi-factor", "read-only" as per common style)
+
+---
+
+## Colons and Semicolons
+
+- **Colon:** Use to introduce a list or an explanation that follows from the main clause. One space after a colon.
+- **Semicolon:** Use to link closely related independent clauses, or to separate list items that already contain commas. Use sparingly; often a full stop is clearer.
+
+---
+
+## Ellipses
+
+- Use for omitted words in a quote (three dots: …)
+- Avoid in UI or body copy to indicate "more" or trailing thought; rewrite so the sentence is complete
+
+---
+
+## Exclamation Points
+
+- Use rarely; reserve for genuine emphasis or short, positive confirmation
+- One exclamation point is enough; never use multiple (!!)
+
+---
+
+## Quotation Marks
+
+- Use double quotation marks for direct speech and short quoted phrases
+- Put full stops and commas inside the closing quote when they apply to the quoted matter; outside when they apply to the whole sentence (British style)
+- For terms or "scare quotes", use sparingly
+
+---
+
+## Related Documentation
+
+- [Writing style](./writing-style.md)
+- [Formatting](./formatting.md)
+- [Numbers](./numbers.md) - Ranges, decimals

package/agent-docs/external/kuat-agent-rules/kuat-docs/rules/foundations/content/voice-and-tone.md

@@ -0,0 +1,263 @@
+# Voice and Tone
+
+Universal voice and tone for Equal Experts content. Applies to all platforms and media. Read this before any platform-specific content guide.
+
+---
+
+## Overview
+
+These guidelines ensure consistent voice and tone across all Equal Experts communications, regardless of platform or medium.
+
+---
+
+## Quick Reference
+
+**Always:**
+- Be clear and direct
+- Focus on audience needs
+- Use plain language
+- Be specific, not vague
+
+**Never:**
+- Use "revolutionize", "transform", "disrupt" without specific evidence
+- Hide behind jargon
+- Speak down to audience
+- Be vague or ambiguous
+
+---
+
+## Content Voice and Tone
+
+### Universal Principles
+
+#### Clear and Direct
+- Get to the point quickly
+- Use plain language
+- Avoid unnecessary words
+- Be specific, not vague
+
+#### Helpful and Respectful
+- Anticipate audience needs
+- Provide guidance when needed
+- Respect audience's time and intelligence
+- Never talk down to people
+
+#### Confident but Humble
+- Show expertise through clarity
+- Admit when something isn't available
+- Provide alternatives when possible
+- Build trust through honesty
+
+#### Consistent and Predictable
+- Use the same terms for the same concepts
+- Follow established patterns
+- Maintain consistent tone across touchpoints
+- Set clear expectations
+
+---
+
+## Content Principles
+
+### 1. Audience-First Thinking
+
+Before creating content, define:
+- The specific aim
+- The target audience
+- How it helps the audience achieve their goals
+- What question it answers
+
+### 2. Clarity Over Cleverness
+
+Prioritize:
+- Clear communication
+- Easy comprehension
+- Quick understanding
+
+Avoid:
+- Clever wordplay that obscures meaning
+- Jokes that might confuse
+- Metaphors that require explanation
+- Industry jargon without context
+
+### 3. Be Clear and Concise
+
+- Use plain English where possible
+- Don't use 10 words when 3 will do
+- Avoid jargon-laden complexity
+- Give yourself the best chance of being read and understood
+
+### 4. Consistency Matters
+
+- Use the same terms for the same concepts
+- Follow established patterns
+- Maintain consistent tone
+- Set clear expectations
+
+### 5. Test, Iterate and Learn
+
+Test new content, improve based on feedback, share learnings across the team.
+
+---
+
+## Audience Considerations
+
+### Technical Audiences (Developers, Engineers)
+
+**Tone:** Pragmatic, evidence-based, respectful of expertise
+
+**Use:**
+- Specific technical details
+- Code examples and practical patterns
+- Trade-offs and architectural decisions
+
+**Avoid:**
+- Over-simplification
+- Buzzwords without substance
+- Marketing language
+
+### Business Stakeholders (Product Owners, Leaders)
+
+**Tone:** Outcome-focused, clear, strategic
+
+**Use:**
+- Business metrics and outcomes
+- Efficiency gains and ROI
+- Impact statements
+
+**Avoid:**
+- Deep technical detail without context
+- Acronyms without explanation
+- Technology for technology's sake
+
+### General Audiences
+
+**Tone:** Helpful, clear, accessible
+
+**Use:**
+- Plain language
+- Clear explanations
+- Practical examples
+
+**Avoid:**
+- Any unnecessary words
+- Corporate speak
+- Jargon or technical terms
+
+---
+
+## Common Anti-Patterns
+
+### Buzzword Bingo
+Using trendy terminology without substance.
+
+❌ "Leveraging synergistic blockchain-enabled AI solutions"  
+✅ "We automated invoice processing using existing APIs"
+
+### Feature Dump
+Listing features without context or benefit.
+
+❌ "Features: Dashboard, Reports, Analytics, Integrations"  
+✅ "The dashboard surfaces the three metrics teams check daily"
+
+### Vague Promise
+Making claims without evidence or specifics.
+
+❌ "We'll dramatically improve your performance"  
+✅ "Teams typically see 40-60% reduction in deployment time"
+
+### Over-Explanation
+Explaining things that don't need explanation.
+
+❌ "Click the button below to continue to the next screen"  
+✅ [Continue]
+
+---
+
+## Content Quality Checklist
+
+### The Clarity Test
+Can it be understood in 30 seconds of skimming?
+
+### The Purpose Test
+Does this answer a specific question or solve a problem?
+
+### The Consistency Test
+Does it use consistent terminology and follow established patterns?
+
+### The Audience Test
+Is this appropriate for the intended audience?
+
+### The Accessibility Test
+Does it work for all people, including those using assistive technologies?
+
+---
+
+## Tone Adaptation Guide
+
+### For Seriousness Levels
+
+**Standard:** Friendly, approachable, professional  
+**High Stakes:** Serious, direct, solution-focused  
+**Celebratory:** Warm, enthusiastic, appreciative  
+**Difficult News:** Empathetic, honest, supportive
+
+---
+
+## For AI Content Generation
+
+### Before Generating
+
+Confirm:
+1. **Content type** - What format?
+2. **Audience** - Who will read this?
+3. **Purpose** - What outcome does this serve?
+4. **Context** - Do you have enough information?
+
+**If unclear, ask clarifying questions.**
+
+### While Generating
+
+**Do:**
+- Use specific examples
+- Include evidence when claiming results
+- Default to plain English
+- Apply appropriate tone for audience
+
+**Don't:**
+- Generate generic content
+- Make claims without evidence
+- Use "revolutionize", "transform", "disrupt" without proof
+- Write like typical AI-generated content
+
+### After Generating
+
+Apply quality tests:
+1. Clarity Test
+2. Purpose Test
+3. Consistency Test
+4. Audience Test
+5. Accessibility Test
+
+**Red flags:**
+- Generic phrases applicable to any context
+- Lack of specific examples
+- Over-use of buzzwords
+- Tone mismatch with audience
+
+---
+
+## Platform-Specific Content
+
+For platform-specific content guidance:
+
+- **Web Marketing** - See [types/web/marketing/](../../types/web/marketing/)
+- **Web Product** - See [types/web/product/](../../types/web/product/)
+- **Slides** - See [types/slides/](../../types/slides/)
+
+---
+
+## Related Documentation
+
+- [Brand Guidelines](../brand.md) - Brand voice and values
+- [Writing style](./writing-style.md) - Active voice, plain language, conventions
+- [Design](../design/README.md) - Visual design principles

package/agent-docs/external/kuat-agent-rules/kuat-docs/rules/foundations/content/writing-style.md

@@ -0,0 +1,91 @@
+# Writing Style
+
+Style and usage principles for Equal Experts content. Be clear, precise, and conversational.
+
+---
+
+## Quick Reference
+
+**Do:**
+- Use active voice
+- Use everyday contractions (we're, it's, don't)
+- Use simple verb tenses (present, past; avoid unnecessary future or perfect)
+- Address the reader as "you"
+- Prefer short sentences
+
+**Don't:**
+- Use passive voice when active is clearer
+- Use formal or stiff phrasing
+- Over-qualify with "in order to", "in the event that"
+- Use jargon without explanation
+
+---
+
+## Active Voice
+
+Prefer the subject doing the action. It's clearer and more direct.
+
+| Prefer | Avoid |
+|--------|--------|
+| The team delivered the project on time | The project was delivered on time by the team |
+| You can save your work here | Work can be saved here |
+| We recommend testing first | It is recommended that testing be performed first |
+
+Use passive only when the actor is unknown or irrelevant, or when you want to emphasise the action.
+
+---
+
+## Plain Language
+
+- Use common words instead of formal or obscure ones
+- Prefer short words where they carry the same meaning
+- Explain technical terms on first use
+
+| Prefer | Avoid |
+|--------|--------|
+| use | utilise |
+| help | facilitate |
+| about | with regard to |
+| if | in the event that |
+| before | prior to (when "before" works) |
+
+---
+
+## Contractions
+
+Use everyday contractions so content sounds natural and approachable.
+
+- we're, it's, don't, can't, you'll, that's
+- Avoid overly formal "we have not", "do not" in body copy unless tone requires it (e.g. legal, formal notices)
+
+---
+
+## Verb Tenses
+
+- Use **present** for general truth and instructions: "The dashboard shows recent activity."
+- Use **past** for what happened: "The deployment completed successfully."
+- Use **future** only when necessary: "You will receive a confirmation email."
+- Avoid unnecessary perfect tenses when simple past or present is clearer.
+
+---
+
+## Conciseness
+
+- Cut filler: "Please note that" → often delete; "at this time" → "now" or "currently"
+- One main idea per sentence where possible
+- Start with the most important information
+
+---
+
+## Addressing the Reader
+
+- Speak to the reader as **"you"**
+- Use **"we"** for Equal Experts when it's clear from context
+- Keep "my" vs "your" consistent with the product (e.g. "your account" in product UI)
+
+---
+
+## Related Documentation
+
+- [Voice and tone](./voice-and-tone.md) - Principles and audience
+- [Formatting](./formatting.md) - Capitalisation, headings, lists

package/agent-docs/external/kuat-agent-rules/kuat-docs/rules/foundations/design/README.md

@@ -0,0 +1,28 @@
+# Design Rules
+
+Visual design tokens and principles for Equal Experts. Apply across all platforms (web, slides, graphics, photography).
+
+---
+
+## Overview
+
+These rules define the design language: colours, typography, spacing, borders, and high-level design principles. Load with [foundations brand and logo](../brand.md) and [foundations content](../content/) as needed.
+
+---
+
+## Files
+
+| File | Description |
+|------|-------------|
+| [design-language.md](./design-language.md) | Design principles and token overview |
+| [colours.md](./colours.md) | Brand colour palette and usage |
+| [typography.md](./typography.md) | Fonts and type scale |
+| [spacing.md](./spacing.md) | Spacing system |
+| [borders.md](./borders.md) | Border philosophy and specifications |
+
+---
+
+## Related
+
+- [Foundations](../README.md) – Brand, logo, accessibility
+- [Content](../content/README.md) – Writing and style

package/agent-docs/external/kuat-agent-rules/kuat-docs/rules/foundations/design/borders.md

@@ -0,0 +1,159 @@
+# Border Rules
+
+Border specifications for Equal Experts. This document defines border philosophy, widths, radius, and usage guidelines.
+
+---
+
+## Overview
+
+The design system follows a **minimal border philosophy** - borders should only be used when necessary. Prefer spacing and visual hierarchy over borders.
+
+**Key Principle:** Use borders sparingly and purposefully. Spacing and visual hierarchy should be the primary tools for creating separation.
+
+---
+
+## When to Use Borders
+
+### Use Borders For:
+
+1. **Creating separation** between distinct sections needing clear boundaries
+2. **Distinguishing interactive elements** from static content
+3. **Defining component boundaries** where spacing alone is insufficient
+4. **Indicating state changes** (focus states, error states, selection)
+
+### Avoid Borders When:
+
+- Spacing alone can create sufficient separation
+- Visual hierarchy (size, color, weight) can distinguish elements
+- The border would create visual clutter
+- Separation is already clear through other design elements
+
+---
+
+## Border Width
+
+Borders should be **1-4px** in width:
+
+| Width | Usage |
+|-------|-------|
+| 1px | Default for most elements (cards, dividers) |
+| 2px | Emphasized borders, active states |
+| 3-4px | Focus indicators, high-contrast separations |
+
+---
+
+## Border Style
+
+**Always use solid lines.**
+
+The design system does not use:
+- Dashed borders
+- Dotted borders
+- Other border styles
+
+---
+
+## Border Color
+
+Use brand-appropriate colors:
+
+| Usage | Color |
+|-------|-------|
+| Default borders | Light gray (slate-200 light, slate-700 dark) |
+| Focus indicators | EE Blue or appropriate focus color |
+| Error states | Red/destructive color |
+| Success states | Transform Teal |
+
+---
+
+## Border Radius
+
+The design system uses a **minimal radius approach**:
+
+### Default: 0px (No Radius)
+
+Most elements have **no border radius** by default for a clean, modern, geometric aesthetic.
+
+**Elements with no radius:**
+- Static containers
+- Sections
+- Dividers
+- Content blocks
+
+### Interactive Elements: 6px
+
+**Interactive elements** use **6px border radius**:
+
+- Buttons
+- Clickable cards
+- Interactive tiles
+- Tabs
+
+### Form Inputs: 4px
+
+**Form input elements** use **4px border radius**:
+
+- Text inputs
+- Textareas
+- Select dropdowns
+- Search inputs
+
+### Summary
+
+| Element Type | Border Radius |
+|--------------|---------------|
+| Static content | 0px |
+| Interactive elements | 6px |
+| Form inputs | 4px |
+
+---
+
+## Accessibility
+
+### Contrast Requirements
+
+Borders must meet WCAG 2.1 Level AA for graphical objects:
+
+- **Minimum contrast ratio:** 3:1 against adjacent colors
+
+### Testing
+
+- Test borders against background colors
+- Verify visibility in both light and dark contexts
+- Ensure sufficient contrast for all users
+
+---
+
+## Usage Guidelines
+
+### Do's
+
+1. **Use borders purposefully** - Only when spacing is insufficient
+2. **Follow width guidelines** - 1px default, 2px emphasized, 3-4px focus
+3. **Apply radius correctly** - 0px static, 6px interactive, 4px inputs
+4. **Ensure accessibility** - 3:1 minimum contrast ratio
+5. **Be consistent** - Same border treatment for same element types
+
+### Don'ts
+
+1. **Don't overuse borders** - Spacing should be the first option
+2. **Don't use non-solid borders** - No dashed or dotted
+3. **Don't use arbitrary radius** - Only 0px, 4px, or 6px
+4. **Don't break accessibility** - Always verify contrast
+5. **Don't use decorative borders** - Keep them functional
+
+---
+
+## Platform-Specific Borders
+
+For platform-specific border guidance:
+
+- **Web** - See [types/web/](../types/web/)
+- **Graphics** - See [types/graphics/](../types/graphics/)
+
+---
+
+## Related Documentation
+
+- [Spacing](./spacing.md) - Spacing as alternative to borders
+- [Colours](./colours.md) - Border colors