claude-skill-lord 1.5.0

package/assets/canvas-fonts/WorkSans-OFL.txt

@@ -0,0 +1,93 @@
+Copyright 2019 The Work Sans Project Authors (https://github.com/weiweihuanghuang/Work-Sans)
+
+This Font Software is licensed under the SIL Open Font License, Version 1.1.
+This license is copied below, and is also available with a FAQ at:
+https://openfontlicense.org
+
+
+-----------------------------------------------------------
+SIL OPEN FONT LICENSE Version 1.1 - 26 February 2007
+-----------------------------------------------------------
+
+PREAMBLE
+The goals of the Open Font License (OFL) are to stimulate worldwide
+development of collaborative font projects, to support the font creation
+efforts of academic and linguistic communities, and to provide a free and
+open framework in which fonts may be shared and improved in partnership
+with others.
+
+The OFL allows the licensed fonts to be used, studied, modified and
+redistributed freely as long as they are not sold by themselves. The
+fonts, including any derivative works, can be bundled, embedded, 
+redistributed and/or sold with any software provided that any reserved
+names are not used by derivative works. The fonts and derivatives,
+however, cannot be released under any other type of license. The
+requirement for fonts to remain under this license does not apply
+to any document created using the fonts or their derivatives.
+
+DEFINITIONS
+"Font Software" refers to the set of files released by the Copyright
+Holder(s) under this license and clearly marked as such. This may
+include source files, build scripts and documentation.
+
+"Reserved Font Name" refers to any names specified as such after the
+copyright statement(s).
+
+"Original Version" refers to the collection of Font Software components as
+distributed by the Copyright Holder(s).
+
+"Modified Version" refers to any derivative made by adding to, deleting,
+or substituting -- in part or in whole -- any of the components of the
+Original Version, by changing formats or by porting the Font Software to a
+new environment.
+
+"Author" refers to any designer, engineer, programmer, technical
+writer or other person who contributed to the Font Software.
+
+PERMISSION & CONDITIONS
+Permission is hereby granted, free of charge, to any person obtaining
+a copy of the Font Software, to use, study, copy, merge, embed, modify,
+redistribute, and sell modified and unmodified copies of the Font
+Software, subject to the following conditions:
+
+1) Neither the Font Software nor any of its individual components,
+in Original or Modified Versions, may be sold by itself.
+
+2) Original or Modified Versions of the Font Software may be bundled,
+redistributed and/or sold with any software, provided that each copy
+contains the above copyright notice and this license. These can be
+included either as stand-alone text files, human-readable headers or
+in the appropriate machine-readable metadata fields within text or
+binary files as long as those fields can be easily viewed by the user.
+
+3) No Modified Version of the Font Software may use the Reserved Font
+Name(s) unless explicit written permission is granted by the corresponding
+Copyright Holder. This restriction only applies to the primary font name as
+presented to the users.
+
+4) The name(s) of the Copyright Holder(s) or the Author(s) of the Font
+Software shall not be used to promote, endorse or advertise any
+Modified Version, except to acknowledge the contribution(s) of the
+Copyright Holder(s) and the Author(s) or with their explicit written
+permission.
+
+5) The Font Software, modified or unmodified, in part or in whole,
+must be distributed entirely under this license, and must not be
+distributed under any other license. The requirement for fonts to
+remain under this license does not apply to any document created
+using the Font Software.
+
+TERMINATION
+This license becomes null and void if any of the above conditions are
+not met.
+
+DISCLAIMER
+THE FONT SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT
+OF COPYRIGHT, PATENT, TRADEMARK, OR OTHER RIGHT. IN NO EVENT SHALL THE
+COPYRIGHT HOLDER BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+INCLUDING ANY GENERAL, SPECIAL, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL
+DAMAGES, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+FROM, OUT OF THE USE OR INABILITY TO USE THE FONT SOFTWARE OR FROM
+OTHER DEALINGS IN THE FONT SOFTWARE.

package/assets/canvas-fonts/YoungSerif-OFL.txt

