npm - @cleocode/skills - Versions diffs - 2.0.0 - Mend

@cleocode/skills 2.0.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (171) hide show

package/skills/ct-dev-workflow/SKILL.md ADDED Viewed

@@ -0,0 +1,423 @@
+---
+name: ct-dev-workflow
+description: Development workflow orchestration for task-driven development with atomic commits, conventional commit messages, and systematic release processes. Enforces task traceability, branch discipline, smart test scope selection, and GitHub Actions integration. Use when committing code, creating releases, managing branches, or following contribution protocols. Triggers on commit operations, release preparation, or workflow compliance needs.
+version: 3.0.0
+tier: 2
+core: false
+category: specialist
+protocol: contribution
+dependencies: []
+sharedResources:
+  - subagent-protocol-base
+  - task-system-integration
+compatibility:
+  - claude-code
+  - cursor
+  - windsurf
+  - gemini-cli
+license: MIT
+---
+# Development Workflow Context Injection
+**Protocol**: @src/protocols/contribution.md
+**Type**: Context Injection (cleo-subagent)
+**Version**: 3.0.0
+---
+## Purpose
+Context injection for development workflow tasks spawned via cleo-subagent. Provides domain expertise for atomic commits with task traceability, conventional commit messages, and systematic release processes.
+---
+## Core Principle: Task-Driven Development
+> **CRITICAL**: NO code changes or commits without a tracked task.
+Every commit MUST be traceable to a CLEO task. This ensures:
+- Work is planned and tracked
+- Changes are reviewable and reversible
+- Progress is measurable
+- Context is preserved for future agents
+---
+## Immutable Constraints (WORKFLOW)
+| ID | Rule | Enforcement |
+|----|------|-------------|
+| WF-001 | Task required | NO commits without CLEO task reference |
+| WF-002 | Branch discipline | NO commits to main/master |
+| WF-003 | Atomic commits | ONE logical change per commit |
+| WF-004 | Conventional format | `<type>(<scope>): <description>` |
+| WF-005 | Tests before push | Relevant tests MUST pass |
+---
+## Task Tracking Integration
+### Before Any Work
+```bash
+# 1. Verify you have a task
+cleo current
+# 2. If no task, find or create one
+cleo find "relevant query"
+cleo add "Task title" --description "What you're doing" --parent T001
+cleo start T123
+```
+### Commit Message Format
+**MUST** include task reference:
+```
+<type>(<scope>): <description>
+<body explaining why>
+Task: T123
+Co-Authored-By: Claude <noreply@anthropic.com>
+```
+**Example:**
+```
+fix(auth): prevent token expiry race condition
+The refresh token was being invalidated before the new access
+token was validated, causing intermittent auth failures.
+Task: T1456
+Co-Authored-By: Claude <noreply@anthropic.com>
+```
+---
+## Branch & Subagent Awareness
+### Single Branch Reality
+Subagents share the parent session's branch. This means:
+- All work happens on the same branch
+- No parallel feature branches from subagents
+- Commits are sequential, not parallel
+- Worktrees needed for true branch isolation
+### Branch Strategy
+```bash
+# Check current branch
+git branch --show-current
+# Feature work (typical pattern)
+main → feature/T123-description → PR → main
+# Branch naming
+feature/T123-auth-improvements     # Task-prefixed
+fix/T456-token-validation          # Bug fix
+```
+---
+## Gate System (Simplified)
+Not all gates apply to all changes. Follow the decision matrix.
+### G0: Pre-Flight Check
+**Always required.**
+```bash
+# 1. Verify task context
+cleo current
+# MUST have a current task
+# 2. Check branch
+git branch --show-current
+# MUST NOT be main/master
+# 3. Check for uncommitted work
+git status --porcelain
+# Review staged/unstaged changes
+```
+### G1: Classify Change
+| Type | Description | Tests Needed | Version Bump |
+|------|-------------|--------------|--------------|
+| `feat` | New feature | Related tests | MINOR |
+| `fix` | Bug fix | Regression test | PATCH |
+| `docs` | Documentation | None | None |
+| `refactor` | Code restructure | Affected tests | PATCH |
+| `test` | Test additions | The new tests | None |
+| `chore` | Maintenance | None | None |
+| `perf` | Performance | Perf tests | PATCH |
+| `security` | Security fix | Security tests | PATCH |
+### G2: Testing (Smart Scope)
+**NOT always full test suite.** CI runs full tests on push.
+| Change Type | Test Scope | Command |
+|-------------|------------|---------|
+| `feat` | Related module tests | `bats tests/unit/feature.bats` |
+| `fix` | Regression + affected | `bats tests/unit/affected.bats` |
+| `docs` | None (CI validates) | Skip |
+| `refactor` | Affected modules | `bats tests/unit/module*.bats` |
+| `test` | The new tests only | `bats tests/unit/new.bats` |
+| `chore` | Syntax check only | `bash -n scripts/*.sh` |
+**When to run full suite locally:**
+- Before release (version bump)
+- Major refactoring
+- Cross-cutting changes
+- User explicitly requests
+```bash
+# Full suite (when needed)
+./tests/run-all-tests.sh
+# Targeted tests (typical)
+bats tests/unit/specific-feature.bats
+bats tests/integration/workflow.bats
+# Quick syntax check
+bash -n scripts/*.sh lib/*.sh
+```
+### G3: Commit
+```bash
+# 1. Get task info
+task_id=$(cleo current --quiet)
+# 2. Stage changes (be specific for atomic commits)
+git add scripts/specific-file.sh lib/related.sh
+# 3. Create commit with task reference
+git commit -m "$(cat <<'EOF'
+fix(auth): prevent token expiry race condition
+The refresh token was being invalidated before validation.
+Task: T1456
+Co-Authored-By: Claude <noreply@anthropic.com>
+EOF
+)"
+```
+### G4: Push (Triggers CI)
+```bash
+# Push branch (CI runs full tests)
+git push origin HEAD
+# CI will run:
+# - Full test suite
+# - ShellCheck linting
+# - JSON validation
+# - Documentation drift check
+# - Installation test
+```
+### G5: Version Bump (Release Only)
+**Only for releases**, not every commit.
+```bash
+# 1. Preview
+./dev/bump-version.sh --dry-run patch
+# 2. Execute
+./dev/bump-version.sh patch
+# 3. Validate
+./dev/validate-version.sh
+# 4. Reinstall locally
+./install.sh --force
+cleo version
+```
+### G6: Tag & Release
+**GitHub Actions handles release creation.**
+```bash
+# 1. Create annotated tag
+git tag -a v${VERSION} -m "${TYPE}: ${SUMMARY}"
+# 2. Push tag (triggers release workflow)
+git push origin v${VERSION}
+# 3. Push branch
+git push origin HEAD
+# GitHub Actions automatically:
+# - Builds release tarball
+# - Creates GitHub Release
+# - Generates release notes
+# - Uploads artifacts
+```
+---
+## Quick Decision Matrix
+### What Tests to Run?
+| Change | Local Tests | Rely on CI |
+|--------|-------------|------------|
+| Single file fix | Related unit test | Yes |
+| New feature | Feature tests | Yes |
+| Docs only | None | Yes |
+| Schema change | Schema tests | Yes |
+| Cross-cutting refactor | Full suite | Yes |
+| Release prep | Full suite | Yes |
+### Do I Need a Version Bump?
+| Change | Bump | Tag |
+|--------|------|-----|
+| `feat` | minor | Yes |
+| `fix` | patch | Yes |
+| `docs` | No | No |
+| `refactor` | patch | Yes |
+| `test` | No | No |
+| `chore` | No | No |
+| `perf` | patch | Yes |
+| `security` | patch | Yes |
+---
+## Task System Integration
+@skills/_shared/task-system-integration.md
+### CLEO Integration Commands
+```bash
+# Task lifecycle
+cleo current                 # Current task
+cleo start T123              # Start task
+cleo complete T123           # Mark done
+# Find existing work
+cleo find "query"            # Search tasks
+cleo list --status pending   # Pending work
+# Create new work
+cleo add "Title" --parent T001 --description "..."
+# Session management
+cleo session status          # Current session
+cleo session end --note "Completed X, Y, Z"
+```
+---
+## Subagent Protocol
+@skills/_shared/subagent-protocol-base.md
+### Output Requirements
+1. MUST write workflow summary to: `{{OUTPUT_DIR}}/{{DATE}}_{{TOPIC_SLUG}}.md`
+2. MUST append ONE line to: `{{MANIFEST_PATH}}`
+3. MUST return ONLY: "Workflow complete. See MANIFEST.jsonl for summary."
+4. MUST NOT return full commit/release details in response
+---
+## Complete Workflow Examples
+### Example 1: Bug Fix (Typical)
+```bash
+# 1. Verify task
+cleo current
+# Output: T1456 - Fix token validation
+# 2. Make changes
+# ... edit files ...
+# 3. Run relevant test
+bats tests/unit/auth.bats
+# 4. Stage specific files
+git add lib/auth.sh scripts/login.sh
+# 5. Commit with task
+git commit -m "$(cat <<'EOF'
+fix(auth): prevent token expiry race condition
+Task: T1456
+Co-Authored-By: Claude <noreply@anthropic.com>
+EOF
+)"
+# 6. Push (CI handles full tests)
+git push origin HEAD
+# 7. Mark task complete
+cleo complete T1456
+```
+### Example 2: Documentation Only
+```bash
+# 1. Verify task
+cleo current  # T1550 - Update README
+# 2. Make doc changes
+# ... edit docs ...
+# 3. No tests needed (CI validates)
+# 4. Commit
+git add docs/ README.md
+git commit -m "$(cat <<'EOF'
+docs: update installation instructions
+Task: T1550
+Co-Authored-By: Claude <noreply@anthropic.com>
+EOF
+)"
+# 5. Push
+git push origin HEAD
+# 6. Complete
+cleo complete T1550
+```
+---
+## Anti-Patterns
+| Pattern | Problem | Solution |
+|---------|---------|----------|
+| No task reference | Untracked work | Create/find task first |
+| Committing to main | Bypass review | Use feature branches |
+| Running full tests always | Slow iteration | Use smart test scope |
+| Skipping CI | Missing validations | Always push, let CI run |
+| Manual release creation | Inconsistent releases | Use tag, GH Actions |
+| Giant commits | Hard to review/revert | Atomic commits |
+| Vague commit messages | Lost context | Conventional + task ref |
+---
+## Critical Rules Summary
+1. **Always have a task** before making changes
+2. **Always include task reference** in commit message
+3. **Never commit to main/master** directly
+4. **Run relevant tests** locally, not always full suite
+5. **Let CI validate** with full test suite on push
+6. **Use tags for releases** - GitHub Actions handles the rest
+7. **One logical change** per commit (atomic)
+8. **Conventional commit format** with task reference

