@cubis/foundry 0.3.67 → 0.3.68

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/frontend-design/references/ux-writing.md

@@ -0,0 +1,74 @@
+# UX Writing Reference
+
+## Principles
+
+1. **Clarity over cleverness** — users scan, they don't read. Say what you mean.
+2. **Every word earns its place** — if removing a word doesn't change the meaning, remove it.
+3. **Active voice** — "Save your changes" not "Changes will be saved."
+4. **Speak like a human** — not a lawyer, not a robot, not a marketing deck.
+5. **Consistent voice** — choose a tone and maintain it across all touchpoints.
+
+## Button Labels
+
+| Bad        | Better                        | Why                            |
+| ---------- | ----------------------------- | ------------------------------ |
+| Submit     | Save changes                  | Tells the user what happens    |
+| OK         | Got it                        | More conversational            |
+| Cancel     | Never mind                    | Friendlier (context-dependent) |
+| Click here | View pricing                  | Says what clicking does        |
+| Yes / No   | Delete project / Keep project | Action-specific, no ambiguity  |
+
+For destructive actions, name the consequence: "Delete account" not just "Delete."
+
+## Error Messages
+
+Structure: **What happened** + **Why** + **What to do next**
+
+| Bad            | Better                                                                  |
+| -------------- | ----------------------------------------------------------------------- |
+| Error 500      | Something went wrong on our end. Try again in a moment.                 |
+| Invalid input  | Email address must include @ and a domain (e.g., you@example.com).      |
+| Request failed | Couldn't save your changes — check your connection and try again.       |
+| Unauthorized   | You don't have access to this page. Contact your admin for permissions. |
+
+Rules:
+
+- Never blame the user ("You entered an invalid…")
+- Never show raw error codes as the primary message
+- Always provide a next step or recovery action
+- Use a conversational tone, not a system log
+
+## Empty States
+
+Empty states should teach, not apologize:
+
+| Context              | Bad                   | Better                                                                      |
+| -------------------- | --------------------- | --------------------------------------------------------------------------- |
+| No search results    | No results found.     | No results for "xyz." Try a broader search or check the spelling.           |
+| Empty inbox          | You have no messages. | All caught up! New messages will appear here.                               |
+| First-time dashboard | No data available.    | Welcome! Connect a data source to start seeing insights here. [Connect now] |
+| Empty task list      | No tasks.             | Ready to get started? Add your first task. [Add task]                       |
+
+## Confirmation & Success
+
+- Success messages: brief and specific. "Project saved" > "Your project has been successfully saved."
+- Undo confirmation: "Message archived. [Undo]" (include the action + undo)
+- Multi-step completion: summarize what was accomplished. "Account created. We sent a verification email to you@example.com."
+
+## Tooltips & Help Text
+
+- Keep under 150 characters
+- Explain what something does, not what it is
+- Use field help text for complex inputs (below the field, subtle gray)
+- Tooltips for icons and abbreviated labels only — not for paragraphs
+
+## Microcopy Checklist
+
+- [ ] All form labels are visible (not placeholder-only)
+- [ ] Error messages explain the problem and offer recovery
+- [ ] Empty states guide toward first action
+- [ ] Buttons describe their action (no generic "Submit" / "OK")
+- [ ] Loading states communicate progress or set expectations
+- [ ] Destructive actions name the consequence
+- [ ] Success confirmations are brief and specific
+- [ ] No unexplained jargon or technical codes shown to users

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/game-development/SKILL.md

@@ -1,165 +1,83 @@
 ---
 name: game-development
-description: Game development orchestrator. Routes to platform-specific skills based on project needs.
+description: "Use when implementing game mechanics, game loops, physics, AI, collision detection, or performance optimization for web, mobile, PC, or VR/AR games."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "1.0"
+compatibility: Claude Code, Codex, GitHub Copilot
 ---
 # Game Development
 
-> **Orchestrator skill** that provides core principles and routes to specialized sub-skills.
+## Purpose
 
