@cubis/foundry 0.3.71 → 0.3.72

package/workflows/powers/changelog-generator/SKILL.md

@@ -1,104 +1,167 @@
 ---
 name: changelog-generator
-description: Automatically creates user-facing changelogs from git commits by analyzing commit history, categorizing changes, and transforming technical commits into clear, customer-friendly release notes. Turns hours of manual changelog writing into minutes of automated generation.
+description: Generate changelogs from conventional commits, semantic versioning, release notes, and automated version management workflows.
+license: Apache-2.0
+metadata:
+  author: cubis-foundry
+  version: "3.0"
+compatibility: Claude Code, Codex, GitHub Copilot, Gemini CLI
 ---
 
 # Changelog Generator
 
-This skill transforms technical git commits into polished, user-friendly changelogs that your customers and users will actually understand and appreciate.
+## Purpose
 
-## When to Use This Skill
+Guide changelog generation, release notes writing, and version management using conventional commits and semantic versioning.
 
-- Preparing release notes for a new version
-- Creating weekly or monthly product update summaries
-- Documenting changes for customers
-- Writing changelog entries for app store submissions
-- Generating update notifications
-- Creating internal release documentation
-- Maintaining a public changelog/product updates page
+## When to Use
 
-## What This Skill Does
+- Generating a CHANGELOG.md from commit history
+- Writing release notes for a new version
+- Setting up automated versioning workflows
+- Reviewing commit message format and conventions
+- Planning a release with breaking changes
 
-1. **Scans Git History**: Analyzes commits from a specific time period or between versions
-2. **Categorizes Changes**: Groups commits into logical categories (features, improvements, bug fixes, breaking changes, security)
-3. **Translates Technical → User-Friendly**: Converts developer commits into customer language
-4. **Formats Professionally**: Creates clean, structured changelog entries
-5. **Filters Noise**: Excludes internal commits (refactoring, tests, etc.)
-6. **Follows Best Practices**: Applies changelog guidelines and your brand voice
+## Instructions
 
-## How to Use
+### Step 1 — Follow Conventional Commits
 
-### Basic Usage
+**Format**: `<type>(<scope>): <description>`
 
-From your project repository:
+| Type       | SemVer Bump | When                                   |
+| ---------- | ----------- | -------------------------------------- |
+| `feat`     | Minor       | New feature for users                  |
+| `fix`      | Patch       | Bug fix for users                      |
+| `docs`     | None        | Documentation only                     |
+| `style`    | None        | Formatting, no logic change            |
+| `refactor` | None        | Code restructuring, no behavior change |
+| `perf`     | Patch       | Performance improvement                |
+| `test`     | None        | Adding or fixing tests                 |
+| `build`    | None        | Build system or dependencies           |
+| `ci`       | None        | CI/CD configuration                    |
+| `chore`    | None        | Maintenance tasks                      |
 
-```
-Create a changelog from commits since last release
-```
+**Breaking changes**: Add `!` after type or `BREAKING CHANGE:` in footer:
 
 ```
-Generate changelog for all commits from the past week
-```
+feat!: remove deprecated API endpoints
 
-```
-Create release notes for version 2.5.0
+BREAKING CHANGE: /v1/users endpoint has been removed. Use /v2/users instead.
 ```
 
-### With Specific Date Range
+### Step 2 — Generate Changelog
 
-```
-Create a changelog for all commits between March 1 and March 15
-```
+**Changelog format** (Keep a Changelog style):
 
-### With Custom Guidelines
+```markdown
+# Changelog
 
+## [2.1.0] - 2025-01-15
+
+### Added
+
+- User profile image upload (#234)
+- Dark mode support for dashboard (#256)
+
+### Fixed
+
+- Login timeout on slow connections (#245)
+- Currency formatting for Japanese Yen (#249)
+
+### Changed
+
+- Increased password minimum length to 12 characters (#251)
+
+## [2.0.0] - 2024-12-01
+
+### Breaking Changes
+
+- Removed deprecated /v1/users endpoint — use /v2/users (#230)
+
+### Added
+
+- New user roles system with RBAC (#220)
 ```