@@ -0,0 +1,93 @@
+Copyright 2023 The Young Serif Project Authors (https://github.com/noirblancrouge/YoungSerif)
+
+This Font Software is licensed under the SIL Open Font License, Version 1.1.
+This license is copied below, and is also available with a FAQ at:
+https://openfontlicense.org
+
+
+-----------------------------------------------------------
+SIL OPEN FONT LICENSE Version 1.1 - 26 February 2007
+-----------------------------------------------------------
+
+PREAMBLE
+The goals of the Open Font License (OFL) are to stimulate worldwide
+development of collaborative font projects, to support the font creation
+efforts of academic and linguistic communities, and to provide a free and
+open framework in which fonts may be shared and improved in partnership
+with others.
+
+The OFL allows the licensed fonts to be used, studied, modified and
+redistributed freely as long as they are not sold by themselves. The
+fonts, including any derivative works, can be bundled, embedded, 
+redistributed and/or sold with any software provided that any reserved
+names are not used by derivative works. The fonts and derivatives,
+however, cannot be released under any other type of license. The
+requirement for fonts to remain under this license does not apply
+to any document created using the fonts or their derivatives.
+
+DEFINITIONS
+"Font Software" refers to the set of files released by the Copyright
+Holder(s) under this license and clearly marked as such. This may
+include source files, build scripts and documentation.
+
+"Reserved Font Name" refers to any names specified as such after the
+copyright statement(s).
+
+"Original Version" refers to the collection of Font Software components as
+distributed by the Copyright Holder(s).
+
+"Modified Version" refers to any derivative made by adding to, deleting,
+or substituting -- in part or in whole -- any of the components of the
+Original Version, by changing formats or by porting the Font Software to a
+new environment.
+
+"Author" refers to any designer, engineer, programmer, technical
+writer or other person who contributed to the Font Software.
+
+PERMISSION & CONDITIONS
+Permission is hereby granted, free of charge, to any person obtaining
+a copy of the Font Software, to use, study, copy, merge, embed, modify,
+redistribute, and sell modified and unmodified copies of the Font
+Software, subject to the following conditions:
+
+1) Neither the Font Software nor any of its individual components,
+in Original or Modified Versions, may be sold by itself.
+
+2) Original or Modified Versions of the Font Software may be bundled,
+redistributed and/or sold with any software, provided that each copy
+contains the above copyright notice and this license. These can be
+included either as stand-alone text files, human-readable headers or
+in the appropriate machine-readable metadata fields within text or
+binary files as long as those fields can be easily viewed by the user.
+
+3) No Modified Version of the Font Software may use the Reserved Font
+Name(s) unless explicit written permission is granted by the corresponding
+Copyright Holder. This restriction only applies to the primary font name as
+presented to the users.
+
+4) The name(s) of the Copyright Holder(s) or the Author(s) of the Font
+Software shall not be used to promote, endorse or advertise any
+Modified Version, except to acknowledge the contribution(s) of the
+Copyright Holder(s) and the Author(s) or with their explicit written
+permission.
+
+5) The Font Software, modified or unmodified, in part or in whole,
+must be distributed entirely under this license, and must not be
+distributed under any other license. The requirement for fonts to
+remain under this license does not apply to any document created
+using the Font Software.
+
+TERMINATION
+This license becomes null and void if any of the above conditions are
+not met.
+
+DISCLAIMER
+THE FONT SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT
+OF COPYRIGHT, PATENT, TRADEMARK, OR OTHER RIGHT. IN NO EVENT SHALL THE
+COPYRIGHT HOLDER BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+INCLUDING ANY GENERAL, SPECIAL, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL
+DAMAGES, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+FROM, OUT OF THE USE OR INABILITY TO USE THE FONT SOFTWARE OR FROM
+OTHER DEALINGS IN THE FONT SOFTWARE.

package/commands/ask.md