----
-
-## When to Use This Skill
-
-You are working on a game development project. This skill teaches the PRINCIPLES of game development and directs you to the right sub-skill based on context.
-
----
-
-## Sub-Skill Routing
-
-### Platform Selection
-
-| If the game targets... | Use Sub-Skill |
-|------------------------|---------------|
-| Web browsers (HTML5, WebGL) | `game-development/web-games` |
-| Mobile (iOS, Android) | `game-development/mobile-games` |
-| PC (Steam, Desktop) | `game-development/pc-games` |
-| VR/AR headsets | `game-development/vr-ar` |
-
-### Dimension Selection
-
-| If the game is... | Use Sub-Skill |
-|-------------------|---------------|
-| 2D (sprites, tilemaps) | `game-development/2d-games` |
-| 3D (meshes, shaders) | `game-development/3d-games` |
-
-### Specialty Areas
-
-| If you need... | Use Sub-Skill |
-|----------------|---------------|
-| GDD, balancing, player psychology | `game-development/game-design` |
-| Multiplayer, networking | `game-development/multiplayer` |
-| Visual style, asset pipeline, animation | `game-development/game-art` |
-| Sound design, music, adaptive audio | `game-development/game-audio` |
-
----
-
-## Core Principles (All Platforms)
-
-### 1. The Game Loop
-
-Every game, regardless of platform, follows this pattern:
-
-```
-INPUT  → Read player actions
-UPDATE → Process game logic (fixed timestep)
-RENDER → Draw the frame (interpolated)
-```
+Use when implementing game mechanics, game loops, physics, AI, collision detection, or performance optimization for web, mobile, PC, or VR/AR games.
 
-**Fixed Timestep Rule:**
-- Physics/logic: Fixed rate (e.g., 50Hz)
-- Rendering: As fast as possible
-- Interpolate between states for smooth visuals
+## When to Use
 
----
-
-### 2. Pattern Selection Matrix
-
-| Pattern | Use When | Example |
-|---------|----------|---------|
-| **State Machine** | 3-5 discrete states | Player: Idle→Walk→Jump |
-| **Object Pooling** | Frequent spawn/destroy | Bullets, particles |
-| **Observer/Events** | Cross-system communication | Health→UI updates |
-| **ECS** | Thousands of similar entities | RTS units, particles |
-| **Command** | Undo, replay, networking | Input recording |
-| **Behavior Tree** | Complex AI decisions | Enemy AI |
-
-**Decision Rule:** Start with State Machine. Add ECS only when performance demands.
-
----
-
-### 3. Input Abstraction
-
-Abstract input into ACTIONS, not raw keys:
-
-```
-"jump"  → Space, Gamepad A, Touch tap
-"move"  → WASD, Left stick, Virtual joystick
-```
+- Implementing core game loops (input, update, render) for any platform.
+- Choosing game architecture patterns (ECS, state machine, object pooling).
+- Implementing collision detection, physics, or spatial partitioning.
+- Designing game AI (FSM, behavior trees, utility AI, GOAP).
+- Optimizing game performance to hit 60 FPS budgets.
+- Platform-specific game delivery (web, mobile, desktop, VR/AR).
 
-**Why:** Enables multi-platform, rebindable controls.
+## Instructions
 
----
+1. Determine target platform and rendering approach.
+2. Implement the core game loop with fixed timestep for physics and variable timestep for rendering.
+3. Choose architecture patterns based on entity count and complexity.
+4. Implement game systems in priority order: input, physics/collision, game logic, rendering, audio.
+5. Profile early and continuously against the performance budget.
 
-### 4. Performance Budget (60 FPS = 16.67ms)
+### Baseline standards
 
-| System | Budget |
-|--------|--------|
-| Input | 1ms |
-| Physics | 3ms |
-| AI | 2ms |
-| Game Logic | 4ms |
-| Rendering | 5ms |
-| Buffer | 1.67ms |
+- Performance budget: 60 FPS = 16.67ms per frame (input 1ms, physics 3ms, game logic 4ms, render 6ms, audio 1ms, overhead 1.67ms).
+- Use object pooling for frequently created/destroyed entities.
+- Separate game logic from rendering for testability.
+- Use spatial partitioning for collision detection at scale.
+- Implement deterministic physics with fixed timestep.
 