-Create a changelog for commits since v2.4.0, using my changelog 
-guidelines from CHANGELOG_STYLE.md
-```
 
-## Example
+**Mapping rules**:
+
+- `feat` → **Added**
+- `fix` → **Fixed**
+- `feat!` / `BREAKING CHANGE` → **Breaking Changes**
+- `perf` → **Performance**
+- `refactor` with user-visible changes → **Changed**
+- `deprecate` → **Deprecated**
+- `remove` → **Removed**
+
+### Step 3 — Semantic Versioning
+
+**MAJOR.MINOR.PATCH** (e.g., 2.1.3):
+
+- **MAJOR**: Breaking changes (API removal, incompatible changes)
+- **MINOR**: New features (backward-compatible additions)
+- **PATCH**: Bug fixes (backward-compatible fixes)
+
+**Pre-release versions**: `2.1.0-beta.1`, `2.1.0-rc.1`
 
-**User**: "Create a changelog for commits from the past 7 days"
+**Rules**:
+
+- Version 0.x.y is for initial development (anything may change)
+- First stable release is 1.0.0
+- Never change a released version — create a new one
+
+### Step 4 — Write Release Notes
+
+**Release notes structure**:
+
+1. **Headline** — one sentence summarizing the release theme
+2. **Highlights** — 2-3 most important changes with context
+3. **Full changelog** — categorized list of all changes
+4. **Migration guide** — for breaking changes, step-by-step upgrade instructions
+5. **Contributors** — acknowledge contributors
+
+**Good highlights**:
 
-**Output**:
 ```markdown
-# Updates - Week of March 10, 2024
+### Highlights
 
-## ✨ New Features
+**Dark Mode** — The dashboard now supports dark mode, automatically
+matching your system preference. Toggle manually in Settings → Appearance.
 
-- **Team Workspaces**: Create separate workspaces for different 
-  projects. Invite team members and keep everything organized.
+**Faster Search** — Search results now load 3x faster thanks to a new
+indexing strategy. No changes needed on your end.
+```
 
-- **Keyboard Shortcuts**: Press ? to see all available shortcuts. 
-  Navigate faster without touching your mouse.
+### Step 5 — Automate the Workflow
 
-## 🔧 Improvements
+**CI pipeline**:
 
-- **Faster Sync**: Files now sync 2x faster across devices
-- **Better Search**: Search now includes file contents, not just titles
+1. Lint commit messages on PR (reject non-conventional)
+2. On merge to main: determine version bump from commits
+3. Generate changelog entry
+4. Bump version in package.json / pyproject.toml
+5. Create git tag
+6. Create GitHub Release with release notes
+7. Publish to package registry
 
-## 🐛 Fixes
+## Output Format
 
-- Fixed issue where large images wouldn't upload
-- Resolved timezone confusion in scheduled posts
-- Corrected notification badge count
 ```
+## Version
+[version number and bump reasoning]
 
