@oriro/orirocli 0.1.8 → 0.1.11

package/skills/technical/technical-writing/SKILL.md

@@ -1,149 +1,149 @@
----
-watermark: ORIRO
-name: technical-writing
-provider: ORIRO.ai
-copyright: Copyright (c) 2026 ORIRO.ai
-description: >
-
-
-
-
-
-
-
-
-
-
-  Technical writing — documentation, READMEs, API docs, tutorials, and communicating technical concepts clearly.
-
-  Sources: Google Search Central, GDPR text, AWS security documentation, Stripe API docs.
----
-
-# Technical Writing
-
-## The fundamentals
-
-### Reader first
-
-Who is reading this? Developer integrating your API? Beginner learning a concept? Ops team deploying your app?
-Write at the reader's level. Don't explain what a variable is to senior engineers. Do explain your unusual naming conventions.
-
-**Docs debt is real.** Out-of-date docs are often worse than no docs — they mislead readers with confidence.
-
-## README structure (for projects)
-
-````markdown
-# Project Name
-
-One sentence: what this is and why it exists.
-
-## Quick start (under 60 seconds to running example)
-
-```bash
-npm install my-package
-```
-````
-
-```ts
-import { MyPackage } from "my-package";
-const result = MyPackage.doThing({ input: "example" });
-console.log(result); // { success: true, output: 'processed' }
-```
-
-## Installation (detailed)
-
-## Configuration
-
-## Usage (common use cases with examples)
-
-## API Reference
-
-## Contributing
-
-## License
-
-````
-
-**Rule:** If it takes more than 5 minutes to go from README to working example, the README has failed.
-
-## API documentation (OpenAPI + prose)
-
-### Document the why, not just the what
-```markdown
-## Authentication
-
-All API requests require a Bearer token in the Authorization header.
-
-**Why:** We use short-lived JWTs (15 min expiry) rather than API keys
-to minimize exposure if a token is leaked in logs or network traffic.
-Long-lived tokens should use the refresh flow instead of storing the
-access token.
-
-### Getting a token
-POST /auth/token with your credentials...
-````
-
-### Annotate code examples
-
-```ts
-// Create a PaymentIntent with automatic_payment_methods enabled.
-// This lets Stripe show the optimal payment options for the customer's
-// location and saves card for future use if setup_future_usage is set.
-const paymentIntent = await stripe.paymentIntents.create({
-  amount: 2000, // Amount in smallest currency unit (cents for USD)
-  currency: "usd",
-  automatic_payment_methods: {
-    enabled: true, // Required for Stripe's adaptive UI
-  },
-});
-
-// Return only the client_secret — NEVER return the full paymentIntent object
-// as it contains server-side only fields.
-return { clientSecret: paymentIntent.client_secret };
-```
-
-## Tutorial writing (the Diátaxis framework)
-
-Four types of documentation (different purposes, should not be mixed):
-**Tutorials:** Learning-oriented. Step-by-step for beginners. "Build your first app in 15 minutes."
-**How-to guides:** Task-oriented. Practical steps for specific goals. "How to set up SSO with Okta."
-**Explanations:** Understanding-oriented. Conceptual depth. "How our caching works."
-**Reference:** Information-oriented. Complete, accurate, dry. API reference, config options.
-
-Mixing these creates docs that are bad at all of them.
-
-## Writing style for technical docs
-
-**Present tense:** "The function returns" not "The function will return."
-**Active voice:** "Call the API" not "The API should be called."
-**Imperative mood for instructions:** "Run the command" not "You should run the command."
-**Concrete:** Show code. Examples are worth more than explanations.
-**Short paragraphs:** Max 3-4 sentences. One idea per paragraph.
-**Scannable:** Headers, lists, code blocks. Nobody reads technical docs linearly.
-
-## Changelog writing
-
-```markdown
-## [2.1.0] - 2024-03-15
-
-### Added
-
-- Streaming support for long-running operations
-- New `timeout` option for all API methods (default: 30s)
-
-### Changed
-
-- BREAKING: `deleteUser()` now requires `confirm: true` parameter to prevent accidents
-- `createSession()` now returns a full session object instead of just the token
-
-### Fixed
-
-- Race condition in concurrent webhook processing
-- Memory leak when connection pool is exhausted
-
-### Deprecated
-
-- `legacy_auth_endpoint` will be removed in v3.0. Use `/auth/v2` instead.
-```
-
-Sources: Google developer documentation style guide (free), Diátaxis framework (diataxis.fr — free), Write the Docs community (writethedocs.org — free), Stripe documentation (excellent example), Tailwind CSS docs (excellent example)
+---
+watermark: ORIRO
+name: technical-writing
+provider: ORIRO.ai
+copyright: Copyright (c) 2026 ORIRO.ai
+description: >
+
+
+
+
+
+
+
+
+
+
+  Technical writing — documentation, READMEs, API docs, tutorials, and communicating technical concepts clearly.
+
+  Sources: Google Search Central, GDPR text, AWS security documentation, Stripe API docs.
+---
+
+# Technical Writing
+
+## The fundamentals
+
+### Reader first
+
+Who is reading this? Developer integrating your API? Beginner learning a concept? Ops team deploying your app?
+Write at the reader's level. Don't explain what a variable is to senior engineers. Do explain your unusual naming conventions.
+
+**Docs debt is real.** Out-of-date docs are often worse than no docs — they mislead readers with confidence.
+
+## README structure (for projects)
+
+````markdown
+# Project Name
+
+One sentence: what this is and why it exists.
+
+## Quick start (under 60 seconds to running example)
+
+```bash
+npm install my-package
+```
+````
+
+```ts
+import { MyPackage } from "my-package";
+const result = MyPackage.doThing({ input: "example" });
+console.log(result); // { success: true, output: 'processed' }
+```
+
+## Installation (detailed)
+
+## Configuration
+
+## Usage (common use cases with examples)
+
+## API Reference
+
+## Contributing
+
+## License
+
+````
+
+**Rule:** If it takes more than 5 minutes to go from README to working example, the README has failed.
+
+## API documentation (OpenAPI + prose)
+
+### Document the why, not just the what
+```markdown
+## Authentication
+
+All API requests require a Bearer token in the Authorization header.
+
+**Why:** We use short-lived JWTs (15 min expiry) rather than API keys
+to minimize exposure if a token is leaked in logs or network traffic.
+Long-lived tokens should use the refresh flow instead of storing the
+access token.
+
+### Getting a token
+POST /auth/token with your credentials...
+````
+
+### Annotate code examples
+
+```ts
+// Create a PaymentIntent with automatic_payment_methods enabled.
+// This lets Stripe show the optimal payment options for the customer's
+// location and saves card for future use if setup_future_usage is set.
+const paymentIntent = await stripe.paymentIntents.create({
+  amount: 2000, // Amount in smallest currency unit (cents for USD)
+  currency: "usd",
+  automatic_payment_methods: {
+    enabled: true, // Required for Stripe's adaptive UI
+  },
+});
+
+// Return only the client_secret — NEVER return the full paymentIntent object
+// as it contains server-side only fields.
+return { clientSecret: paymentIntent.client_secret };
+```
+
+## Tutorial writing (the Diátaxis framework)
+
+Four types of documentation (different purposes, should not be mixed):
+**Tutorials:** Learning-oriented. Step-by-step for beginners. "Build your first app in 15 minutes."
+**How-to guides:** Task-oriented. Practical steps for specific goals. "How to set up SSO with Okta."
+**Explanations:** Understanding-oriented. Conceptual depth. "How our caching works."
+**Reference:** Information-oriented. Complete, accurate, dry. API reference, config options.
+
+Mixing these creates docs that are bad at all of them.
+
+## Writing style for technical docs
+
+**Present tense:** "The function returns" not "The function will return."
+**Active voice:** "Call the API" not "The API should be called."
+**Imperative mood for instructions:** "Run the command" not "You should run the command."
+**Concrete:** Show code. Examples are worth more than explanations.
+**Short paragraphs:** Max 3-4 sentences. One idea per paragraph.
+**Scannable:** Headers, lists, code blocks. Nobody reads technical docs linearly.
+
+## Changelog writing
+
+```markdown
+## [2.1.0] - 2024-03-15
+
+### Added
+
+- Streaming support for long-running operations
+- New `timeout` option for all API methods (default: 30s)
+
+### Changed
+
+- BREAKING: `deleteUser()` now requires `confirm: true` parameter to prevent accidents
+- `createSession()` now returns a full session object instead of just the token
+
+### Fixed
+
+- Race condition in concurrent webhook processing
+- Memory leak when connection pool is exhausted
+
+### Deprecated
+
+- `legacy_auth_endpoint` will be removed in v3.0. Use `/auth/v2` instead.
+```
+
+Sources: Google developer documentation style guide (free), Diátaxis framework (diataxis.fr — free), Write the Docs community (writethedocs.org — free), Stripe documentation (excellent example), Tailwind CSS docs (excellent example)

