@builderos/create-agent-os 0.0.2

package/src/template/agent-os/commands/shape-spec/2-shape-spec.md

@@ -0,0 +1,300 @@
+Now that you've initialized the folder for this new spec, proceed with the research phase.
+
+Follow these instructions for researching this spec's requirements:
+
+# Spec Research
+
+## Core Responsibilities
+
+1. **Read Initial Idea**: Load the raw idea from initialization.md
+2. **Analyze Product Context**: Understand product mission, roadmap, and how this feature fits
+3. **Ask Clarifying Questions**: Generate targeted questions WITH visual asset request AND reusability check
+4. **Process Answers**: Analyze responses and any provided visuals
+5. **Ask Follow-ups**: Based on answers and visual analysis if needed
+6. **Save Requirements**: Document the requirements you've gathered to a single file named: `[spec-path]/planning/requirements.md`
+
+## Workflow
+
+### Step 1: Read Initial Idea
+
+Read the raw idea from `[spec-path]/planning/initialization.md` to understand what the user wants to build.
+
+### Step 2: Analyze Product Context
+
+Before generating questions, understand the broader product context:
+
+1. **Read Product Mission**: Load `agent-os/product/mission.md` to understand:
+   - The product's overall mission and purpose
+   - Target users and their primary use cases
+   - Core problems the product aims to solve
+   - How users are expected to benefit
+
+2. **Read Product Roadmap**: Load `agent-os/product/roadmap.md` to understand:
+   - Features and capabilities already completed
+   - The current state of the product
+   - Where this new feature fits in the broader roadmap
+   - Related features that might inform or constrain this work
+
+3. **Read Product Tech Stack**: Load `agent-os/product/tech-stack.md` to understand:
+   - Technologies and frameworks in use
+   - Technical constraints and capabilities
+   - Libraries and tools available
+
+This context will help you:
+- Ask more relevant and contextual questions
+- Identify existing features that might be reused or referenced
+- Ensure the feature aligns with product goals
+- Understand user needs and expectations
+
+### Step 3: Generate First Round of Questions WITH Visual Request AND Reusability Check
+
+Based on the initial idea, generate 4-8 targeted, NUMBERED questions that explore requirements while suggesting reasonable defaults.
+
+**CRITICAL: Always include the visual asset request AND reusability question at the END of your questions.**
+
+**Question generation guidelines:**
+- Start each question with a number
+- Propose sensible assumptions based on best practices
+- Frame questions as "I'm assuming X, is that correct?"
+- Make it easy for users to confirm or provide alternatives
+- Include specific suggestions they can say yes/no to
+- Always end with an open question about exclusions
+
+**Required output format:**
+```
+Based on your idea for [spec name], I have some clarifying questions:
+
+1. I assume [specific assumption]. Is that correct, or [alternative]?
+2. I'm thinking [specific approach]. Should we [alternative]?
+3. [Continue with numbered questions...]
+[Last numbered question about exclusions]
+
+**Existing Code Reuse:**
+Are there existing features in your codebase with similar patterns we should reference? For example:
+- Similar interface elements or UI components to re-use
+- Comparable page layouts or navigation patterns
+- Related backend logic or service objects
+- Existing models or controllers with similar functionality
+
+Please provide file/folder paths or names of these features if they exist.
+
+**Visual Assets Request:**
+Do you have any design mockups, wireframes, or screenshots that could help guide the development?
+
+If yes, please place them in: `[spec-path]/planning/visuals/`
+
+Use descriptive file names like:
+- homepage-mockup.png
+- dashboard-wireframe.jpg
+- lofi-form-layout.png
+- mobile-view.png
+- existing-ui-screenshot.png
+
+Please answer the questions above and let me know if you've added any visual files or can point to similar existing features.
+```
+
+**OUTPUT these questions to the orchestrator and STOP - wait for user response.**
+
+### Step 4: Process Answers and MANDATORY Visual Check
+
+After receiving user's answers from the orchestrator:
+
+1. Store the user's answers for later documentation
+
+2. **MANDATORY: Check for visual assets regardless of user's response:**
+
+**CRITICAL**: You MUST run the following bash command even if the user says "no visuals" or doesn't mention visuals (Users often add files without mentioning them):
+
+```bash
+# List all files in visuals folder - THIS IS MANDATORY
+ls -la [spec-path]/planning/visuals/ 2>/dev/null | grep -E '\.(png|jpg|jpeg|gif|svg|pdf)$' || echo "No visual files found"
+```
+
+3. IF visual files are found (bash command returns filenames):
+   - Use Read tool to analyze EACH visual file found
+   - Note key design elements, patterns, and user flows
+   - Document observations for each file
+   - Check filenames for low-fidelity indicators (lofi, lo-fi, wireframe, sketch, rough, etc.)
+
+4. IF user provided paths or names of similar features:
+   - Make note of these paths/names for spec-writer to reference
+   - DO NOT explore them yourself (to save time), but DO document their names for future reference by the spec-writer.
+
+### Step 5: Generate Follow-up Questions (if needed)
+
+Determine if follow-up questions are needed based on:
+
+**Visual-triggered follow-ups:**
+- If visuals were found but user didn't mention them: "I found [filename(s)] in the visuals folder. Let me analyze these for the specification."
+- If filenames contain "lofi", "lo-fi", "wireframe", "sketch", or "rough": "I notice you've provided [filename(s)] which appear to be wireframes/low-fidelity mockups. Should we treat these as layout and structure guides rather than exact design specifications, using our application's existing styling instead?"
+- If visuals show features not discussed in answers
+- If there are discrepancies between answers and visuals
+
+**Reusability follow-ups:**
+   - If user didn't provide similar features but the spec seems common: "This seems like it might share patterns with existing features. Could you point me to any similar forms/pages/logic in your app?"
+- If provided paths seem incomplete you can ask something like: "You mentioned [feature]. Are there any service objects or backend logic we should also reference?"
+
+**User's Answers-triggered follow-ups:**
+- Vague requirements need clarification
+- Missing technical details
+- Unclear scope boundaries
+
+**If follow-ups needed, OUTPUT to orchestrator:**
+```
+Based on your answers [and the visual files I found], I have a few follow-up questions:
+
+1. [Specific follow-up question]
+2. [Another follow-up if needed]
+
+Please provide these additional details.
+```
+
+**Then STOP and wait for responses.**
+
+### Step 6: Save Complete Requirements
+
+After all questions are answered, record ALL gathered information to ONE FILE at this location with this name: `[spec-path]/planning/requirements.md`
+
+Use the following structure and do not deviate from this structure when writing your gathered information to `requirements.md`.  Include ONLY the items specified in the following structure:
+
+```markdown
+# Spec Requirements: [Spec Name]
+
+## Initial Description
+[User's original spec description from initialization.md]
+
+## Requirements Discussion
+
+### First Round Questions
+
+**Q1:** [First question asked]
+**Answer:** [User's answer]
+
+**Q2:** [Second question asked]
+**Answer:** [User's answer]
+
+[Continue for all questions]
+
+### Existing Code to Reference
+[Based on user's response about similar features]
+
+**Similar Features Identified:**
+- Feature: [Name] - Path: `[path provided by user]`
+- Components to potentially reuse: [user's description]
+- Backend logic to reference: [user's description]
+
+[If user provided no similar features]
+No similar existing features identified for reference.
+
+### Follow-up Questions
+[If any were asked]
+
+**Follow-up 1:** [Question]
+**Answer:** [User's answer]
+
+## Visual Assets
+
+### Files Provided:
+[Based on actual bash check, not user statement]
+- `filename.png`: [Description of what it shows from your analysis]
+- `filename2.jpg`: [Key elements observed from your analysis]
+
+### Visual Insights:
+- [Design patterns identified]
+- [User flow implications]
+- [UI components shown]
+- [Fidelity level: high-fidelity mockup / low-fidelity wireframe]
+
+[If bash check found no files]
+No visual assets provided.
+
+## Requirements Summary
+
+### Functional Requirements
+- [Core functionality based on answers]
+- [User actions enabled]
+- [Data to be managed]
+
+### Reusability Opportunities
+- [Components that might exist already based on user's input]
+- [Backend patterns to investigate]
+- [Similar features to model after]
+
+### Scope Boundaries
+**In Scope:**
+- [What will be built]
+
+**Out of Scope:**
+- [What won't be built]
+- [Future enhancements mentioned]
+
+### Technical Considerations
+- [Integration points mentioned]
+- [Existing system constraints]
+- [Technology preferences stated]
+- [Similar code patterns to follow]
+```
+
+### Step 7: Output Completion
+
+Return to orchestrator:
+
+```
+Requirements research complete!
+
+✅ Processed [X] clarifying questions
+✅ Visual check performed: [Found and analyzed Y files / No files found]
+✅ Reusability opportunities: [Identified Z similar features / None identified]
+✅ Requirements documented comprehensively
+
+Requirements saved to: `[spec-path]/planning/requirements.md`
+
+Ready for specification creation.
+```
+
+## Important Constraints
+
+- **MANDATORY**: Always run bash command to check visuals folder after receiving user answers
+- DO NOT write technical specifications for development. Just record your findings from information gathering to this single file: `[spec-path]/planning/requirements.md`.
+- Visual check is based on actual file(s) found via bash, NOT user statements
+- Check filenames for low-fidelity indicators and clarify design intent if found
+- Ask about existing similar features to promote code reuse
+- Keep follow-ups minimal (1-3 questions max)
+- Save user's exact answers, not interpretations
+- Document all visual findings including fidelity level
+- Document paths to similar features for spec-writer to reference
+- OUTPUT questions and STOP to wait for orchestrator to relay responses
+
+
+## Display confirmation and next step
+
+Once you've completed your research and documented it, output the following message:
+
+```
+✅ I have documented this spec's research and requirements in `agent-os/specs/[this-spec]/planning`.
+
+Next step: Run the command, `1-create-spec.md`.
+```
+
+After all steps complete, inform the user:
+
+```
+Spec initialized successfully!
+
+✅ Spec folder created: `[spec-path]`
+✅ Requirements gathered
+✅ Visual assets: [Found X files / No files provided]
+
+👉 Run `/write-spec` to create the spec.md document.
+```
+
+## User Standards & Preferences Compliance
+
+IMPORTANT: Ensure that your research questions and insights are ALIGNED and DOES NOT CONFLICT with the user's preferences and standards as detailed in the following files:
+
+@agent-os/standards/global/coding-style.md
+@agent-os/standards/global/commenting.md
+@agent-os/standards/global/conventions.md
+@agent-os/standards/global/error-handling.md
+@agent-os/standards/global/tech-stack.md
+@agent-os/standards/global/validation.md

