AI Assistant Context Index
🤖 Purpose: Central entry point for AI assistants working on this Astro project
Quick Start for AI Assistants
Section titled “Quick Start for AI Assistants”When working on this project, follow this priority order:
- Understand the Track: Check if working on MVP or Showcase version
- Review Current Phase: Identify which implementation phase is active
- Check Performance Budgets: Ensure changes stay within limits
- Follow Design System: Use established tokens and patterns
- Maintain Type Safety: TypeScript strict mode is required
Project Overview
Section titled “Project Overview”This is a modern Astro static site with:
- Framework: Astro 5.11.0 with zero JavaScript by default
- Styling: Tailwind CSS 3.4.4 with design tokens
- Content: MDX with Astro Content Collections
- Performance: Lighthouse 97+ target
- Deployment: Cloudflare Pages
Key Directories
Section titled “Key Directories”src/├── components/ # UI components (atomic design)├── content/ # Content collections (blog, projects)├── layouts/ # Page layouts├── pages/ # Routes├── styles/ # Global CSS└── utils/ # Helper functions
docs/├── implementation-guides/ # Phase-by-phase guides├── adr/ # Architecture decisions└── ai-context/ # AI assistant docsCurrent Implementation Status
Section titled “Current Implementation Status”The current active phase is defined in this file’s frontmatter (current_phase).
To determine the status of any phase:
- Consult the Implementation Roadmap for the full, ordered list of phases (0-12).
- Compare a phase’s number to the
current_phasevalue:- If
phase_number < current_phase, it is Completed. - If
phase_number == current_phase, it is Active. - If
phase_number > current_phase, it is Pending.
- If
This value is updated automatically by CI on pull request merges.
Critical Constraints
Section titled “Critical Constraints”Performance Budgets
Section titled “Performance Budgets”- JavaScript: < 160KB total (gzipped)
- CSS: < 50KB total
- Images: < 200KB each (after optimization)
- Lighthouse Scores: Performance 97+, Accessibility 98+
Note on Budget Strictness: These budgets are intentionally strict to maintain excellent Core Web Vitals and ensure a high-quality user experience. For instance, the project’s INP/FID goals (target < 100ms) are more demanding than Google’s ‘good’ threshold of 200ms. While this is beneficial for outcomes like a developer portfolio, it’s important to communicate to stakeholders that CI may fail even on seemingly small regressions that exceed these tight budgets. This proactive communication helps manage expectations around development velocity and quality gates.
Technical Rules
Section titled “Technical Rules”- Avoid
client:loadunless explicitly justified in an ADR (e.g., early theme initialization inThemeSetup.astro). Wheneverclient:loadis used, document the rationale and measure the impact. - Prefer CSS solutions over JavaScript
- Use Astro Image component for all images
- TypeScript strict mode required
- Biome for linting/formatting (not ESLint/Prettier)
Common AI Tasks
Section titled “Common AI Tasks”Component Creation
Section titled “Component Creation”"Create an accessible [component] with:- TypeScript interfaces- Tailwind styling using our tokens- ARIA labels and keyboard navigation- MVP version (no JS) and Showcase version (minimal JS)"Performance Optimization
Section titled “Performance Optimization”"Optimize [feature] to:- Reduce bundle size- Improve Core Web Vitals- Lazy load appropriately- Stay within our budgets"Content Modeling
Section titled “Content Modeling”"Create Astro content collection for [type] with:- Zod schema- TypeScript types- Draft mechanism- SEO fields"Key Configuration Files
Section titled “Key Configuration Files”Always Reference These
Section titled “Always Reference These”astro.config.mjs- Astro configurationtailwind.config.ts- Tailwind with design tokenstsconfig.json- TypeScript settingsbiome.json- Linting/formatting rulessrc/content/config.ts- Content schemas
Performance Monitoring
Section titled “Performance Monitoring”perf-baseline/scores.json- Target metrics.lighthouserc.js- Lighthouse CI configpublic/_headers- Security headers
Design System Reference
Section titled “Design System Reference”Color Tokens
Section titled “Color Tokens”- Semantic: background, foreground, border, primary, etc.
- Format: HSL values in CSS variables
- Dark Mode: Automatic with .dark class
Typography Scale
Section titled “Typography Scale”- Sizes: xs, sm, base, lg, xl, 2xl, 3xl, 4xl
- Font: Inter Variable (self-hosted)
- Line heights: Included in tokens
Spacing System
Section titled “Spacing System”- Scale: 0, 1, 2, 3, 4, 5, 6, 8, 10, 12, 16, 20, 24
- Usage: Consistent padding/margin
Content Types
Section titled “Content Types”Projects Collection
Section titled “Projects Collection”- Fields: title, description, date, technologies, outcomes
- Features: Draft mode, featured flag, custom sorting
Blog Collection
Section titled “Blog Collection”- Fields: title, description, date, tags, author
- Features: MDX support, related posts, reading time
Navigation Collection
Section titled “Navigation Collection”- Type: Data collection (JSON)
- Usage: Header/footer navigation items
Development Workflow
Section titled “Development Workflow”Before Making Changes
Section titled “Before Making Changes”- Run
pnpm run check- Ensure types are correct - Run
pnpm run build:tokens- If design tokens changed - Check current Git branch - Follow branch strategy
While Developing
Section titled “While Developing”- Use
pnpm run dev- Local development - Test on mobile - Mobile-first approach
- Check accessibility - Keyboard navigation
Before Committing
Section titled “Before Committing”- Pre-commit hooks run automatically
- Validates formatting and types
- Ensure CI will pass
Common Pitfalls to Avoid
Section titled “Common Pitfalls to Avoid”- Adding unnecessary JavaScript - Prefer CSS solutions
- Hardcoding values - Use design tokens
- Skipping accessibility - Always include ARIA
- Ignoring performance - Check bundle size
- Breaking types - Run TypeScript checks
Getting Help
Section titled “Getting Help”Internal Documentation
Section titled “Internal Documentation”- Implementation Roadmap - Chronological build sequence.
- Detailed Phase Guides:
../implementation-guides/ - Architecture Decisions:
../adr/ - Component Patterns:
../patterns/
External Resources
Section titled “External Resources”Maintenance Notes
Section titled “Maintenance Notes”This context should be updated when:
- Completing a new phase
- Making architecture decisions
- Changing performance budgets
- Adding new content types
- Updating dependencies
Self-Maintenance Checklist
Section titled “Self-Maintenance Checklist”When any of the following occur, update this file immediately:
-
Phase Completion
- [ ] Check the box for the completed phase
- [ ] Update “Active Phase” to the next phase
- [ ] Add any new constraints or rules discovered
-
New ADR Accepted
- [ ] Add to “Critical Constraints” if it affects development
- [ ] Update relevant sections (e.g., new performance budgets)
- [ ] Link to the ADR in the appropriate section
-
Dependency Changes
- [ ] Update version numbers in “Project Overview”
- [ ] Add migration notes if breaking changes
- [ ] Update any affected code examples
-
Content Model Changes
- [ ] Update “Content Types” section
- [ ] Add new fields or collections
- [ ] Note any migration requirements
-
New Patterns or Anti-patterns
- [ ] Add to “Common Pitfalls to Avoid”
- [ ] Update “Common AI Tasks” with new examples
- [ ] Create new pattern documents if needed
Maintenance Commands
Section titled “Maintenance Commands”# After completing a phasepnpm run update:phase-status --phase=5 --status=complete
# After adding new ADRpnpm run update:ai-context --type=adr --file=docs/adr/006-new-decision.md
# Validate AI context is currentpnpm run validate:ai-contextReview Schedule
Section titled “Review Schedule”- Weekly: Quick check during team sync
- Phase Completion: Full review and update
- Monthly: Comprehensive accuracy audit
- Quarterly: Structure and organization review
Last reviewed: 2025-06-19 Next review due: 2025-12-31