ci: add workflow to auto-add issues to project board

[tac0turtle]

Description

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Performance improvement
• Refactoring

Related Issues

Fixes #(issue)

Checklist

• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published

Testing

Additional Notes

[gemini-code-assist]

Note

Gemini is unable to generate a summary for this pull request due to the file types involved not being currently supported.

[claude]

Claude finished @tac0turtle's task —— View job

---

Code Review Completed ✅

Reviewing PR #133: "ci: add workflow to auto-add issues to project board"

Review Checklist:

• Read and analyze workflow files
• Check security considerations
• Evaluate best practices and code quality
• Check for potential bugs or issues
• Assess performance considerations
• Provide comprehensive feedback

---

Summary

This PR adds a GitHub Actions workflow to automatically add new issues to a project board and sets default field values. The implementation looks solid overall with a few minor considerations.

Code Quality & Best Practices ✅

Positive aspects:

• Clean, readable workflow structure
• Proper use of environment variables for configuration
• Good separation of concerns with individual steps
• Uses official GitHub Actions (actions/add-to-project@v1.0.2)
• Appropriate trigger (only on issues.opened)

Minor suggestions:

• Consider adding comments to explain the hardcoded IDs in the environment section
• The workflow could benefit from error handling (though GitHub Actions provides basic retry logic)

Security Assessment ✅

Secure practices:

• Uses a dedicated PAT (ADD_TO_PROJECT_PAT) instead of GITHUB_TOKEN - this is correct for project operations
• Token is properly referenced via secrets, not hardcoded
• Minimal permissions scope - only triggers on issue creation
• No user input is directly executed in shell commands

No security concerns identified.

Potential Issues & Bugs 🔍

Low-risk considerations:

1. Hardcoded IDs: The workflow relies on hardcoded project/field/option IDs:

   PROJECT_ID: PVT_kwDOBy5rXM4ALaHM
   STATUS_FIELD_ID: PVTSSF_lADOBy5rXM4ALaHMzgHRhFU

   These IDs are brittle - if the project structure changes, the workflow will fail. Consider documenting what these represent.

2. No fallback handling: If steps.add.outputs.itemId is empty or the first step fails, subsequent steps will fail silently. The workflow could benefit from conditional execution.

3. Dependency on external action: Uses actions/add-to-project@v1.0.2 - ensure this version is maintained and consider pinning to a commit SHA for security.

Performance Considerations ✅

• Lightweight workflow with minimal resource usage
• Runs only on issue creation (appropriate trigger)
• Uses standard GitHub CLI commands (efficient)
• No unnecessary dependencies or complex operations

Additional Changes Review

The modification to .github/workflows/lint.yml adds a specific nightly toolchain version:

+ with:
+   toolchain: nightly-2026-02-21

This is a good practice for reproducible builds and should prevent issues with nightly toolchain changes.

Test Coverage 📝

Missing: No tests for the workflow itself. Consider:

• Testing the workflow with a test repository
• Documenting the expected behavior
• Adding workflow status badges if desired

Recommendations

1. Documentation: Add comments explaining what the hardcoded IDs represent
2. Error handling: Consider adding conditional steps or failure notifications
3. Monitoring: Consider adding a step to report workflow success/failure
4. Version pinning: Consider pinning actions/add-to-project to a commit SHA

Approval Status ✅

The workflow implementation is solid and ready for merge. The security practices are sound, and the functionality aligns with the stated purpose. The hardcoded IDs are a known limitation of the GitHub Projects API and are acceptable for this use case.

---

[randygrok]

looks good, lets try it!