-**Optimization Priority:**
-1. Algorithm (O(n²) → O(n log n))
-2. Batching (reduce draw calls)
-3. Pooling (avoid GC spikes)
-4. LOD (detail by distance)
-5. Culling (skip invisible)
+### Pattern selection
 
----
+| Pattern         | When to Use                                     |
+| --------------- | ----------------------------------------------- |
+| State Machine   | Character states, UI flow, game phases          |
+| ECS             | Large entity counts, data-driven composition    |
+| Object Pooling  | Bullets, particles, frequently spawned entities |
+| Command Pattern | Input handling, replay, undo                    |
+| Observer        | Events, achievements, UI updates                |
 
-### 5. AI Selection by Complexity
+### AI selection by complexity
 
-| AI Type | Complexity | Use When |
-|---------|------------|----------|
-| **FSM** | Simple | 3-5 states, predictable behavior |
-| **Behavior Tree** | Medium | Modular, designer-friendly |
-| **GOAP** | High | Emergent, planning-based |
-| **Utility AI** | High | Scoring-based decisions |
+| Complexity | Approach                                   |
+| ---------- | ------------------------------------------ |
+| Simple     | Finite State Machine (FSM)                 |
+| Medium     | Behavior Tree                              |
+| Complex    | GOAP or Utility AI                         |
+| Adaptive   | Machine learning (rare in real-time games) |
 
----
+### Constraints
 
-### 6. Collision Strategy
+- Never allocate memory in the hot path (game loop).
+- Never use floating point equality for physics comparisons.
+- Never couple game logic directly to frame rate.
+- Always handle edge cases in collision detection (tunneling, resting contact).
 
-| Type | Best For |
-|------|----------|
-| **AABB** | Rectangles, fast checks |
-| **Circle** | Round objects, cheap |
-| **Spatial Hash** | Many similar-sized objects |
-| **Quadtree** | Large worlds, varying sizes |
+## Output Format
 
----
+Provide implementation guidance, code examples, architecture diagrams, and performance budgets as appropriate.
 
-## Anti-Patterns (Universal)
+## References
 
-| Don't | Do |
-|-------|-----|
-| Update everything every frame | Use events, dirty flags |
-| Create objects in hot loops | Object pooling |
-| Cache nothing | Cache references |
-| Optimize without profiling | Profile first |
-| Mix input with logic | Abstract input layer |
+No reference files for this skill right now.
 
----
+## Scripts
 
-## Routing Examples
+No helper scripts are required for this skill right now.
 
-### Example 1: "I want to make a browser-based 2D platformer"
-→ Start with `game-development/web-games` for framework selection
-→ Then `game-development/2d-games` for sprite/tilemap patterns
-→ Reference `game-development/game-design` for level design
-
-### Example 2: "Mobile puzzle game for iOS and Android"
-→ Start with `game-development/mobile-games` for touch input and stores
-→ Use `game-development/game-design` for puzzle balancing
-
-### Example 3: "Multiplayer VR shooter"
-→ `game-development/vr-ar` for comfort and immersion
-→ `game-development/3d-games` for rendering
-→ `game-development/multiplayer` for networking
-
----
+## Examples
 
-> **Remember:** Great games come from iteration, not perfection. Prototype fast, then polish.
+- "Help me implement a game loop with fixed timestep physics"
+- "Choose the right collision detection strategy for my 2D platformer"
+- "Design an entity component system for my RTS game"

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/geo-fundamentals/SKILL.md

@@ -1,154 +1,92 @@
 ---
 name: geo-fundamentals
-description: Generative Engine Optimization for AI search engines (ChatGPT, Claude, Perplexity).
+description: "Use when optimizing content for AI search engines (ChatGPT, Claude, Perplexity) using Generative Engine Optimization techniques and citation-worthy content patterns."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "1.0"
+compatibility: Claude Code, Codex, GitHub Copilot
 ---
 # GEO Fundamentals
 