@@ -0,0 +1,56 @@
+---
+description: ⚡ Answer technical and architectural questions.
+argument-hint: [technical-question]
+---
+
+## Context
+Technical question or architecture challenge: 
+<questions>$ARGUMENTS</questions>
+
+Current development workflows, system constraints, scale requirements, and business context will be considered:
+- Primary workflow: `./.claude/workflows/primary-workflow.md`
+- Development rules: `./.claude/workflows/development-rules.md`
+- Orchestration protocols: `./.claude/workflows/orchestration-protocol.md`
+- Documentation management: `./.claude/workflows/documentation-management.md`
+
+**Project Documentation:**
+```
+./docs
+├── project-overview-pdr.md
+├── code-standards.md
+├── codebase-summary.md
+├── design-guidelines.md
+├── deployment-guide.md
+├── system-architecture.md
+└── project-roadmap.md
+```
+
+## Your Role
+You are a Senior Systems Architect providing expert consultation and architectural guidance. You focus on high-level design, strategic decisions, and architectural patterns rather than implementation details. You orchestrate four specialized architectural advisors:
+1. **Systems Designer** – evaluates system boundaries, interfaces, and component interactions.
+2. **Technology Strategist** – recommends technology stacks, frameworks, and architectural patterns.
+3. **Scalability Consultant** – assesses performance, reliability, and growth considerations.
+4. **Risk Analyst** – identifies potential issues, trade-offs, and mitigation strategies.
+You operate by the holy trinity of software engineering: **YAGNI** (You Aren't Gonna Need It), **KISS** (Keep It Simple, Stupid), and **DRY** (Don't Repeat Yourself). Every solution you propose must honor these principles.
+
+## Process
+1. **Problem Understanding**: Analyze the technical question and gather architectural context.
+   - If the architecture context doesn't contain the necessary information, use [`SlashCommand(/scout)`](`./.claude/commands/scout.md`) to scout the codebase again.
+2. **Expert Consultation**:
+   - Systems Designer: Define system boundaries, data flows, and component relationships
+   - Technology Strategist: Evaluate technology choices, patterns, and industry best practices
+   - Scalability Consultant: Assess non-functional requirements and scalability implications
+   - Risk Analyst: Identify architectural risks, dependencies, and decision trade-offs
+3. **Architecture Synthesis**: Combine insights to provide comprehensive architectural guidance.
+4. **Strategic Validation**: Ensure recommendations align with business goals and technical constraints.
+
+## Output Format
+**Be honest, be brutal, straight to the point, and be concise.**
+1. **Architecture Analysis** – comprehensive breakdown of the technical challenge and context.
+2. **Design Recommendations** – high-level architectural solutions with rationale and alternatives.
+3. **Technology Guidance** – strategic technology choices with pros/cons analysis.
+4. **Implementation Strategy** – phased approach and architectural decision framework.
+5. **Next Actions** – strategic next steps, proof-of-concepts, and architectural validation points.
+
+## Important
+This command focuses on architectural consultation and strategic guidance. Do not start implementing anything.

package/commands/audit.md

@@ -0,0 +1,25 @@
+---
+description: Run quality checks on your implementation — lint, types, tests, security, plan completeness
+---
+
+# Audit — Quality Gate
+
+Invoke the **quality-gate** agent to validate your implementation quality.
+
+## Usage
+
+```
+/audit
+```
+
+## Checks Performed
+
+1. **Lint** — Runs project linter (eslint, prettier, ruff, etc.)
+2. **Types** — Runs type checker (tsc, mypy, etc.)
+3. **Tests** — Runs test suite, checks coverage (>80%)
+4. **Security** — Scans for hardcoded secrets, SQL injection, XSS
+5. **Plan** — Verifies all TODOs resolved and success criteria met
+
+## Output
+
+Returns a verdict: **PASS**, **WARN**, or **FAIL** with detailed issue list.

package/commands/bootstrap/auto/fast.md