package/skills/technical/ux-research-tools/LICENSE

@@ -1,21 +1,21 @@
-MIT License
-
-Copyright (c) 2026 ORIRO.ai
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.
+MIT License
+
+Copyright (c) 2026 ORIRO.ai
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/skills/technical/ux-research-tools/SKILL.md

@@ -1,54 +1,54 @@
----
-watermark: ORIRO
-name: ux-research-tools
-provider: ORIRO.ai
-copyright: Copyright (c) 2026 ORIRO.ai
-description: >
-  UX research methods and tools — user interviews, usability testing, surveys,
-  analytics, heatmaps, and synthesis frameworks. Sources: Nielsen Norman Group
-  (free articles), IDEO Design Thinking (free), UX Collective (free).
----
-
-# UX Research Methods and Tools
-
-## Research methods by phase
-
-### Discovery (understand the problem)
-
-**User interviews:** 5-8 participants per persona. Semi-structured. "Tell me about..." not "Do you...?"
-**Contextual inquiry:** Observe users in their environment. What people do vs what they say.
-**Diary studies:** Participants log experiences over days/weeks. For infrequent behaviors.
-**Surveys:** Large scale. Quant data. Low depth. SurveyMonkey, Google Forms, Typeform.
-
-### Evaluation (test solutions)
-
-**Usability testing:** 5 users find 80% of usability problems (Nielsen's rule).
-Moderated: Facilitator observes. Rich data. Expensive.
-Unmoderated: Remote, automated. Larger sample. Less rich.
-**A/B testing:** Live traffic split. Statistical significance needed. Minimum 100-1000 users per variant.
-**First-click testing:** Test navigation by asking users to click where they'd go first.
-
-### Free/low-cost tools
-
-**Maze:** Unmoderated testing. Prototype testing. Free tier.
-**Hotjar:** Heatmaps + session recordings. Free tier.
-**Google Analytics 4:** Free. Behavioral analytics.
-**Lookback.io:** Moderated testing. More expensive.
-**Miro:** Online whiteboard. Research synthesis. Free tier.
-
-## Research synthesis
-
-**Affinity mapping:** Group observations into themes. Post-it notes on wall (or digital).
-**Jobs to be Done (JTBD):** "When [situation], I want to [motivation], so I can [outcome]."
-**How Might We (HMW):** Convert problems into design opportunities.
-**User journey map:** Stages × actions × thoughts × emotions × pain points.
-
-## Key metrics
-
-**SUS (System Usability Scale):** 10 questions. Score 0-100. >70 = acceptable. >85 = excellent.
-**CSAT:** Customer Satisfaction. Single question 1-5 or 1-10.
-**NPS (Net Promoter Score):** "How likely to recommend?" 0-10. Promoters minus Detractors.
-**Task completion rate:** % users completing defined task. Target >78% for critical tasks.
-
-Sources: Nielsen Norman Group (nngroup.com — free articles), UX Collective (free),
-IDEO Design Thinking methodology (free), Google UX Design Certificate (Coursera)
+---
+watermark: ORIRO
+name: ux-research-tools
+provider: ORIRO.ai
+copyright: Copyright (c) 2026 ORIRO.ai
+description: >
+  UX research methods and tools — user interviews, usability testing, surveys,
+  analytics, heatmaps, and synthesis frameworks. Sources: Nielsen Norman Group
+  (free articles), IDEO Design Thinking (free), UX Collective (free).
+---
+
+# UX Research Methods and Tools
+
+## Research methods by phase
+
+### Discovery (understand the problem)
+
+**User interviews:** 5-8 participants per persona. Semi-structured. "Tell me about..." not "Do you...?"
+**Contextual inquiry:** Observe users in their environment. What people do vs what they say.
+**Diary studies:** Participants log experiences over days/weeks. For infrequent behaviors.
+**Surveys:** Large scale. Quant data. Low depth. SurveyMonkey, Google Forms, Typeform.
+
+### Evaluation (test solutions)
+
+**Usability testing:** 5 users find 80% of usability problems (Nielsen's rule).
+Moderated: Facilitator observes. Rich data. Expensive.
+Unmoderated: Remote, automated. Larger sample. Less rich.
+**A/B testing:** Live traffic split. Statistical significance needed. Minimum 100-1000 users per variant.
+**First-click testing:** Test navigation by asking users to click where they'd go first.
+
+### Free/low-cost tools
+
+**Maze:** Unmoderated testing. Prototype testing. Free tier.
+**Hotjar:** Heatmaps + session recordings. Free tier.
+**Google Analytics 4:** Free. Behavioral analytics.
+**Lookback.io:** Moderated testing. More expensive.
+**Miro:** Online whiteboard. Research synthesis. Free tier.
+
+## Research synthesis
+
+**Affinity mapping:** Group observations into themes. Post-it notes on wall (or digital).
+**Jobs to be Done (JTBD):** "When [situation], I want to [motivation], so I can [outcome]."
+**How Might We (HMW):** Convert problems into design opportunities.
+**User journey map:** Stages × actions × thoughts × emotions × pain points.
+
+## Key metrics
+
+**SUS (System Usability Scale):** 10 questions. Score 0-100. >70 = acceptable. >85 = excellent.
+**CSAT:** Customer Satisfaction. Single question 1-5 or 1-10.
+**NPS (Net Promoter Score):** "How likely to recommend?" 0-10. Promoters minus Detractors.
+**Task completion rate:** % users completing defined task. Target >78% for critical tasks.
+
+Sources: Nielsen Norman Group (nngroup.com — free articles), UX Collective (free),
+IDEO Design Thinking methodology (free), Google UX Design Certificate (Coursera)

package/skills/theme-factory/LICENSE

@@ -1,21 +1,21 @@
-MIT License
-
-Copyright (c) 2026 ORIRO.ai
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.
+MIT License
+
+Copyright (c) 2026 ORIRO.ai
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/skills/theme-factory/SKILL.md

@@ -1,65 +1,65 @@
----
-provider: ORIRO.ai
-copyright: Copyright (c) 2026 ORIRO.ai
-watermark: ORIRO
-disable-model-invocation: true
-name: theme-factory
-description: Toolkit for styling artifacts with a theme. These artifacts can be slides, docs, reportings, HTML landing pages, etc. There are 10 pre-set themes with colors/fonts that you can apply to any artifact that has been creating, or can generate a new theme on-the-fly.
----
-
-# Theme Factory Skill
-
-This skill provides a curated collection of professional font and color themes themes, each with carefully selected color palettes and font pairings. Once a theme is chosen, it can be applied to any artifact.
-
-## Purpose
-
-To apply consistent, professional styling to presentation slide decks, use this skill. Each theme includes:
-
-- A cohesive color palette with hex codes
-- Complementary font pairings for headers and body text
-- A distinct visual identity suitable for different contexts and audiences
-
-## Usage Instructions
-
-To apply styling to a slide deck or other artifact:
-
-1. **Show the theme showcase**: Display the `theme-showcase.pdf` file to allow users to see all available themes visually. Do not make any modifications to it; simply show the file for viewing.
-2. **Ask for their choice**: Ask which theme to apply to the deck
-3. **Wait for selection**: Get explicit confirmation about the chosen theme
-4. **Apply the theme**: Once a theme has been chosen, apply the selected theme's colors and fonts to the deck/artifact
-
-## Themes Available
-
-The following 10 themes are available, each showcased in `theme-showcase.pdf`:
-
-1. **Ocean Depths** - Professional and calming maritime theme
-2. **Sunset Boulevard** - Warm and vibrant sunset colors
-3. **Forest Canopy** - Natural and grounded earth tones
-4. **Modern Minimalist** - Clean and contemporary grayscale
-5. **Golden Hour** - Rich and warm autumnal palette
-6. **Arctic Frost** - Cool and crisp winter-inspired theme
-7. **Desert Rose** - Soft and sophisticated dusty tones
-8. **Tech Innovation** - Bold and modern tech aesthetic
-9. **Botanical Garden** - Fresh and organic garden colors
-10. **Midnight Galaxy** - Dramatic and cosmic deep tones
-
-## Theme Details
-
-Each theme is defined in the `themes/` directory with complete specifications including:
-
-- Cohesive color palette with hex codes
-- Complementary font pairings for headers and body text
-- Distinct visual identity suitable for different contexts and audiences
-
-## Application Process
-
-After a preferred theme is selected:
-
-1. Read the corresponding theme file from the `themes/` directory
-2. Apply the specified colors and fonts consistently throughout the deck
-3. Ensure proper contrast and readability
-4. Maintain the theme's visual identity across all slides
-
-## Create your Own Theme
-
-To handle cases where none of the existing themes work for an artifact, create a custom theme. Based on provided inputs, generate a new theme similar to the ones above. Give the theme a similar name describing what the font/color combinations represent. Use any basic description provided to choose appropriate colors/fonts. After generating the theme, show it for review and verification. Following that, apply the theme as described above.
+---
+provider: ORIRO.ai
+copyright: Copyright (c) 2026 ORIRO.ai
+watermark: ORIRO
+disable-model-invocation: true
+name: theme-factory
+description: Toolkit for styling artifacts with a theme. These artifacts can be slides, docs, reportings, HTML landing pages, etc. There are 10 pre-set themes with colors/fonts that you can apply to any artifact that has been creating, or can generate a new theme on-the-fly.
+---
+
+# Theme Factory Skill
+
+This skill provides a curated collection of professional font and color themes themes, each with carefully selected color palettes and font pairings. Once a theme is chosen, it can be applied to any artifact.
+
+## Purpose
+
+To apply consistent, professional styling to presentation slide decks, use this skill. Each theme includes:
+
+- A cohesive color palette with hex codes
+- Complementary font pairings for headers and body text
+- A distinct visual identity suitable for different contexts and audiences
+
+## Usage Instructions
+
+To apply styling to a slide deck or other artifact:
+
+1. **Show the theme showcase**: Display the `theme-showcase.pdf` file to allow users to see all available themes visually. Do not make any modifications to it; simply show the file for viewing.
+2. **Ask for their choice**: Ask which theme to apply to the deck
+3. **Wait for selection**: Get explicit confirmation about the chosen theme
+4. **Apply the theme**: Once a theme has been chosen, apply the selected theme's colors and fonts to the deck/artifact
+
+## Themes Available
+
+The following 10 themes are available, each showcased in `theme-showcase.pdf`:
+
+1. **Ocean Depths** - Professional and calming maritime theme
+2. **Sunset Boulevard** - Warm and vibrant sunset colors
+3. **Forest Canopy** - Natural and grounded earth tones
+4. **Modern Minimalist** - Clean and contemporary grayscale
+5. **Golden Hour** - Rich and warm autumnal palette
+6. **Arctic Frost** - Cool and crisp winter-inspired theme
+7. **Desert Rose** - Soft and sophisticated dusty tones
+8. **Tech Innovation** - Bold and modern tech aesthetic
+9. **Botanical Garden** - Fresh and organic garden colors
+10. **Midnight Galaxy** - Dramatic and cosmic deep tones
+
+## Theme Details
+
+Each theme is defined in the `themes/` directory with complete specifications including:
+
+- Cohesive color palette with hex codes
+- Complementary font pairings for headers and body text
+- Distinct visual identity suitable for different contexts and audiences
+
+## Application Process
+
+After a preferred theme is selected:
+
+1. Read the corresponding theme file from the `themes/` directory
+2. Apply the specified colors and fonts consistently throughout the deck
+3. Ensure proper contrast and readability
+4. Maintain the theme's visual identity across all slides
+
+## Create your Own Theme
+
+To handle cases where none of the existing themes work for an artifact, create a custom theme. Based on provided inputs, generate a new theme similar to the ones above. Give the theme a similar name describing what the font/color combinations represent. Use any basic description provided to choose appropriate colors/fonts. After generating the theme, show it for review and verification. Following that, apply the theme as described above.