-> Optimization for AI-powered search engines.
+## Purpose
 
----
-
-## 1. What is GEO?
-
-**GEO** = Generative Engine Optimization
-
-| Goal | Platform |
-|------|----------|
-| Be cited in AI responses | ChatGPT, Claude, Perplexity, Gemini |
-
-### SEO vs GEO
-
-| Aspect | SEO | GEO |
-|--------|-----|-----|
-| Goal | #1 ranking | AI citations |
-| Platform | Google | AI engines |
-| Metrics | Rankings, CTR | Citation rate |
-| Focus | Keywords | Entities, data |
-
----
+Use when optimizing content for AI search engines (ChatGPT, Claude, Perplexity) using Generative Engine Optimization techniques and citation-worthy content patterns.
 
-## 2. AI Engine Landscape
+## When to Use
 
-| Engine | Citation Style | Opportunity |
-|--------|----------------|-------------|
-| **Perplexity** | Numbered [1][2] | Highest citation rate |
-| **ChatGPT** | Inline/footnotes | Custom GPTs |
-| **Claude** | Contextual | Long-form content |
-| **Gemini** | Sources section | SEO crossover |
+- Optimizing content to be cited by AI search engines and LLM-powered tools.
+- Understanding the differences between traditional SEO and Generative Engine Optimization.
+- Creating content that performs well in RAG retrieval pipelines.
+- Configuring AI crawler access and structured data for LLM consumption.
+- Designing content strategies that work across both traditional and AI-powered search.
 
----
-
-## 3. RAG Retrieval Factors
-
-How AI engines select content to cite:
-
-| Factor | Weight |
-|--------|--------|
-| Semantic relevance | ~40% |
-| Keyword match | ~20% |
-| Authority signals | ~15% |
-| Freshness | ~10% |
-| Source diversity | ~15% |
+## Instructions
 
----
+1. Understand the AI search landscape — how Perplexity, ChatGPT, and Claude cite sources differently.
+2. Optimize for RAG retrieval factors — semantic relevance (~40%), keyword match (~20%), authority (~15%), freshness (~10%), diversity (~15%).
+3. Create citation-worthy content — original statistics, expert quotes, clear definitions, step-by-step guides, comparison tables.
+4. Implement technical GEO — schema markup, author credentials, AI crawler access, FAQ sections.
+5. Measure and iterate — track AI citation frequency and adapt content strategy.
 
-## 4. Content That Gets Cited
+### SEO vs GEO comparison
 
-| Element | Why It Works |
-|---------|--------------|
-| **Original statistics** | Unique, citable data |
-| **Expert quotes** | Authority transfer |
-| **Clear definitions** | Easy to extract |
-| **Step-by-step guides** | Actionable value |
-| **Comparison tables** | Structured info |
-| **FAQ sections** | Direct answers |
+| Aspect  | Traditional SEO            | Generative Engine Optimization      |
+| ------- | -------------------------- | ----------------------------------- |
+| Target  | Search engine results page | AI-generated answers                |
+| Goal    | Click-through from SERP    | Citation in AI response             |
+| Content | Keyword-optimized pages    | Citation-worthy, structured content |
+| Links   | Backlink building          | Authority signals for RAG           |
+| Schema  | For rich snippets          | For LLM understanding               |
 
----
+### Content patterns that get cited
 
-## 5. GEO Content Checklist
+- Original statistics and data points
+- Expert quotes with credentials
+- Clear, concise definitions
+- Step-by-step guides with numbered steps
+- Comparison tables with concrete data
+- Unique frameworks or methodologies
 
-### Content Elements
+### AI crawler user agents
 
-- [ ] Question-based titles
-- [ ] Summary/TL;DR at top
-- [ ] Original data with sources
-- [ ] Expert quotes (name, title)
-- [ ] FAQ section (3-5 Q&A)
-- [ ] Clear definitions
-- [ ] "Last updated" timestamp
-- [ ] Author with credentials
+| Crawler         | Engine             |
+| --------------- | ------------------ |
+| GPTBot          | ChatGPT / OpenAI   |
+| Claude-Web      | Claude / Anthropic |
+| PerplexityBot   | Perplexity         |
+| Google-Extended | Google AI features |
 
