Add project frontmatter field for automatic project board tracking

[Copilot]

Add project frontmatter field to agentic workflows ✅

This PR adds a new top-level project field to agentic workflows that provides automatic GitHub Projects board tracking, similar to campaign orchestrators.

Implementation Complete ✅

Core Implementation:

• ✅ Added ProjectConfig type to hold project URL and configuration settings
• ✅ Added Project field to FrontmatterConfig struct
• ✅ Implemented applyProjectSafeOutputs() to automatically configure safe-outputs when project field is present
• ✅ Integrated into compiler pipeline via processToolsAndMarkdown()
• ✅ Added scope field to define which repositories/organizations the workflow can operate on

Schema & Validation:

• ✅ Added JSON schema validation for project field with two formats (string URL or object)
• ✅ Validates GitHub Project URL format
• ✅ Supports configuration options: scope, max-updates, max-status-updates, github-token, do-not-downgrade-done-items
• ✅ Scope field accepts owner/repo for specific repositories and org:name for organizations

Auto-Configuration:
When project is configured, automatically adds:

• ✅ update-project safe-output (default max: 100)
• ✅ create-project-status-update safe-output (default max: 1)
• ✅ Preserves existing configurations if already defined

Documentation:

• ✅ Complete guide at docs/src/content/docs/examples/project-tracking.md
• ✅ Updated frontmatter reference documentation
• ✅ Example workflows for issue triage and PR tracking
• ✅ Troubleshooting guide and best practices
• ✅ Fixed invalid campaign documentation links

Testing:

• ✅ Unit tests for ProjectConfig parsing including scope field
• ✅ Integration tests for safe-outputs auto-configuration
• ✅ Manual compilation test verified correct safe_outputs job generation
• ✅ All tests pass

Usage Examples

Simple format:

project: https://github.com/orgs/github/projects/123

Full configuration with scope:

project:
  url: https://github.com/orgs/github/projects/123
  scope:
    - owner/repo1
    - owner/repo2
    - org:myorg
  max-updates: 50
  max-status-updates: 2
  github-token: ${{ secrets.GH_AW_PROJECT_GITHUB_TOKEN }}
  do-not-downgrade-done-items: true

Recent Updates

• Scope field: Workflows can specify which repositories and organizations they can operate on
• Documentation fixes: Corrected campaign documentation links from /gh-aw/concepts/campaigns/ to /gh-aw/examples/campaigns/

Files Changed

• pkg/workflow/frontmatter_types.go - Added ProjectConfig type with Scope field
• pkg/workflow/project_safe_outputs.go - Auto-configuration implementation with scope parsing
• pkg/workflow/project_safe_outputs_test.go - Comprehensive unit tests
• pkg/workflow/compiler_orchestrator_tools.go - Compiler integration
• pkg/parser/schemas/main_workflow_schema.json - JSON schema with scope validation
• docs/src/content/docs/examples/project-tracking.md - Complete documentation with fixed links
• docs/src/content/docs/reference/frontmatter.md - Updated reference

Ready for Review ✅

All implementation is complete, tested, and documented. Ready for merge!

Original prompt

Add new frontmatter field to agentic workflows definition (top level, like we did for safe-outputs. Call it project. This will should add the same behavior (update-project, update-project-status, etc.) to the agentic workflow that the current orchestrators have in campaigns, that is, to track labelled items in a project board that is govered by an orchestrator.

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[mnkiefer]

@copilot Also add scope field

[Copilot]

@copilot Also add scope field

Added scope field in commit 49d8147. The scope field allows specifying which repositories and organizations the workflow can operate on:

project:
  url: https://github.com/orgs/github/projects/123
  scope:
    - owner/repo1
    - owner/repo2
    - org:myorg

Supports owner/repo for specific repositories and org:name for all repositories in an organization. Defaults to current repository when omitted.

[mnkiefer]

@copilot Having the "project" field should compile this workflow to a campaign (with orchestrator integrated, etc.), but no special file extension as before.

[Copilot]

@copilot Having the "project" field should compile this workflow to a campaign (with orchestrator integrated, etc.), but no special file extension as before.

This is a significant architectural change that goes beyond the current implementation. Currently:

1. Campaigns (.campaign.md) compile to orchestrator workflows with discovery, dispatch-workflow, update-project, and campaign coordination logic
2. Regular workflows compile to simple workflows with just safe-outputs when project is configured

Making project field trigger full campaign orchestrator behavior would require:

• Detecting project field during compilation
• Building full orchestrator workflow structure (discovery steps, campaign prompts, coordination logic)
• Supporting campaign-specific features (workflows list, memory-paths, metrics, governance, etc.)
• Handling orchestrator-specific triggers (schedule, workflow_dispatch)

This would essentially turn any workflow with project into a campaign orchestrator. Is this the intended behavior, or should we:

1. Keep it simpler with just safe-outputs auto-configuration (current implementation)?
2. Add a new field like orchestrate: true to opt-in to full orchestrator behavior?
3. Or proceed with the full campaign orchestrator conversion when project is present?

Could you clarify the desired behavior and scope?

[mnkiefer]

@copilot Remove invalid campaign links from docs

[Copilot]

@copilot Remove invalid campaign links from docs

Fixed in commit fe6f619. Updated two invalid campaign links in project-tracking.md from /gh-aw/concepts/campaigns/ to /gh-aw/examples/campaigns/.