package/skills/ct-docs-lookup/SKILL.md ADDED Viewed

@@ -0,0 +1,66 @@
+---
+name: ct-docs-lookup
+description: This skill should be used when the user asks "how do I configure [library]", "write code using [framework]", "what are the [library] methods", "show me [framework] examples", or mentions libraries like React, Vue, Next.js, Prisma, Supabase, Express, Tailwind, Drizzle, Svelte. Triggers for library setup, configuration, API references, framework code examples, or version-specific docs ("React 19", "Next.js 15").
+version: 1.0.0
+tier: 3
+core: false
+category: composition
+protocol: null
+dependencies: []
+sharedResources: []
+compatibility:
+  - claude-code
+  - cursor
+  - windsurf
+  - gemini-cli
+license: MIT
+---
+When the user asks about libraries, frameworks, or needs code examples, use Context7 to fetch current documentation instead of relying on training data.
+## When to Use This Skill
+Activate this skill when the user:
+- Asks setup or configuration questions ("How do I configure Next.js middleware?")
+- Requests code involving libraries ("Write a Prisma query for...")
+- Needs API references ("What are the Supabase auth methods?")
+- Mentions specific frameworks (React, Vue, Svelte, Express, Tailwind, etc.)
+## How to Fetch Documentation
+### Step 1: Resolve the Library ID
+Call `resolve-library-id` with:
+- `libraryName`: The library name extracted from the user's question
+- `query`: The user's full question (improves relevance ranking)
+### Step 2: Select the Best Match
+From the resolution results, choose based on:
+- Exact or closest name match to what the user asked for
+- Higher benchmark scores indicate better documentation quality
+- If the user mentioned a version (e.g., "React 19"), prefer version-specific IDs
+### Step 3: Fetch the Documentation
+Call `query-docs` with:
+- `libraryId`: The selected Context7 library ID (e.g., `/vercel/next.js`)
+- `query`: The user's specific question
+### Step 4: Use the Documentation
+Incorporate the fetched documentation into your response:
+- Answer the user's question using current, accurate information
+- Include relevant code examples from the docs
+- Cite the library version when relevant
+## Guidelines
+- **Be specific**: Pass the user's full question as the query for better results
+- **Version awareness**: When users mention versions ("Next.js 15", "React 19"), use version-specific library IDs if available from the resolution step
+- **Prefer official sources**: When multiple matches exist, prefer official/primary packages over community forks