package/src/template/agent-os/commands/shape-spec/shape-spec.md

@@ -0,0 +1,40 @@
+# COMMAND: Shape Section Spec
+
+## Goal
+Create the technical specification (`spec.md`) for a specific product section.
+
+## Prerequisites
+- `design/product/product-roadmap.md` must exist.
+- You must know the **Section Title** and **Section ID**.
+
+## Instructions
+
+### Step 1: Analyze Context
+- Read `design/product/product-roadmap.md` to understand where this section fits.
+- Read `design/product/product-overview.md` to understand the overall product context.
+
+### Step 2: Create Spec File
+Create `design/product/sections/[section-id]/spec.md`.
+
+Format:
+```markdown
+# [Section Title] Specification
+
+## Overview
+[A clear, concise description of what this section does and its purpose.]
+
+## User Flows
+- [User Action] -> [System Response] -> [Next Step]
+- [User Action] -> [System Response]
+
+## UI Requirements
+- [Requirement 1: e.g., A list of items with sortable columns]
+- [Requirement 2: e.g., A primary action button in the top right]
+- [Requirement 3]
+
+## Configuration
+- shell: true (or false if this is a standalone public page like login)
+```
+
+### Step 3: Verification
+- Output: "Spec for '[Section Title]' created! You can now view it in Design OS."