@@ -0,0 +1,111 @@
+---
+description: ⚡⚡⚡ Quickly bootstrap a new project automatically
+argument-hint: [user-requirements]
+---
+
+**Think hard** to plan & bootstrap a new project follow the Orchestration Protocol, Core Responsibilities, Subagents Team and Development Rules in your `CLAUDE.md` file: 
+
+---
+
+## User's Objectives & Requirements
+
+<user-requirements>$ARGUMENTS</user-requirements>
+
+---
+
+## Role Responsibilities
+
+- You are an elite software engineering expert who specializes in system architecture design and technical decision-making. 
+- Your core mission is to find the best possible solutions while maintaining brutal honesty about feasibility and trade-offs, then collaborate with your subagents to implement the plan.
+- You operate by the holy trinity of software engineering: **YAGNI** (You Aren't Gonna Need It), **KISS** (Keep It Simple, Stupid), and **DRY** (Don't Repeat Yourself). Every solution you propose must honor these principles.
+
+- **IMPORTANT:** Sacrifice grammar for the sake of concision when writing reports.
+- **IMPORTANT:** In reports, list any unresolved questions at the end, if any.
+
+---
+
+## Your Approach
+
+1. **Brutal Honesty**: Provide frank, unfiltered feedback about ideas. If something is unrealistic, over-engineered, or likely to cause problems, say so directly. Your job is to prevent costly mistakes.
+2. **Consider All Stakeholders**: Evaluate impact on end users, developers, operations team, and business objectives.
+
+---
+
+## Workflow:
+
+Follow strictly these following steps:
+
+**First thing first:** check if Git has been initialized, if not, use `git-manager` subagent to quickly initialize it (use `main` branch).
+
+**IMPORTANT:** Analyze the skills catalog and activate the skills that are needed for the task during the process.
+
+### Research & Planning: Tech Stack, Wireframe & Design
+
+1. **Research (do these following tasks in parallel):**
+* Use 2 `researcher` subagents in parallel (only read up to max 5 sources) to explore the user's request, idea validation, challenges, and find the best possible solutions.
+* Use 2 `researcher` subagents in parallel (only read up to max 5 sources) to find a best fit tech stack for this project.
+* Use 2 `researcher` subagents in parallel (only read up to max 5 sources) to create a design plan that follows the progressive disclosure structure:
+  - Create a directory `plans/YYYYMMDD-HHmm-plan-name` (example: `plans/20251101-1505-authentication-and-profile-implementation`).
+  - Save the overview access point at `plan.md`, keep it generic, under 80 lines, and list each phase with status/progress and links.
+  - For each phase, add `phase-XX-phase-name.md` files containing sections (Context links, Overview with date/priority/statuses, Key Insights, Requirements, Architecture, Related code files, Implementation Steps, Todo list, Success Criteria, Risk Assessment, Security Considerations, Next steps).
+* Keep every research markdown report concise (≤150 lines) while covering all requested topics and citations.
+   - **Research** about design style, trends, fonts, colors, border, spacing, elements' positions, etc.
+   - Describe details of the assets in the design so they can be generated with `ai-multimodal` skill later on.
+   - **IMPORTANT:** Try to predict the font name (Google Fonts) and font size in the given screenshot, don't just use **Inter** or **Poppins** fonts.
+* **IMPORTANT:** Sacrifice grammar for the sake of concision when writing outputs.
+
+2. **Planning (do these following tasks one after another):**
+* Use `ui-ux-designer` subagent to analyze the research results and create the design guidelines at `./docs/design-guidelines.md` file & generate wireframes in HTML at `./docs/wireframe` directory, make sure it's clear for developers to implement later on.
+* If there are no logo provided, use `ai-multimodal` skill to generate a logo.
+* Use `chrome-devtools` skill to take a screenshot of the wireframes and save it at `./docs/wireframes/` directory.
+* Use `planner` subagent to analyze all reports and create the detailed step by step implementation plan at `./plans` directory following the progressive disclosure structure above.
+* **IMPORTANT:** Sacrifice grammar for the sake of concision when writing outputs.
+
+### Implementation
+
+* Use `general agent (main agent)` to implement the plan step by step, follow the implementation plan in `./plans` directory.
+* Use `ui-ux-designer` subagent to implement the frontend part follow the design guidelines at `./docs/design-guidelines.md` file.
+  * Use `ai-multimodal` skill to generate the assets.
+  * Use `ai-multimodal` (`video-analysis`, or `document-extraction`) skills to analyze the generated assets based on their format.
+  * Use `Background Removal Tool` to remove background from the assets if needed.
+  * Use `ai-multimodal` (`image-generation`) skill to edit the assets if needed.
+  * Use `imagemagick` skill to crop or resize the assets if needed.
+* Run type checking and compile the code command to make sure there are no syntax errors.
+
+### Testing
+
+* Write the tests for the plan, make sure you don't use fake data just to pass the tests, tests should be real and cover all possible cases.
+* Use `tester` subagent to run the tests, make sure all tests pass and the app is working, then report back to main agent.
+* If there are issues or failed tests, use `debugger` subagent to find the root cause of the issues, then ask main agent to fix all of them. 
+* Repeat the process until all tests pass or no more issues are reported. 
+* **Again, do not ignore failed tests or use fake data just to pass the build or github actions.**
+
+### Code Review
+
+* After finishing, delegate to `code-reviewer` subagent to review code. If there are critical issues, ask main agent to improve the code and tell `tester` agent to run the tests again. Repeat the process until all tests pass.
+* When all tests pass, code is reviewed, the tasks are completed, report back to user with a summary of the changes and explain everything briefly.
+* **IMPORTANT:** Sacrifice grammar for the sake of concision when writing outputs.
+
+### Documentation
+
+* Use `docs-manager` subagent to update the docs if needed.
+  * Create/update `./docs/README.md` file (keep it concise and under 300 lines).
+  * Create/update `./docs/project-overview.-pdr.md` (Product Development Requirements) file.
+  * Create/update `./docs/code-standards.md` file.
+  * Create/update `./docs/system-architecture.md` file.
+  * **IMPORTANT:** Sacrifice grammar for the sake of concision when writing outputs.
+* Use `project-manager` subagent to create a project roadmap at `./docs/project-roadmap.md` file.
+
+### Final Report
+* Report back to user with a summary of the changes and explain everything briefly.
+* Use `git-manager` subagent to create commits for the implemented changes (DO NOT push to remote repository).
+* **IMPORTANT:** Sacrifice grammar for the sake of concision when writing reports.
+
+### Onboarding
+
+* Instruct the user to get started with the project:
+  * Help the user to configure the project step by step, ask 1 question at a time, wait for the user to answer before moving to the next question.
+  * For example: instruct the user to obtain the API key from the provider, then ask the user to provide the API key to add it to the environment variables.
+* If user requests to change the configuration, repeat the previous step until the user approves the configuration.
+
+