-**Inspired by:** Manik Aggarwal's use case from Lenny's Newsletter
+## Changelog Entry
+[formatted changelog in Keep a Changelog style]
+
+## Release Notes
+[user-facing summary with highlights and migration guide]
+```
 
-## Tips
+## Examples
 
-- Run from your git repository root
-- Specify date ranges for focused changelogs
-- Use your CHANGELOG_STYLE.md for consistent formatting
-- Review and adjust the generated changelog before publishing
-- Save output directly to CHANGELOG.md
+**User**: "Generate a changelog for our latest release"
 
-## Related Use Cases
+**Response approach**: Scan commits since last tag. Categorize by type. Generate changelog in Keep a Changelog format. Determine version bump (major/minor/patch). Write release highlights.
 
-- Creating GitHub release notes
-- Writing app store update descriptions
-- Generating email updates for users
-- Creating social media announcement posts
+**User**: "We have breaking API changes — how do we release this?"
 
+**Response approach**: Bump major version. Write migration guide with before/after examples. Add deprecation notices in the previous minor release if possible. Generate changelog with Breaking Changes section first.

package/workflows/powers/ci-cd-pipelines/POWER.md

@@ -0,0 +1,156 @@
+````markdown
+---
+inclusion: manual
+name: ci-cd-pipelines
+description: "Use when designing, reviewing, or debugging CI/CD pipelines across GitHub Actions, GitLab CI, and similar platforms. Covers pipeline architecture, job sequencing, caching, artifact management, environment promotion, security hardening, and flaky-pipeline triage."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "1.0"
+compatibility: Claude Code, Codex, GitHub Copilot
+---
+
+# CI/CD Pipelines
+
+## Purpose
+
+Use when designing, reviewing, or debugging CI/CD pipelines across GitHub Actions, GitLab CI, and similar platforms. Covers pipeline architecture, job sequencing, caching, artifact management, environment promotion, security hardening, and flaky-pipeline triage.
+
+## When to Use
+
+- Working on ci cd pipelines related tasks
+
+## Instructions
+
+1. **Understand the deployment target** — cloud, container, serverless, or bare-metal. Pipeline shape follows deployment topology.
+2. **Map the job graph** — identify which steps are independent (parallelizable) and which have hard ordering dependencies. Minimize serial chains.
+3. **Isolate build from test from deploy** — each stage must be independently retriable without re-running earlier stages.
+4. **Cache aggressively but invalidate correctly** — hash lockfiles for dependency caches, hash source for build caches. Never cache test state.
+5. **Gate deployments** — staging must pass before production. Use environment protection rules, required reviewers, or manual approvals for high-risk targets.
+
+### Pipeline architecture
+
+### Job graph design
+
+- Prefer fan-out/fan-in: lint + typecheck + unit tests run in parallel, integration tests depend on all three.
+- Keep each job under 10 minutes. Split large test suites across matrix jobs.
+- Use `needs` / `dependencies` to declare explicit ordering — avoid relying on implicit stage ordering.
+
+### Caching strategy
+
+- **Dependency cache**: key on lockfile hash (`package-lock.json`, `yarn.lock`, `Gemfile.lock`, `go.sum`). Restore with fallback keys.
+- **Build cache**: key on source hash or commit SHA. Use for compiled outputs, Docker layer cache, and generated code.
+- **Never cache**: test databases, integration state, secrets, or environment-specific config.
+
+### Artifact management
+
+- Upload build artifacts between jobs — do not rebuild in deploy jobs.
+- Set retention periods appropriate to the artifact type (7 days for PR artifacts, 90 days for release artifacts).
+- Sign release artifacts when publishing to registries.
+
+### Matrix builds
+
+- Use matrix strategy for cross-platform or cross-version testing.
+- Pin exact versions in matrix — do not use `latest` or floating tags.
+- Use `fail-fast: false` for comprehensive test matrices, `fail-fast: true` for blocking checks.
+
+### GitHub Actions specifics
+
+### Workflow structure
+
+```yaml
+name: CI
+on:
+  push:
+    branches: [main]
+  pull_request:
+    branches: [main]
+
+concurrency:
+  group: ${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: true
+
+permissions:
+  contents: read
+
+jobs:
+  lint:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-node@v4
+        with:
+          node-version-file: ".node-version"
+          cache: "npm"
+      - run: npm ci
+      - run: npm run lint
+
+  test:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-node@v4
+        with:
+          node-version-file: ".node-version"
+          cache: "npm"
+      - run: npm ci
+      - run: npm test
+```
+
+### Security hardening
+
+- Always set top-level `permissions` to minimum required. Never use `permissions: write-all`.
+- Pin actions to full SHA, not tags: `uses: actions/checkout@<sha>`.
+- Use `concurrency` groups to cancel redundant runs.
+- Never echo secrets. Use `GITHUB_TOKEN` scoping per job.
+- Audit third-party actions — prefer official `actions/` namespace or verified publishers.
+
+### Reusable workflows
+
+- Extract shared logic into reusable workflows (`workflow_call` trigger).
+- Pass inputs and secrets explicitly — do not inherit.
+- Version reusable workflows with tags or SHA references.
+
+### Environment promotion
+
+- **PR** → lint + test + preview deploy (auto)
+- **main** → staging deploy (auto) → smoke tests (auto)
+- **Release tag** → production deploy (gated) → canary → full rollout
+- Never deploy directly to production from a PR merge without a staging gate.
+
+### Flaky pipeline triage
+
+1. Identify flaky jobs by checking re-run success rate.
+2. Common causes: timing-dependent tests, shared mutable state, network calls to external services, race conditions in parallel jobs.
+3. Fix flakiness at the source — do not add retries as a permanent fix.
+4. Quarantine persistently flaky tests into a separate non-blocking job.
+
+### Constraints
+
+- Avoid monolithic pipeline files over 300 lines — split into reusable workflows and composite actions.
+- Avoid running full E2E suites on every PR — reserve for merge queue or staging.
+- Avoid storing secrets in workflow files — use repository or organization secrets.
+- Avoid `continue-on-error: true` on critical checks — failures must block.
+- Avoid manual version bumps in CI — use semantic-release or similar automation.
+- Avoid running CI steps as root when not required.
+
+## Output Format
+
+Provide implementation guidance, code examples, and configuration as appropriate to the task.
+
+## References
+
+| File                                        | Purpose                                                                                             |
+| ------------------------------------------- | --------------------------------------------------------------------------------------------------- |
+| `references/github-actions-patterns.md`     | Reusable workflow patterns, composite actions, matrix strategies, and environment protection rules. |
+| `references/pipeline-security-checklist.md` | Supply chain hardening, SLSA compliance, secret rotation, and audit trail requirements.             |
+
+## 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 ci cd pipelines best practices in this project"
+- "Review my ci cd pipelines implementation for issues"
+````

package/workflows/powers/ci-cd-pipelines/SKILL.md

@@ -0,0 +1,153 @@
+---
+name: ci-cd-pipelines
+description: "Use when designing, reviewing, or debugging CI/CD pipelines across GitHub Actions, GitLab CI, and similar platforms. Covers pipeline architecture, job sequencing, caching, artifact management, environment promotion, security hardening, and flaky-pipeline triage."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "1.0"
+compatibility: Claude Code, Codex, GitHub Copilot
+---
+
+# CI/CD Pipelines
+
+## Purpose
+
+Use when designing, reviewing, or debugging CI/CD pipelines across GitHub Actions, GitLab CI, and similar platforms. Covers pipeline architecture, job sequencing, caching, artifact management, environment promotion, security hardening, and flaky-pipeline triage.
+
+## When to Use
+
+- Working on ci cd pipelines related tasks
+
+## Instructions
+
+1. **Understand the deployment target** — cloud, container, serverless, or bare-metal. Pipeline shape follows deployment topology.
+2. **Map the job graph** — identify which steps are independent (parallelizable) and which have hard ordering dependencies. Minimize serial chains.
+3. **Isolate build from test from deploy** — each stage must be independently retriable without re-running earlier stages.
+4. **Cache aggressively but invalidate correctly** — hash lockfiles for dependency caches, hash source for build caches. Never cache test state.
+5. **Gate deployments** — staging must pass before production. Use environment protection rules, required reviewers, or manual approvals for high-risk targets.
+
+### Pipeline architecture
+
+### Job graph design
+
+- Prefer fan-out/fan-in: lint + typecheck + unit tests run in parallel, integration tests depend on all three.
+- Keep each job under 10 minutes. Split large test suites across matrix jobs.
+- Use `needs` / `dependencies` to declare explicit ordering — avoid relying on implicit stage ordering.
+
+### Caching strategy
+
+- **Dependency cache**: key on lockfile hash (`package-lock.json`, `yarn.lock`, `Gemfile.lock`, `go.sum`). Restore with fallback keys.
+- **Build cache**: key on source hash or commit SHA. Use for compiled outputs, Docker layer cache, and generated code.
+- **Never cache**: test databases, integration state, secrets, or environment-specific config.
+
+### Artifact management
+
+- Upload build artifacts between jobs — do not rebuild in deploy jobs.
+- Set retention periods appropriate to the artifact type (7 days for PR artifacts, 90 days for release artifacts).
+- Sign release artifacts when publishing to registries.
+
+### Matrix builds
+
+- Use matrix strategy for cross-platform or cross-version testing.
+- Pin exact versions in matrix — do not use `latest` or floating tags.
+- Use `fail-fast: false` for comprehensive test matrices, `fail-fast: true` for blocking checks.
+
+### GitHub Actions specifics
+
+### Workflow structure
+
+```yaml
+name: CI
+on:
+  push:
+    branches: [main]
+  pull_request:
+    branches: [main]
+
+concurrency:
+  group: ${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: true
+
+permissions:
+  contents: read
+
+jobs:
+  lint:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-node@v4
+        with:
+          node-version-file: ".node-version"
+          cache: "npm"
+      - run: npm ci
+      - run: npm run lint
+
+  test:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-node@v4
+        with:
+          node-version-file: ".node-version"
+          cache: "npm"
+      - run: npm ci
+      - run: npm test
+```
+
+### Security hardening
+
+- Always set top-level `permissions` to minimum required. Never use `permissions: write-all`.
+- Pin actions to full SHA, not tags: `uses: actions/checkout@<sha>`.
+- Use `concurrency` groups to cancel redundant runs.
+- Never echo secrets. Use `GITHUB_TOKEN` scoping per job.
+- Audit third-party actions — prefer official `actions/` namespace or verified publishers.
+
+### Reusable workflows
+
+- Extract shared logic into reusable workflows (`workflow_call` trigger).
+- Pass inputs and secrets explicitly — do not inherit.
+- Version reusable workflows with tags or SHA references.
+
+### Environment promotion
+
+- **PR** → lint + test + preview deploy (auto)
+- **main** → staging deploy (auto) → smoke tests (auto)
+- **Release tag** → production deploy (gated) → canary → full rollout
+- Never deploy directly to production from a PR merge without a staging gate.
+
+### Flaky pipeline triage
+
+1. Identify flaky jobs by checking re-run success rate.
+2. Common causes: timing-dependent tests, shared mutable state, network calls to external services, race conditions in parallel jobs.
+3. Fix flakiness at the source — do not add retries as a permanent fix.
+4. Quarantine persistently flaky tests into a separate non-blocking job.
+
+### Constraints
+
+- Avoid monolithic pipeline files over 300 lines — split into reusable workflows and composite actions.
+- Avoid running full E2E suites on every PR — reserve for merge queue or staging.
+- Avoid storing secrets in workflow files — use repository or organization secrets.
+- Avoid `continue-on-error: true` on critical checks — failures must block.
+- Avoid manual version bumps in CI — use semantic-release or similar automation.
+- Avoid running CI steps as root when not required.
+
+## Output Format
+
+Provide implementation guidance, code examples, and configuration as appropriate to the task.
+
+## References
+
+| File                                        | Purpose                                                                                             |
+| ------------------------------------------- | --------------------------------------------------------------------------------------------------- |
+| `references/github-actions-patterns.md`     | Reusable workflow patterns, composite actions, matrix strategies, and environment protection rules. |
+| `references/pipeline-security-checklist.md` | Supply chain hardening, SLSA compliance, secret rotation, and audit trail requirements.             |
+
+## 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 ci cd pipelines best practices in this project"
+- "Review my ci cd pipelines implementation for issues"