package/src/template/agent-os/commands/write-spec/write-spec.md

@@ -0,0 +1,134 @@
+Now that we've initiated and planned the details for a new spec, we will now proceed with drafting the specification document, following these instructions:
+
+# Spec Writing
+
+## Core Responsibilities
+
+1. **Analyze Requirements**: Load and analyze requirements and visual assets thoroughly
+2. **Search for Reusable Code**: Find reusable components and patterns in existing codebase
+3. **Create Specification**: Write comprehensive specification document
+
+## Workflow
+
+### Step 1: Analyze Requirements and Context
+
+Read and understand all inputs and THINK HARD:
+```bash
+# Read the requirements document
+cat agent-os/specs/[current-spec]/planning/requirements.md
+
+# Check for visual assets
+ls -la agent-os/specs/[current-spec]/planning/visuals/ 2>/dev/null | grep -v "^total" | grep -v "^d"
+```
+
+Parse and analyze:
+- User's feature description and goals
+- Requirements gathered by spec-shaper
+- Visual mockups or screenshots (if present)
+- Any constraints or out-of-scope items mentioned
+
+### Step 2: Search for Reusable Code
+
+Before creating specifications, search the codebase for existing patterns and components that can be reused.
+
+Based on the feature requirements, identify relevant keywords and search for:
+- Similar features or functionality
+- Existing UI components that match your needs
+- Models, services, or controllers with related logic
+- API patterns that could be extended
+- Database structures that could be reused
+
+Use appropriate search tools and commands for the project's technology stack to find:
+- Components that can be reused or extended
+- Patterns to follow from similar features
+- Naming conventions used in the codebase
+- Architecture patterns already established
+
+Document your findings for use in the specification.
+
+### Step 3: Create Core Specification
+
+Write the main specification to `agent-os/specs/[current-spec]/spec.md`.
+
+DO NOT write actual code in the spec.md document. Just describe the requirements clearly and concisely.
+
+Keep it short and include only essential information for each section.
+
+Follow this structure exactly when creating the content of `spec.md`:
+
+```markdown
+# Specification: [Feature Name]
+
+## Goal
+[1-2 sentences describing the core objective]
+
+## User Stories
+- As a [user type], I want to [action] so that [benefit]
+- [repeat for up to 2 max additional user stories]
+
+## Specific Requirements
+
+**Specific requirement name**
+- [Up to 8 CONCISE sub-bullet points to clarify specific sub-requirements, design or architectual decisions that go into this requirement, or the technical approach to take when implementing this requirement]
+
+[repeat for up to a max of 10 specific requirements]
+
+## Visual Design
+[If mockups provided]
+
+**`planning/visuals/[filename]`**
+- [up to 8 CONCISE bullets describing specific UI elements found in this visual to address when building]
+
+[repeat for each file in the `planning/visuals` folder]
+
+## Existing Code to Leverage
+
+**Code, component, or existing logic found**
+- [up to 5 bullets that describe what this existing code does and how it should be re-used or replicated when building this spec]
+
+[repeat for up to 5 existing code areas]
+
+## Out of Scope
+- [up to 10 concise descriptions of specific features that are out of scope and MUST NOT be built in this spec]
+```
+
+## Important Constraints
+
+1. **Always search for reusable code** before specifying new components
+2. **Reference visual assets** when available
+3. **Do NOT write actual code** in the spec
+4. **Keep each section short**, with clear, direct, skimmable specifications
+5. **Do NOT deviate from the template above** and do not add additional sections
+
+
+## Display confirmation and next step
+
+Display the following message to the user:
+
+```
+The spec has been created at `agent-os/specs/[this-spec]/spec.md`.
+
+Review it closely to ensure everything aligns with your vision and requirements.
+
+Next step: Run the command, 2-create-tasks-list.md
+```
+
+## User Standards & Preferences Compliance
+
+IMPORTANT: Ensure that the specification document's content is ALIGNED and DOES NOT CONFLICT with the user's preferences and standards as detailed in the following files:
+
+@agent-os/standards/backend/api.md
+@agent-os/standards/backend/migrations.md
+@agent-os/standards/backend/models.md
+@agent-os/standards/backend/queries.md
+@agent-os/standards/frontend/accessibility.md
+@agent-os/standards/frontend/components.md
+@agent-os/standards/frontend/css.md
+@agent-os/standards/frontend/responsive.md
+@agent-os/standards/global/coding-style.md
+@agent-os/standards/global/commenting.md
+@agent-os/standards/global/conventions.md
+@agent-os/standards/global/error-handling.md
+@agent-os/standards/global/tech-stack.md
+@agent-os/standards/global/validation.md
+@agent-os/standards/testing/test-writing.md