-### Technical Elements
+### GEO content checklist
 
-- [ ] Article schema with dates
-- [ ] Person schema for author
-- [ ] FAQPage schema
-- [ ] Fast loading (< 2.5s)
-- [ ] Clean HTML structure
+- Question-based titles and headings
+- Author credentials and expertise signals
+- FAQ sections with structured data
+- Article and FAQPage schema markup
+- Clear, quotable sentences in the first paragraph
+- Data-backed claims with sources
 
----
+### Constraints
 
-## 6. Entity Building
+- Never block AI crawlers unless there's a specific business reason.
+- Never create content solely for AI citation without user value.
+- Always maintain content accuracy — AI engines amplify both good and bad information.
+- Always include proper attribution for data and quotes.
 
-| Action | Purpose |
-|--------|---------|
-| Google Knowledge Panel | Entity recognition |
-| Wikipedia (if notable) | Authority source |
-| Consistent info across web | Entity consolidation |
-| Industry mentions | Authority signals |
+## Output Format
 
----
+Provide GEO audit findings, content optimization recommendations, schema markup, and crawler configuration guidance.
 
-## 7. AI Crawler Access
+## References
 
-### Key AI User-Agents
+No reference files for this skill right now.
 
-| Crawler | Engine |
-|---------|--------|
-| GPTBot | ChatGPT/OpenAI |
-| Claude-Web | Claude |
-| PerplexityBot | Perplexity |
-| Googlebot | Gemini (shared) |
-
-### Access Decision
-
-| Strategy | When |
-|----------|------|
-| Allow all | Want AI citations |
-| Block GPTBot | Don't want OpenAI training |
-| Selective | Allow some, block others |
-
----
-
-## 8. Measurement
-
-| Metric | How to Track |
-|--------|--------------|
-| AI citations | Manual monitoring |
-| "According to [Brand]" mentions | Search in AI |
-| Competitor citations | Compare share |
-| AI-referred traffic | UTM parameters |
-
----
-
-## 9. Anti-Patterns
-
-| ❌ Don't | ✅ Do |
-|----------|-------|
-| Publish without dates | Add timestamps |
-| Vague attributions | Name sources |
-| Skip author info | Show credentials |
-| Thin content | Comprehensive coverage |
-
----
-
-> **Remember:** AI cites content that's clear, authoritative, and easy to extract. Be the best answer.
-
----
+## Scripts
 
-## Script
+No helper scripts are required for this skill right now.
 
-| Script | Purpose | Command |
-|--------|---------|---------|
-| `scripts/geo_checker.py` | GEO audit (AI citation readiness) | `python scripts/geo_checker.py <project_path>` |
+## Examples
 
+- "Optimize our documentation to be cited by AI search engines"
+- "Create a GEO content strategy for our developer blog"
+- "Configure AI crawler access and structured data for our site"

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/git-workflow/SKILL.md

