release: v0.1.1

[eumaninho54]

🚀 Summary

Release v0.1.1 — ships the release pipeline, branch protection workflows, and several CI/skill fixes.

Type of change

• feat — new feature
• fix — bug fix
• docs — documentation
• refactor — code restructuring
• chore — maintenance
• ci — CI/CD
• release — new version

📝 Changes

• feat(ci): add release pipeline and branch protection workflows
• fix(ci): auto-close PRs targeting main from non-release branches
• fix(ci): exit 0 after closing invalid PR to avoid stale failed check
• fix(skills/pr): enforce use of repo PR template in body
• docs: add instructions for context-triggered skills

🧪 Testing

• Existing tests pass
• New tests added (if applicable)
• Tested manually

🎟️ Related Tickets

• Related Issue #
• Closes #

[eumaninho54]

DEPLOY-RELEASE

[llamapreview]

Auto Pull Request Review from LlamaPReview

Recommendation: 🔴 Request Changes - This PR introduces essential release automation and branch protection for the AIWorkers ecosystem, but contains critical issues that must be addressed before merging. The P0 issue with GitHub token permissions would break the entire release pipeline under standard branch protection settings, and the P1 issues could lead to incorrect approval counting and duplicate releases.

1. Overview

1.1 Core Changes

• Primary purpose: Implements automated release pipeline with branch protection, CI fixes, and documentation improvements
• Key components modified:
  • CI/CD workflows (deploy.yml, enforce-release-branch.yml)
  • Local setup script (setup.sh)
  • Skill documentation (pr/SKILL.md)
  • AI usage instructions (CLAUDE.md)
• Cross-component impacts:
  • Release process now requires specific branch naming (release/vX.Y.Z)
  • PR creation must follow repository template structure
  • Local development environment setup more robust
• Business value alignment:
  • Enables consistent, repeatable releases with minimal human error
  • Protects main branch from accidental merges
  • Ensures uniform PR descriptions through template enforcement
  • Fixes local development environment issues

1.2 Technical Architecture

• System design modifications:
  • Introduces comment-triggered release pipeline (DEPLOY-RELEASE)
  • Implements automated branch protection via workflow
  • Centralizes version management through package.json
• Component interaction changes:
  • GitHub Actions now handles version bumping, tagging, and merging
  • PR workflows interact with GitHub API for metadata and comments
  • Local setup script more carefully manages symlinks
• Integration points impact:
  • Requires proper GitHub token permissions
  • Assumes package.json exists at root
  • Depends on specific branch naming convention
• Dependency changes:
  • Adds implicit dependency on jq for JSON processing
  • Requires GitHub CLI (gh) in workflow environment

2. Critical Findings

2.1 Must Fix (P0🔴)

Issue: Deploy workflow will fail under branch protection

• Analysis Confidence: High
• Impact: Entire release pipeline becomes non-functional in standard protected-branch setups, preventing all releases
• Resolution: Replace secrets.GITHUB_TOKEN with a dedicated PAT stored as secrets.RELEASE_PAT that has bypass permissions, or clearly document the branch protection constraint

2.2 Should Fix (P1🟡)

Issue: Approval counting ignores latest review state

• Analysis Confidence: High
• Impact: Could allow releases with outdated approvals, compromising release quality
• Suggested Solution:

  APPROVALS=$(gh api repos/${{ github.repository }}/pulls/${{ env.PR_NUMBER }}/reviews \
    --jq '[group_by(.user.login)[] | max_by(.submitted_at) | select(.state == "APPROVED")] | length')

Issue: No check for existing tag before creation

• Analysis Confidence: High
• Impact: Workflow will fail if tag already exists, potentially mid-release
• Suggested Solution:

  - name: Check tag existence
    run: |
      if git rev-parse "${{ env.TAG }}" >/dev/null 2>&1; then
        echo "Tag ${{ env.TAG }} already exists locally."
        exit 1
      fi
      if gh api repos/${{ github.repository }}/git/ref/tags/${{ env.TAG }} >/dev/null 2>&1; then
        echo "Tag ${{ env.TAG }} already exists remotely."
        exit 1
      fi