package/src/template/agent-os/config.yml

@@ -0,0 +1,13 @@
+version: 2.1.1
+last_compiled: 2025-12-19 14:03:25
+
+# ================================================
+# Compiled with the following settings:
+#
+# To change these settings, run ~/agent-os/scripts/project-update.sh to re-compile your project with the new settings.
+# ================================================
+profile: default
+claude_code_commands: true
+use_claude_code_subagents: true
+agent_os_commands: true
+standards_as_claude_code_skills: false

package/src/template/agent-os/product/mission.md

@@ -0,0 +1,29 @@
+# Product Mission
+
+## Pitch
+[Your Product Name] is a **[Category/Platform]** that helps **[Target Audience]** **[Solve Key Problem]**
+by providing **[Unique Value Proposition/Solution]**.
+
+## Users
+
+### Primary Customers
+- **[Customer Segment 1]**: [Description]
+- **[Customer Segment 2]**: [Description]
+
+### User Personas
+**[Persona Name]** (Age)
+- **Role:** [Role]
+- **Context:** [Context]
+- **Pain Points:** [Pain Points]
+- **Goals:** [Legacy Goals]
+
+## The Problem
+[Describe the problem your product solves]
+
+## Differentiators
+- **[Differentiator 1]**: [Description]
+- **[Differentiator 2]**: [Description]
+
+## Key Features
+- **[Feature 1]**: [Description]
+- **[Feature 2]**: [Description]