@@ -0,0 +1,131 @@
+---
+name: git-workflow
+description: "Use when establishing or reviewing git branching strategies, PR conventions, commit hygiene, merge policies, monorepo workflows, and release tagging. Covers trunk-based development, GitFlow alternatives, conventional commits, and code review standards."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "1.0"
+compatibility: Claude Code, Codex, GitHub Copilot
+---
+# Git Workflow
+
+## Purpose
+
+Use when establishing or reviewing git branching strategies, PR conventions, commit hygiene, merge policies, monorepo workflows, and release tagging. Covers trunk-based development, GitFlow alternatives, conventional commits, and code review standards.
+
+## When to Use
+
+- Working on git workflow related tasks
+
+## Instructions
+
+1. **Choose a branching model** — trunk-based for high-velocity teams, short-lived feature branches for teams needing review gates.
+2. **Keep branches short-lived** — merge within 1-2 days. Long-lived branches create merge pain and integration risk.
+3. **Write meaningful commits** — each commit should be a logical, reviewable unit. Squash fixup commits before merge.
+4. **Review before merge** — every change to protected branches goes through PR review. No direct pushes.
+5. **Automate what you can** — branch protection, CI gating, auto-merge on approval, changelog generation.
+
+### Branching strategies
+
+### Trunk-based development (recommended)
+
+- All developers commit to `main` (directly or via short-lived branches).
+- Feature branches live for hours to 1-2 days, never weeks.
+- Use feature flags for incomplete work that must be merged.
+- Release from `main` via tags or release branches cut at the moment of release.
+- Best for: teams with strong CI, continuous deployment capability.
+
+### GitHub Flow
+
+- `main` is always deployable.
+- Create feature branches from `main`, open PR, review, merge back.
+- Deploy from `main` after merge.
+- Simpler than GitFlow. No develop branch, no release branches unless needed.
+- Best for: SaaS products with single production environment.
+
+### Release branches (when needed)
+
+- Cut `release/X.Y` from `main` when preparing a release.
+- Cherry-pick critical fixes to release branch. Never merge `main` into release.
+- Tag releases from the release branch.
+- Delete release branch after final patch version.
+
+### Commit conventions
+
+### Conventional Commits
+
+```
+<type>(<scope>): <description>
+
+[optional body]
+
+[optional footer]
+```
+
+Types: `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore`.
+
+- `feat`: new feature visible to users → triggers minor version bump.
+- `fix`: bug fix → triggers patch version bump.
+- `feat!` or `BREAKING CHANGE:` footer → triggers major version bump.
+
+### Commit message rules
+
+- Subject line: imperative mood, under 72 characters, no period.
+- Body: explain WHY, not WHAT (the diff shows what changed).
+- One logical change per commit. Do not mix refactoring with behavior changes.
+
+### Pull request standards
+
+- Title follows conventional commit format.
+- Description includes: what changed, why it changed, how to test.
+- Link related issues with `Closes #123` or `Fixes #456`.
+- Keep PRs under 400 lines of meaningful change. Split larger work into stacked PRs.
+- Request review from domain owners, not random team members.
+
+### Merge strategy
+
+| Strategy     | When to use                                                         |
+| ------------ | ------------------------------------------------------------------- |
+| Squash merge | Default for feature PRs — clean single-commit history on main.      |
+| Merge commit | When preserving individual commits matters (multi-author, long PR). |
+| Rebase merge | When linear history is required and branch is small/clean.          |
+
+- Configure repository default in GitHub settings.
+- Delete branches after merge — do not accumulate stale branches.
+
+### Protected branch rules
+
+- [ ] Require PR reviews (minimum 1 reviewer)
+- [ ] Require status checks to pass (CI, lint, test)
+- [ ] Require branches to be up to date before merge
+- [ ] Disable force push to `main` and release branches
+- [ ] Require signed commits (optional but recommended for regulated environments)
+- [ ] Enable merge queue for high-traffic repositories
+
+### Constraints
+
+- Avoid long-lived feature branches (>3 days) — merge pain grows exponentially.
+- Avoid merge commits from `main` into feature branches — rebase instead.
+- Avoid commit messages like "fix", "wip", "stuff" — they provide no value in history.
+- Avoid bypassing CI checks with `--no-verify` — fix the issue instead.
+- Avoid cherry-picking without tracking — document which commits were cherry-picked and why.
+- Avoid force-pushing to shared branches — coordinate with collaborators first.
+
+## Output Format
+
+Provide implementation guidance, code examples, and configuration as appropriate to the task.
+
+## References
+
+| File                                | Purpose                                                                                             |
+| ----------------------------------- | --------------------------------------------------------------------------------------------------- |
+| `references/pr-review-checklist.md` | Code review process, reviewer responsibilities, approval criteria, and common review anti-patterns. |
+
+## Scripts
+
+No helper scripts are required for this skill right now. Keep execution in `SKILL.md` and `references/` unless repeated automation becomes necessary.
+
+## Examples
+
+- "Help me with git workflow best practices in this project"
+- "Review my git workflow implementation for issues"