package/skills/ct-docs-review/SKILL.md ADDED Viewed

@@ -0,0 +1,175 @@
+---
+name: ct-docs-review
+description: This skill should be used when the user asks to "review documentation", "check docs style", "review this markdown file", "check style guide compliance", "review PR documentation", or needs documentation reviewed against the CLEO writing style guide. Supports both local file review and GitHub PR review modes with inline comments.
+version: 1.0.0
+tier: 3
+core: false
+category: composition
+protocol: null
+dependencies: []
+sharedResources: []
+compatibility:
+  - claude-code
+  - cursor
+  - windsurf
+  - gemini-cli
+license: MIT
+---
+# Documentation Review Skill
+@skills/_shared/cleo-style-guide.md
+## Review mode detection
+**IMPORTANT: Before starting the review, determine which mode to use:**
+1. **PR review mode**: If the `mcp__github__create_pending_pull_request_review` tool is available, you are reviewing a GitHub PR
+   - Use the pending review workflow to post all issues as one cohesive review
+   - Follow the workflow steps in "PR review mode format" below
+2. **Local review mode**: If the MCP tool is NOT available, output issues in the conversation
+   - Format all issues in a numbered markdown list (as described in "Feedback format" below)
+## Review process
+1. **Detect review mode** - Check if `mcp__github__create_pending_pull_request_review` is available
+2. Read the changes through once to understand intent
+3. Check all issues that violate style guide or significantly impact readability
+4. Only flag issues worth mentioning - if it won't make a material difference to the reader, skip it
+5. **REQUIRED: Number ALL feedback sequentially** - Start from Issue 1 and increment for each issue found
+## Review checklist
+Run through the diff looking for these issues:
+**Tone and voice:**
+- [ ] Formal/corporate language ("utilize" not "use", "offerings", etc.)
+- [ ] "Users" instead of "people" or "companies"
+- [ ] Excessive exclamation points or overly peppy tone
+- [ ] Telling readers something is cool instead of showing them
+**Structure and clarity:**
+- [ ] Important information buried instead of leading
+- [ ] Verbose text that adds little value
+- [ ] Paragraphs without clear purpose
+- [ ] Vague headings that don't convey the point
+- [ ] Instructions explain "why" before telling "what to do"
+- [ ] Tasks described as "easy" or "simple"
+**Links and references:**
+- [ ] Linking the word "here" instead of descriptive text
+- [ ] Links in headings (unless entire heading is a link)
+**Formatting:**
+- [ ] Ampersands as "and" substitute (except proper nouns)
+- [ ] Inconsistent list formatting
+**Code and examples:**
+- [ ] Code examples that don't work or would error
+- [ ] Commands not in execution order
+- [ ] Full-width screenshots instead of scoped UI elements
+- [ ] Excessive or unnecessary images
+**Sentence construction:**
+- [ ] Overuse of pronouns when introducing new terms
+## Quick scan table
+| Pattern                       | Issue                                         |
+| ----------------------------- | --------------------------------------------- |
+| we can do X, our feature      | Should be "CLEO" or "it"                      |
+| click here, read more here    | Need descriptive link text                    |
+| easy, simple, just            | Remove condescending qualifiers               |
+| users                         | Should be "people" or "companies" if possible |
+## Feedback format
+**MANDATORY REQUIREMENT: Every single issue MUST be numbered sequentially starting from Issue 1.**
+This numbered format is NON-NEGOTIABLE. It allows users to efficiently reference specific issues (e.g., "fix issues 1, 3, and 5") and track which feedback has been addressed.
+### Local review mode format
+When outputting issues in the conversation (local mode), use this format:
+```markdown
+## Issues
+**Issue 1: [Brief title]**
+Line X: Succinct description of the issue
+[code or example]
+Suggested fix or succinct explanation
+**Issue 2: [Brief title]**
+Line Y: Description of the issue
+Suggested fix or explanation
+**Issue 3: [Brief title]**
+...
+```
+**Examples:**
+> **Issue 1: Formal tone**
+> Line 15: This could be more conversational. Consider: "You can't..." instead of "You cannot..."
+> **Issue 2: Vague heading**
+> Line 8: The heading could be more specific. Try stating the point directly: "Run migrations before upgrading" vs "Upgrade process"
+### PR review mode format
+When posting to GitHub (PR mode), use the **pending review workflow**:
+**Workflow steps:**
+1. **Start a review**: Use `mcp__github__create_pending_pull_request_review` to begin a pending review
+   - This creates a draft review that won't be visible until submitted
+2. **Get diff information**: Use `mcp__github__get_pull_request_diff` to understand the code changes and line numbers
+   - This helps you determine the correct file paths and line numbers for comments
+3. **Identify ALL issues**: Read through all changes and identify every issue worth mentioning
+   - Collect all issues before posting any comments
+   - Number them sequentially (Issue 1, Issue 2, Issue 3, etc.)
+4. **Add review comments**: Use `mcp__github__add_pull_request_review_comment_to_pending_review` for each issue
+   - **CRITICAL**: Post ALL comments in a SINGLE response using multiple tool calls in parallel
+   - Each comment should reference a specific file path and line number from the diff
+   - Start each comment body with `**Issue N: [Brief title]**`
+   - Include the description and suggested fix
+5. **Submit the review**: Use `mcp__github__submit_pending_pull_request_review` to publish all comments at once
+   - Use event type `"COMMENT"` (NOT "REQUEST_CHANGES") to make it non-blocking
+   - **Do NOT include a body message** - Leave the body empty or omit it entirely
+   - All comments will appear together as one cohesive review
+**Comment format example:**
+```
+**Issue 1: Formal tone**
+This could be more conversational. Consider: "You can't..." instead of "You cannot..."
+```
+**IMPORTANT**:
+- Each issue gets its own review comment attached to the pending review
+- Number ALL comments sequentially (Issue 1, Issue 2, Issue 3, etc.)
+- Always start the comment body with `**Issue N: [Brief title]**`
+- **MUST add all comments in parallel in a single response** - Do NOT add them one after another in separate responses
+- Do NOT output a summary message to the conversation - only post GitHub review comments
+- When submitting the review, do NOT include a body parameter (or leave it empty) to avoid cluttering the PR with summary text
+- The review will appear as a single review with multiple comments when submitted
+## Final check
+1. Remove any issues from your assessment that won't make a material difference to the reader if addressed. Only flag issues worth the author's time to fix.
+2. **Verify all issues are numbered sequentially** starting from Issue 1 with no gaps in numbering.
+3. Confirm the format exactly matches: `**Issue N: [Brief title]**` where N is the issue number.
+4. **In PR mode**: Verify each issue was posted as a separate GitHub comment (not output to conversation).