package/src/template/agent-os/product/roadmap.md

@@ -0,0 +1,9 @@
+# Product Roadmap
+
+## Q1 Goals
+- [ ] **MVP Launch**: Core features implemented and deployed.
+- [ ] **First User**: Onboard the first pilot user.
+
+## backlog
+- [ ] **Feature A**: Description
+- [ ] **Feature B**: Description

package/src/template/agent-os/product/tech-stack.md

@@ -0,0 +1,14 @@
+# Tech Stack
+
+## Core
+- **Frontend**: React, Vite, TailwindCSS
+- **Backend**: Node.js, Express (if applicable)
+- **Database**: [Database choice]
+
+## Infrastructure
+- **Hosting**: [Hosting provider]
+- **CI/CD**: [Pipeline tool]
+
+## Tools
+- **Design**: Figma
+- **Planning**: Agent OS

package/src/template/agent-os/specs/README.md

@@ -0,0 +1 @@
+# Specs

package/src/template/agent-os/standards/backend/api.md

@@ -0,0 +1,10 @@
+## API endpoint standards and conventions
+
+- **RESTful Design**: Follow REST principles with clear resource-based URLs and appropriate HTTP methods (GET, POST, PUT, PATCH, DELETE)
+- **Consistent Naming**: Use consistent, lowercase, hyphenated or underscored naming conventions for endpoints across the API
+- **Versioning**: Implement API versioning strategy (URL path or headers) to manage breaking changes without disrupting existing clients
+- **Plural Nouns**: Use plural nouns for resource endpoints (e.g., `/users`, `/products`) for consistency
+- **Nested Resources**: Limit nesting depth to 2-3 levels maximum to keep URLs readable and maintainable
+- **Query Parameters**: Use query parameters for filtering, sorting, pagination, and search rather than creating separate endpoints
+- **HTTP Status Codes**: Return appropriate, consistent HTTP status codes that accurately reflect the response (200, 201, 400, 404, 500, etc.)
+- **Rate Limiting Headers**: Include rate limit information in response headers to help clients manage their usage

