feat(ci): add AI coding automation workflows with GitHub integration

[kla-bemindlabs]

Summary

• Add AI-powered issue handling workflow (auto-triage, labeling, AI commands)
• Add automated PR code review with coverage and security analysis
• Add bidirectional sync between local backlog and GitHub Projects
• Add documentation sync workflow for wiki, API docs, and changelog
• Include sprint planning document for AI automation epic (46 story points)

Changes

New Workflows

Workflow	Purpose
ai-issue-handler.yml	Auto-triage issues, respond to /ai-* commands
ai-pr-review.yml	Automated code review, coverage, security scans
ai-project-sync.yml	Sync local backlog ↔ GitHub Projects
ai-docs-sync.yml	Auto-generate wiki, API docs, changelog

Sprint Planning

• Created .scrum/planning/sprint-1-ai-automation-planning.md
• Updated backlog with 12 AI automation items (46 story points)

Test plan

• Verify workflows pass syntax validation
• Test issue triage by creating a test issue
• Test PR review on this PR
• Manually trigger project sync workflow
• Manually trigger docs sync workflow

🤖 Generated with Claude Code

In general, to fix this problem in GitHub Actions you must avoid inserting untrusted expressions directly into the script text passed to run:. Instead, assign untrusted values to environment variables via ${{ ... }} and then reference them using the shell’s native variable syntax ($VAR), or via process.env / the appropriate API inside another language. This prevents the untrusted content from being parsed as part of the shell script itself.

For this specific workflow, the problematic usage is in the Analyze and create fix step (lines 161–172). The step currently does:

run: |
  echo "AI analysis would happen here"
  echo "Issue: ${{ github.event.issue.title }}"
  echo "Body: ${{ github.event.issue.body }}"

We should move github.event.issue.title and github.event.issue.body into environment variables using the expression syntax, then reference them in the shell with $ISSUE_TITLE and $ISSUE_BODY. For example:

- name: Analyze and create fix
  id: fix
  env:
    ISSUE_TITLE: ${{ github.event.issue.title }}
    ISSUE_BODY: ${{ github.event.issue.body }}
  run: |
    echo "AI analysis would happen here"
    echo "Issue: $ISSUE_TITLE"
    echo "Body: $ISSUE_BODY"
    echo "fix_applied=false" >> $GITHUB_OUTPUT

This preserves existing functionality (printing the same values) while eliminating the code-injection vector flagged by CodeQL. No new imports or external dependencies are required; the change is limited to editing the Analyze and create fix step in .github/workflows/ai-issue-handler.yml.

---

In general, to fix this class of issue in GitHub Actions, you must not embed user-controlled expressions directly into run: or script: blocks. Instead, assign the expression to an environment variable using workflow expression syntax, and then read that variable using the native syntax of the shell (e.g., $BODY in bash) or from process.env in JavaScript. This prevents user data from being interpreted as part of the script itself.

For this specific workflow, the problematic use is in the Analyze and create fix step, where the untrusted issue body is interpolated inline:

- name: Analyze and create fix
  id: fix
  run: |
    echo "AI analysis would happen here"
    echo "Issue: ${{ github.event.issue.title }}"
    echo "Body: ${{ github.event.issue.body }}"

We should add an env: section to that step to pass both the issue title and body as environment variables, and then update the shell script to echo $ISSUE_TITLE and $ISSUE_BODY using bash syntax. This removes all ${{ ... }} expansions from the shell code while preserving current behavior (still only echoing the values). Concretely, edit .github/workflows/ai-issue-handler.yml around lines 161–166 to:

• Add:

  env:
    ISSUE_TITLE: ${{ github.event.issue.title }}
    ISSUE_BODY: ${{ github.event.issue.body }}

• Change:

  echo "Issue: ${{ github.event.issue.title }}"
  echo "Body: ${{ github.event.issue.body }}"

  to:

  echo "Issue: $ISSUE_TITLE"
  echo "Body: $ISSUE_BODY"

No new imports or external libraries are needed; this is purely a YAML/workflow change. All other steps remain unchanged, and functionality is preserved.

---