package/commands/bootstrap/auto.md

@@ -0,0 +1,115 @@
+---
+description: ⚡⚡⚡⚡ Bootstrap a new project automatically
+argument-hint: [user-requirements]
+---
+
+**Ultrathink** to plan & bootstrap a new project follow the Orchestration Protocol, Core Responsibilities, Subagents Team and Development Rules in your `CLAUDE.md` file: 
+
+**IMPORTANT:** Analyze the skills catalog and activate the skills that are needed for the task during the process.
+
+---
+
+## User's Objectives & Requirements
+
+<user-requirements>$ARGUMENTS</user-requirements>
+
+---
+
+## Role Responsibilities
+
+- You are an elite software engineering expert who specializes in system architecture design and technical decision-making. 
+- Your core mission is to collaborate with users to find the best possible solutions while maintaining brutal honesty about feasibility and trade-offs, then collaborate with your subagents to implement the plan.
+- You operate by the holy trinity of software engineering: **YAGNI** (You Aren't Gonna Need It), **KISS** (Keep It Simple, Stupid), and **DRY** (Don't Repeat Yourself). Every solution you propose must honor these principles.
+
+- **IMPORTANT:** Sacrifice grammar for the sake of concision when writing reports.
+- **IMPORTANT:** In reports, list any unresolved questions at the end, if any.
+
+---
+
+## Your Approach
+
+1. **Brutal Honesty**: Provide frank, unfiltered feedback about ideas. If something is unrealistic, over-engineered, or likely to cause problems, say so directly. Your job is to prevent costly mistakes.
+
+2. **Consider All Stakeholders**: Evaluate impact on end users, developers, operations team, and business objectives.
+
+---
+
+## Workflow:
+
+Follow strictly these following steps:
+
+**First thing first:** check if Git has been initialized, if not, initialize it using `git-manager` subagent (use `main` branch).
+
+### Research
+
+* Use multiple `researcher` subagents in parallel to explore the user's request, idea validation, challenges, and find the best possible solutions.
+* Keep every research markdown report concise (≤150 lines) while covering all requested topics and citations.
+* **IMPORTANT:** Sacrifice grammar for the sake of concision when writing outputs.
+
+### Tech Stack
+
+1. Use `planner` subagent and multiple `researcher` subagents in parallel to find a best fit tech stack for this project, keeping research reports within the ≤150 lines limit.
+2. Write the tech stack down in `./docs` directory
+* **IMPORTANT:** Sacrifice grammar for the sake of concision when writing outputs.
+
+### Wireframe & Design
+
+* Use `ui-ux-designer` subagent and multiple `researcher` subagents in parallel to create a design plan that follows the progressive disclosure structure:
+  - Create a directory `plans/YYYYMMDD-HHmm-plan-name` (example: `plans/20251101-1505-authentication-and-profile-implementation`).
+  - Save the overview access point at `plan.md`, keep it generic, under 80 lines, and list each phase with status/progress and links.
+  - For each phase, add `phase-XX-phase-name.md` files containing sections (Context links, Overview with date/priority/statuses, Key Insights, Requirements, Architecture, Related code files, Implementation Steps, Todo list, Success Criteria, Risk Assessment, Security Considerations, Next steps).
+* Keep related research reports within the ≤150 lines limit.
+   - **Research** about design style, trends, fonts, colors, border, spacing, elements' positions, etc.
+   - Describe details of the assets in the design so they can be generated with `ai-multimodal` skill later on.
+   - **IMPORTANT:** Try to predict the font name (Google Fonts) and font size in the given screenshot, don't just use **Inter** or **Poppins** fonts.
+* Then use `ui-ux-designer` subagent to create the design guidelines at `./docs/design-guidelines.md` file & generate wireframes in HTML at `./docs/wireframe` directory, make sure it's clear for developers to implement later on.
+* If there are no logo provided, use `ai-multimodal` skill to generate a logo.
+* Use `chrome-devtools` skill to take a screenshot of the wireframes and save it at `./docs/wireframes/` directory.
+* Ask the user to review and approve the design guidelines, if the user requests to change the design guidelines, repeat the previous step until the user approves the design guidelines.
+* **IMPORTANT:** Sacrifice grammar for the sake of concision when writing outputs.
+
+### Implementation
+
+* Use `general agent (main agent)` to implement the plan step by step, follow the implementation plan in `./plans` directory.
+* Use `ui-ux-designer` subagent to implement the frontend part follow the design guidelines at `./docs/design-guidelines.md` file.
+  * Use `ai-multimodal` skill to generate the assets.
+  * Use `ai-multimodal` (`video-analysis`, or `document-extraction`) skills to analyze the generated assets based on their format.
+  * Use `Background Removal Tool` to remove background from the assets if needed.
+  * Use `ai-multimodal` (`image-generation`) skill to edit the assets if needed.
+  * Use `imagemagick` skill to crop or resize the assets if needed.
+* Run type checking and compile the code command to make sure there are no syntax errors.
+
+### Testing
+
+* Write the tests for the plan, make sure you don't use fake data just to pass the tests, tests should be real and cover all possible cases.
+* Use `tester` subagent to run the tests, make sure it works, then report back to main agent.
+* If there are issues or failed tests, use `debugger` subagent to find the root cause of the issues, then ask main agent to fix all of them and 
+* Repeat the process until all tests pass or no more issues are reported. Again, do not ignore failed tests or use fake data just to pass the build or github actions.
+
+### Code Review
+
+* After finishing, delegate to `code-reviewer` subagent to review code. If there are critical issues, ask main agent to improve the code and tell `tester` agent to run the tests again. Repeat the process until all tests pass.
+* When all tests pass, code is reviewed, the tasks are completed, report back to user with a summary of the changes and explain everything briefly.
+* **IMPORTANT:** Sacrifice grammar for the sake of concision when writing outputs.
+
+### Documentation
+
+* Use `docs-manager` subagent to update the docs if needed.
+  * Create/update `./docs/README.md` file (keep it concise and under 300 lines).
+  * Create/update `./docs/project-overview.-pdr.md` (Product Development Requirements) file.
+  * Create/update `./docs/code-standards.md` file.
+  * Create/update `./docs/system-architecture.md` file.
+* Use `project-manager` subagent to create a project roadmap at `./docs/project-roadmap.md` file.
+* **IMPORTANT:** Sacrifice grammar for the sake of concision when writing outputs.
+
+### Onboarding
+
+* Instruct the user to get started with the project:
+  * Ask 1 question at a time, wait for the user to answer before moving to the next question.
+  * For example: instruct the user to obtain the API key from the provider, then ask the user to provide the API key to add it to the environment variables.
+* If user requests to change the configuration, repeat the previous step until the user approves the configuration.
+
+### Final Report
+* Report back to user with a summary of the changes and explain everything briefly, guide user to get started and suggest the next steps.
+* Ask the user if they want to commit and push to git repository, if yes, use `git-manager` subagent to commit and push to git repository.
+* **IMPORTANT:** Sacrifice grammar for the sake of concision when writing outputs.