Issue: Assumes package.json always exists

• Analysis Confidence: High
• Impact: Version bump step will fail if file missing
• Suggested Solution:

  - name: Validate package.json
    run: |
      if [ ! -f package.json ]; then
        echo "package.json not found; aborting version bump."
        exit 1
      fi

2.3 Consider (P2🟢)

Area: Workflow concurrency control

• Analysis Confidence: High
• Improvement Opportunity: Prevent race conditions from multiple DEPLOY-RELEASE comments

  concurrency:
    group: release-pipeline-${{ github.event.issue.number }}
    cancel-in-progress: false

Area: setup.sh safety improvement

• Analysis Confidence: High
• Improvement Opportunity: Add path prefix check before rm -rf

  [[ "$target" == "$AW_COMMANDS"/* ]] || exit 1

Area: PR template rule specificity

• Analysis Confidence: Medium
• Improvement Opportunity: Specify exact template file location in pr/SKILL.md

2.4 Summary of Action Items

1. Critical (P0): Fix GitHub token permissions issue before merging
2. High Priority (P1): Implement all three P1 fixes for approval counting, tag checking, and package.json validation
3. Recommended (P2): Add concurrency control and improve setup.sh safety
4. Documentation: Consider adding branch naming convention to CONTRIBUTING.md

3. Technical Analysis

3.1 Code Logic Analysis

📁 .github/workflows/deploy.yml - Release Pipeline

• Submitted PR Code:

    - name: Checkout PR branch
      uses: actions/checkout@v4
      with:
        ref: ${{ env.PR_BRANCH }}
        fetch-depth: 0
        # NOTE: If branch protection requires signed commits, replace with:
        #   token: ${{ secrets.RELEASE_PAT }}

• Analysis:
  • Current logic uses default GITHUB_TOKEN which lacks permissions to push to protected branches
  • This will cause silent failures when branch protection is enabled
  • The comment indicates awareness but doesn't enforce the solution
  • Cross-component impact affects entire release process
• LlamaPReview Suggested Improvements:

    - name: Checkout PR branch
      uses: actions/checkout@v4
      with:
        ref: ${{ env.PR_BRANCH }}
        fetch-depth: 0
        token: ${{ secrets.RELEASE_PAT }}  # Required for protected branches

• Improvement rationale:
  • Technical benefits: Ensures workflow can push to protected branches
  • Business value: Makes release pipeline functional in standard protected branch setups
  • Risk assessment: Low - this is standard practice for release workflows

📁 .github/workflows/deploy.yml - Approval Counting Logic

• Submitted PR Code:

    APPROVALS=$(gh api \
      repos/${{ github.repository }}/pulls/${{ env.PR_NUMBER }}/reviews \
      --jq '[.[] | select(.state == "APPROVED")] | length')

• Analysis:
  • Current logic counts all historical approvals, even if reviewer later requested changes
  • This could allow releases with outdated approvals
  • Doesn't account for most recent review state per reviewer
• LlamaPReview Suggested Improvements:

    APPROVALS=$(gh api repos/${{ github.repository }}/pulls/${{ env.PR_NUMBER }}/reviews \
      --jq '[group_by(.user.login)[] | max_by(.submitted_at) | select(.state == "APPROVED")] | length')

• Improvement rationale:
  • Technical benefits: Accurately reflects current approval state
  • Business value: Prevents releases with stale approvals
  • Risk assessment: Low - more accurate approval counting

📁 scripts/setup.sh - Symlink Creation Logic

• Submitted PR Code:

    target="$AW_COMMANDS/$name"
    [ -d "$target" ] && [ ! -L "$target" ] && rm -rf "$target"
    ln -sfn "$dir" "$target"

• Analysis:
  • Current logic fixes nesting bug by removing real directories before symlinking
  • Uses rm -rf which could be dangerous if target path is unexpected
  • No path validation before removal
• LlamaPReview Suggested Improvements:

    target="$AW_COMMANDS/$name"
    [[ "$target" == "$AW_COMMANDS"/* ]] || exit 1  # Safety check
    [ -d "$target" ] && [ ! -L "$target" ] && rm -rf "$target"
    ln -sfn "$dir" "$target"

• Improvement rationale:
  • Technical benefits: Prevents accidental removal of system directories
  • Business value: Makes script safer for all users
  • Risk assessment: Low - adds safety without changing functionality

📁 src/skills/pr/SKILL.md - PR Template Rule

• Submitted PR Code:

    - **Never invent a PR body.** Always read the template file and use it as the body structure — including all emojis, sections, and checkboxes exactly as they appear

• Analysis:
  • Rule enforces template usage but doesn't specify which template file
  • Could lead to ambiguity about which template to use
  • Missing reference to standard location (.github/PULL_REQUEST_TEMPLATE.md)
• LlamaPReview Suggested Improvements:

    - **Never invent a PR body.** Always read the template from `.github/PULL_REQUEST_TEMPLATE.md` and use its structure exactly — including all emojis, sections, and checkboxes as they appear

• Improvement rationale:
  • Technical benefits: Removes ambiguity about template location
  • Business value: Ensures consistent PR formatting
  • Risk assessment: Low - clarifies existing requirement

3.2 Key Quality Aspects

• System scalability considerations:
  • Release pipeline handles one release at a time (concurrency group recommended)
  • Branch protection workflow scales with PR volume
• Performance bottlenecks:
  • Multiple GH API calls could be optimized with single queries
  • jq processing could be combined where possible
• Testing strategy:
  • Workflows should be tested with:
    • Protected and unprotected branches
    • Various approval scenarios
    • Existing tags
    • Missing package.json
  • Manual testing of setup.sh fixes recommended
• Documentation needs:
  • Branch naming convention should be documented in CONTRIBUTING.md
  • Required GitHub token permissions should be specified
  • Release process should be documented for maintainers

4. Overall Evaluation

• Technical assessment:

  • Well-designed release pipeline with proper security checks
  • Branch protection workflow effectively guards main branch
  • Local setup fix resolves real nesting bug
  • Documentation improvements enhance usability
  • Critical token permission issue must be fixed
  • Several important validation checks missing

• Business impact:

  • Enables consistent, automated releases
  • Protects main branch integrity
  • Improves local development experience
  • Ensures uniform PR descriptions
  • Current issues could prevent successful releases

• Risk evaluation:

  • High: Release pipeline will fail under branch protection (P0)
  • Medium: Approval counting could allow invalid releases (P1)
  • Medium: Tag conflicts could abort releases (P1)
  • Low: package.json assumption could fail (P1)
  • Low: Various minor improvements available (P2)

• Notable positive aspects:

  • Comment-triggered release is user-friendly
  • Comprehensive error handling and user feedback
  • Proper use of GitHub API for metadata
  • Clear separation of concerns in workflows
  • Fixes real bug in setup script
  • Improves AI tool guidance

• Implementation quality:

  • Generally high quality with thoughtful design
  • Good error handling and user communication
  • Follows GitHub Actions best practices
  • Missing some important validation checks
  • One critical permission issue

• Final recommendation: 🔴 Request Changes
  The PR introduces valuable release automation but contains critical issues that must be addressed:

  1. Fix GitHub token permissions (P0)
  2. Implement proper approval counting (P1)
  3. Add tag existence validation (P1)
  4. Validate package.json existence (P1)

  Once these issues are resolved, the PR will be ready for merging and will significantly improve the project's release process and branch protection.

---

Service Update
Thank you for being one of the 4,000+ repositories trusting LlamaPReview. As the AI coding landscape shifts, we are stepping back from the review SaaS model. Free reviews for private repositories will pause on May 1, 2026 00:00:00 UTC (Public open-source repos remain free).

If you've enjoyed our work, we'd be honored if you checked out our new open-source journey at DocMason.