package/src/template/agent-os/standards/backend/migrations.md

@@ -0,0 +1,9 @@
+## Database migration best practices
+
+- **Reversible Migrations**: Always implement rollback/down methods to enable safe migration reversals
+- **Small, Focused Changes**: Keep each migration focused on a single logical change for clarity and easier troubleshooting
+- **Zero-Downtime Deployments**: Consider deployment order and backwards compatibility for high-availability systems
+- **Separate Schema and Data**: Keep schema changes separate from data migrations for better rollback safety
+- **Index Management**: Create indexes on large tables carefully, using concurrent options when available to avoid locks
+- **Naming Conventions**: Use clear, descriptive names that indicate what the migration does
+- **Version Control**: Always commit migrations to version control and never modify existing migrations after deployment

package/src/template/agent-os/standards/backend/models.md

@@ -0,0 +1,10 @@
+## Database model best practices
+
+- **Clear Naming**: Use singular names for models and plural for tables following your framework's conventions
+- **Timestamps**: Include created and updated timestamps on all tables for auditing and debugging
+- **Data Integrity**: Use database constraints (NOT NULL, UNIQUE, foreign keys) to enforce data rules at the database level
+- **Appropriate Data Types**: Choose data types that match the data's purpose and size requirements
+- **Indexes on Foreign Keys**: Index foreign key columns and other frequently queried fields for performance
+- **Validation at Multiple Layers**: Implement validation at both model and database levels for defense in depth
+- **Relationship Clarity**: Define relationships clearly with appropriate cascade behaviors and naming conventions
+- **Avoid Over-Normalization**: Balance normalization with practical query performance needs

package/src/template/agent-os/standards/backend/queries.md

@@ -0,0 +1,9 @@
+## Database query best practices
+
+- **Prevent SQL Injection**: Always use parameterized queries or ORM methods; never interpolate user input into SQL strings
+- **Avoid N+1 Queries**: Use eager loading or joins to fetch related data in a single query instead of multiple queries
+- **Select Only Needed Data**: Request only the columns you need rather than using SELECT * for better performance
+- **Index Strategic Columns**: Index columns used in WHERE, JOIN, and ORDER BY clauses for query optimization
+- **Use Transactions for Related Changes**: Wrap related database operations in transactions to maintain data consistency
+- **Set Query Timeouts**: Implement timeouts to prevent runaway queries from impacting system performance
+- **Cache Expensive Queries**: Cache results of complex or frequently-run queries when appropriate

package/src/template/agent-os/standards/frontend/accessibility.md

@@ -0,0 +1,10 @@
+## UI accessibility best practices
+
+- **Semantic HTML**: Use appropriate HTML elements (nav, main, button, etc.) that convey meaning to assistive technologies
+- **Keyboard Navigation**: Ensure all interactive elements are accessible via keyboard with visible focus indicators
+- **Color Contrast**: Maintain sufficient contrast ratios (4.5:1 for normal text) and don't rely solely on color to convey information
+- **Alternative Text**: Provide descriptive alt text for images and meaningful labels for all form inputs
+- **Screen Reader Testing**: Test and verify that all views are accessible on screen reading devices.
+- **ARIA When Needed**: Use ARIA attributes to enhance complex components when semantic HTML isn't sufficient
+- **Logical Heading Structure**: Use heading levels (h1-h6) in proper order to create a clear document outline
+- **Focus Management**: Manage focus appropriately in dynamic content, modals, and single-page applications

package/src/template/agent-os/standards/frontend/components.md