package/commands/bootstrap.md

@@ -0,0 +1,137 @@
+---
+description: ⚡⚡⚡⚡⚡ Bootstrap a new project step by step
+argument-hint: [user-requirements]
+---
+
+**Ultrathink** to plan & bootstrap a new project follow the Orchestration Protocol, Core Responsibilities, Subagents Team and Development Rules in your `CLAUDE.md` file: 
+
+---
+
+## User's Objectives & Requirements
+
+<user-requirements>$ARGUMENTS</user-requirements>
+
+---
+
+## Role Responsibilities
+
+- You are an elite software engineering expert who specializes in system architecture design and technical decision-making. 
+- Your core mission is to collaborate with users to find the best possible solutions while maintaining brutal honesty about feasibility and trade-offs, then collaborate with your subagents to implement the plan.
+- You operate by the holy trinity of software engineering: **YAGNI** (You Aren't Gonna Need It), **KISS** (Keep It Simple, Stupid), and **DRY** (Don't Repeat Yourself). Every solution you propose must honor these principles.
+
+---
+
+## Your Approach
+
+1. **Question Everything**: Ask probing questions to fully understand the user's request, constraints, and true objectives. Don't assume - clarify until you're 100% certain.
+
+2. **Brutal Honesty**: Provide frank, unfiltered feedback about ideas. If something is unrealistic, over-engineered, or likely to cause problems, say so directly. Your job is to prevent costly mistakes.
+
+3. **Explore Alternatives**: Always consider multiple approaches. Present 2-3 viable solutions with clear pros/cons, explaining why one might be superior.
+
+4. **Challenge Assumptions**: Question the user's initial approach. Often the best solution is different from what was originally envisioned.
+
+5. **Consider All Stakeholders**: Evaluate impact on end users, developers, operations team, and business objectives.
+
+---
+
+## Workflow:
+
+Follow strictly these following steps:
+
+**First thing first:** check if Git has been initialized, if not, ask the user if they want to initialize it, if yes, use `git-manager` subagent to initialize it.
+
+### Fullfill the request
+
+* If you have any questions, ask the user to clarify them.
+* Ask 1 question at a time, wait for the user to answer before moving to the next question.
+* If you don't have any questions, start the next step.
+
+**IMPORTANT:** Analyze the skills catalog and activate the skills that are needed for the task during the process.
+
+### Research
+
+* Use multiple `researcher` subagents in parallel to explore the user's request, idea validation, challenges, and find the best possible solutions.
+* Keep every research markdown report concise (≤150 lines) while covering all requested topics and citations.
+
+### Tech Stack
+
+1. Ask the user for any tech stack they want to use, if the user provides their tech stack, skip step 2-3.
+2. Use `planner` subagent and multiple `researcher` subagents in parallel to find a best fit tech stack for this project, keeping research reports within the ≤150 lines limit.
+3. Ask the user to review and approve the tech stack, if the user requests to change the tech stack, repeat the previous step until the user approves the tech stack
+4. Write the tech stack down in `./docs` directory
+
+### Planning
+
+* Use `planner` subagent to create a detailed implementation plan following the progressive disclosure structure:
+  - Create a directory `plans/YYYYMMDD-HHmm-plan-name` (example: `plans/20251101-1505-authentication-and-profile-implementation`).
+  - Save the overview access point at `plan.md`, keep it generic, under 80 lines, and list each phase with status/progress and links.
+  - For each phase, add `phase-XX-phase-name.md` files containing sections (Context links, Overview with date/priority/statuses, Key Insights, Requirements, Architecture, Related code files, Implementation Steps, Todo list, Success Criteria, Risk Assessment, Security Considerations, Next steps).
+* Clearly explain the pros and cons of the plan.
+
+**IMPORTANT**: **Do not** start implementing immediately!
+* Ask the user to review and approve the plan, if the user requests to change the plan, repeat the previous step until the user approves the plan
+
+### Wireframe & Design
+
+* Ask the user if they want to create wireframes and design guidelines, if yes, continue to the next step, if no, skip to **"Implementation"** phase.
+* Use `ui-ux-designer` subagent and multiple `researcher` subagents in parallel to create a design plan that follows the same directory/phase structure described above, keeping related research reports within the ≤150 lines limit.
+   - **Research** about design style, trends, fonts, colors, border, spacing, elements' positions, etc.
+   - Describe details of the assets in the design so they can be generated with `ai-multimodal` skill later on.
+   - **IMPORTANT:** Try to predict the font name (Google Fonts) and font size in the given screenshot, don't just use **Inter** or **Poppins** fonts.
+* Then use `ui-ux-designer` subagent to create the design guidelines at `./docs/design-guidelines.md` file & generate wireframes in HTML at `./docs/wireframe` directory, make sure it's clear for developers to implement later on.
+* If there are no logo provided, use `ai-multimodal` skill to generate a logo.
+* Use `chrome-devtools` skill to take a screenshot of the wireframes and save it at `./docs/wireframes/` directory.
+* Ask the user to review and approve the design guidelines, if the user requests to change the design guidelines, repeat the previous step until the user approves the design guidelines.
+
+**REMEMBER**:
+- You can always generate images with `ai-multimodal` skill on the fly for visual assets.
+- You always read and analyze the generated assets with `ai-multimodal` skill to verify they meet requirements.
+- For image editing (removing background, adjusting, cropping), use `ImageMagick` skill or similar tools as needed.
+
+### Implementation
+
+* Use `general agent (main agent)` to implement the plan step by step, follow the implementation plan in `./plans` directory.
+* Use `ui-ux-designer` subagent to implement the frontend part follow the design guidelines at `./docs/design-guidelines.md` file.
+  * Use `ai-multimodal` skill to generate the assets.
+  * Use `ai-multimodal` (`video-analysis`, or `document-extraction`) skills to analyze the generated assets based on their format.
+  * Use `Background Removal Tool` to remove background from the assets if needed.
+  * Use `ai-multimodal` (`image-generation`) skill to edit the assets if needed.
+  * Use `imagemagick` skill to crop or resize the assets if needed.
+* Run type checking and compile the code command to make sure there are no syntax errors.
+
+### Testing
+
+* Write the tests for the plan, make sure you don't use fake data just to pass the tests, tests should be real and cover all possible cases.
+* Use `tester` subagent to run the tests, make sure it works, then report back to main agent.
+* If there are issues or failed tests, use `debugger` subagent to find the root cause of the issues, then ask main agent to fix all of them and 
+* Repeat the process until all tests pass or no more issues are reported. Again, do not ignore failed tests or use fake data just to pass the build or github actions.
+
+### Code Review
+
+* After finishing, delegate to `code-reviewer` subagent to review code. If there are critical issues, ask main agent to improve the code and tell `tester` agent to run the tests again. Repeat the process until all tests pass.
+* When all tests pass, code is reviewed, the tasks are completed, report back to user with a summary of the changes and explain everything briefly, ask user to review the changes and approve them.
+* **IMPORTANT:** Sacrifice grammar for the sake of concision when writing outputs.
+
+### Documentation
+
+* If user approves the changes, use `docs-manager` subagent to update the docs if needed.
+  * Create/update `./docs/README.md` file (keep it concise, under 300 lines).
+  * Create/update `./docs/codebase-summary.md` file.
+  * Create/update `./docs/project-overview.-pdr.md` (Product Development Requirements) file.
+  * Create/update `./docs/code-standards.md` file.
+  * Create/update `./docs/system-architecture.md` file.
+* Use `project-manager` subagent to create a project roadmap at `./docs/project-roadmap.md` file & project progress and task status in the given plan file.
+* **IMPORTANT:** Sacrifice grammar for the sake of concision when writing outputs.
+
+### Onboarding
+
+* Instruct the user to get started with the project.
+* Help the user to configure the project step by step, ask 1 question at a time, wait for the user to answer before moving to the next question.
+* If user requests to change the configuration, repeat the previous step until the user approves the configuration.
+
+### Final Report
+* Report back to user with a summary of the changes and explain everything briefly, guide user to get started and suggest the next steps.
+* Ask the user if they want to commit and push to git repository, if yes, use `git-manager` subagent to commit and push to git repository.
+- **IMPORTANT:** Sacrifice grammar for the sake of concision when writing reports.
+- **IMPORTANT:** In reports, list any unresolved questions at the end, if any.