Add agent/working label to track active agent runs

[cgwaltersbot]

Summary

Implements automatic agent/working label management to all three gh-aw workflows (drafter, review, fix) to provide visibility into which issues/PRs currently have agents actively working on them.

Changes

Workflow modifications

Each workflow now includes two new jobs:

1. add_working_label - Runs after pre_activation succeeds and adds the agent/working label:

   • For drafter.lock.yml: Adds label to the issue
   • For review.lock.yml and fix.lock.yml: Adds label to the pull request

2. remove_working_label - Runs at the end with if: always() to remove the label regardless of success or failure

The jobs use the GitHub App token (same pattern as merge.yml) and plain GitHub Actions steps, not gh-aw's safe-outputs mechanism. This ensures cleanup happens even if the agent job fails or times out.

Documentation updates

Updated README.md to:

• Add agent/working to the repository setup checklist (now 5 labels instead of 4)
• Explain how the label tracking works in the "Design notes and gotchas" section
• Document that the .lock.yml modifications are manual and will be lost if workflows are recompiled

Validation

Changes validated by:

• Workflow YAML syntax verified with grep and structure inspection
• Jobs properly sequenced with correct needs: dependencies
• The if: always() condition ensures cleanup runs in all cases
• Issue vs PR label commands correctly differentiated (drafter uses gh issue edit, review/fix use gh pr edit)
• Followed the same pattern as merge.yml for GitHub App token usage

Important note

The .lock.yml files are normally auto-generated by gh aw compile. These changes are manual modifications to the compiled output and will be overwritten if the workflows are recompiled. The README now documents this and explains that these jobs need to be manually re-added after any recompilation.

• Resolves Add agent/working label to track active agent runs #26

Generated by Autonomous Developer Agent for #26 · 135.3 AIC · ⌖ 19.1 AIC · ⊞ 3.1K · ◷

[cgwaltersbot]

Review Feedback

The implementation is excellent and correct. The workflow YAML changes are well-structured with proper job dependencies, permissions, and error handling. However, there's one documentation error that needs to be corrected:

Documentation Error

Location: README.md:201-202 (in the "Repository setup checklist" section)

Issue: The cross-reference direction is incorrect. The text currently says:

(see "Agent working label tracking" below)

But the referenced section ("Agent working label tracking uses manual .lock.yml jobs") appears earlier in the document (lines 98-107) in the "Design notes and gotchas" section, not later.

Fix required: Change "below" to "above":

(see "Agent working label tracking" above)

What I Checked

✅ Workflow YAML syntax and structure
✅ Job dependencies and conditional execution
✅ Permissions (issues vs pull-requests)
✅ GitHub App token usage pattern
✅ Issue vs PR context handling
✅ Error handling and cleanup logic
✅ Security considerations
✅ Documentation completeness

Everything else looks great. Once the cross-reference is corrected, this will be ready to merge.

[cgwalters]

Closing without merging.

The approach here is functionally correct — the add_working_label/remove_working_label jobs, the if: always() cleanup, and the App-token pattern all do the right thing — but it's architecturally unsound: this PR hand-edits the compiled .lock.yml output (drafter.lock.yml, fix.lock.yml, review.lock.yml) directly instead of the .md source. Per this repo's compile-from-source model, .lock.yml files are generated artifacts regenerated via gh aw compile drafter fix review and are never hand-edited — the PR's own README addition acknowledges the hand-edits 'will be lost if you run gh aw compile', which means the very next recompile (e.g. from an unrelated change to any of these workflows) silently reverts this feature with no error or warning.

gh-aw supports exactly this kind of always-run cleanup job natively via a jobs: block in frontmatter: a custom job can declare needs: pre_activation (which the compiler automatically threads into activation's own dependencies) to run right after activation, and a second custom job with if: always() depending on the other built-in jobs to guarantee cleanup regardless of success/failure — all expressed at the .md level so it survives recompilation.

A proper fix redone at the source level will follow in a separate PR referencing #26.