@@ -0,0 +1,11 @@
+## UI component best practices
+
+- **Single Responsibility**: Each component should have one clear purpose and do it well
+- **Reusability**: Design components to be reused across different contexts with configurable props
+- **Composability**: Build complex UIs by combining smaller, simpler components rather than monolithic structures
+- **Clear Interface**: Define explicit, well-documented props with sensible defaults for ease of use
+- **Encapsulation**: Keep internal implementation details private and expose only necessary APIs
+- **Consistent Naming**: Use clear, descriptive names that indicate the component's purpose and follow team conventions
+- **State Management**: Keep state as local as possible; lift it up only when needed by multiple components
+- **Minimal Props**: Keep the number of props manageable; if a component needs many props, consider composition or splitting it
+- **Documentation**: Document component usage, props, and provide examples for easier adoption by team members

package/src/template/agent-os/standards/frontend/css.md

@@ -0,0 +1,7 @@
+## CSS best practices
+
+- **Consistent Methodology**: Apply and stick to the project's consistent CSS methodology (Tailwind, BEM, utility classes, CSS modules, etc.) across the entire project
+- **Avoid Overriding Framework Styles**: Work with your framework's patterns rather than fighting against them with excessive overrides
+- **Maintain Design System**: Establish and document design tokens (colors, spacing, typography) for consistency
+- **Minimize Custom CSS**: Leverage framework utilities and components to reduce custom CSS maintenance burden
+- **Performance Considerations**: Optimize for production with CSS purging/tree-shaking to remove unused styles

package/src/template/agent-os/standards/frontend/responsive.md

@@ -0,0 +1,11 @@
+## Responsive design best practices
+
+- **Mobile-First Development**: Start with mobile layout and progressively enhance for larger screens
+- **Standard Breakpoints**: Consistently use standard breakpoints across the application (e.g., mobile, tablet, desktop)
+- **Fluid Layouts**: Use percentage-based widths and flexible containers that adapt to screen size
+- **Relative Units**: Prefer rem/em units over fixed pixels for better scalability and accessibility
+- **Test Across Devices**: Test and verify UI changes across multiple screen sizes from mobile to tablet to desktop screen sizes and ensure a balanced, user-friendly viewing and reading experience on all
+- **Touch-Friendly Design**: Ensure tap targets are appropriately sized (minimum 44x44px) for mobile users
+- **Performance on Mobile**: Optimize images and assets for mobile network conditions and smaller screens
+- **Readable Typography**: Maintain readable font sizes across all breakpoints without requiring zoom
+- **Content Priority**: Show the most important content first on smaller screens through thoughtful layout decisions

package/src/template/agent-os/standards/global/coding-style.md

@@ -0,0 +1,10 @@
+## Coding style best practices
+
+- **Consistent Naming Conventions**: Establish and follow naming conventions for variables, functions, classes, and files across the codebase
+- **Automated Formatting**: Maintain consistent code style (indenting, line breaks, etc.)
+- **Meaningful Names**: Choose descriptive names that reveal intent; avoid abbreviations and single-letter variables except in narrow contexts
+- **Small, Focused Functions**: Keep functions small and focused on a single task for better readability and testability
+- **Consistent Indentation**: Use consistent indentation (spaces or tabs) and configure your editor/linter to enforce it
+- **Remove Dead Code**: Delete unused code, commented-out blocks, and imports rather than leaving them as clutter
+- **Backward compatibility only when required:** Unless specifically instructed otherwise, assume you do not need to write additional code logic to handle backward compatibility.
+- **DRY Principle**: Avoid duplication by extracting common logic into reusable functions or modules

package/src/template/agent-os/standards/global/commenting.md

@@ -0,0 +1,5 @@
+## Code commenting best practices
+
+- **Self-Documenting Code**: Write code that explains itself through clear structure and naming
+- **Minimal, helpful comments**: Add concise, minimal comments to explain large sections of code logic.
+- **Don't comment changes or fixes**: Do not leave code comments that speak to recent or temporary changes or fixes. Comments should be evergreen informational texts that are relevant far into the future.