Problem Statement
The /agentready assess command authorization in the GitHub Actions workflow (agentready-assessment.yml) is currently hardcoded to a single username (jeremyeder). This makes it difficult to manage access at scale, requiring direct workflow file edits to add or remove authorized users, and provides no audit trail for access changes.
Proposed Solution
Implement a configuration file-based ACL (Access Control List) at .github/agentready-acl.yml that defines authorized users for the /agentready assess command. The workflow would read this file to determine authorization, replacing the hardcoded username check.
Example configuration:
# Authorized users for /agentready assess command
authorized_users:
- jeremyeder
- contributor1
- contributor2
Alternatives Considered
-
GitHub Repository Variables: Store authorized users in a repository variable (e.g., AGENTREADY_ALLOWED_USERS). Pros: Easy to manage via GitHub UI. Cons: Less visible, no audit trail, requires repo admin access.
-
GitHub Team Membership: Check if the user belongs to a specific GitHub team. Pros: Scalable, org-level control. Cons: Requires org admin setup, API calls, more complex implementation.
-
CODEOWNERS Integration: Use CODEOWNERS file to determine authorization. Cons: Mixes code review responsibilities with command authorization.
Use Cases
- Multi-maintainer repositories: Projects with multiple maintainers can grant
/agentready assess access to their team without modifying workflow files.
- Community contribution: External contributors can be granted access via a simple PR to add their username to the ACL.
- Access audit: Repository owners can easily see who has access by viewing the ACL file, with full git history of changes.
- Temporary access: Grant and revoke access through documented PRs, enabling review and approval workflows.
Additional Context
Current implementation in agentready-assessment.yml:
if: |
(github.event_name == 'issue_comment' && contains(github.event.comment.body, '/agentready assess') && github.event.comment.user.login == 'jeremyeder') ||
...
Proposed workflow structure:
┌─────────────────┐
│ Comment Event │
└────────┬────────┘
▼
┌─────────────────┐
│ check-acl job │──► Read .github/agentready-acl.yml
└────────┬────────┘
▼
┌────┴────┐
│Authorized?│
└────┬────┘
Yes │ No
▼ ▼
┌──────┐ ┌────────────┐
│assess│ │unauthorized│
└──────┘ └────────────┘
Acceptance Criteria
Priority
How important is this feature to you?
Problem Statement
The
/agentready assesscommand authorization in the GitHub Actions workflow (agentready-assessment.yml) is currently hardcoded to a single username (jeremyeder). This makes it difficult to manage access at scale, requiring direct workflow file edits to add or remove authorized users, and provides no audit trail for access changes.Proposed Solution
Implement a configuration file-based ACL (Access Control List) at
.github/agentready-acl.ymlthat defines authorized users for the/agentready assesscommand. The workflow would read this file to determine authorization, replacing the hardcoded username check.Example configuration:
Alternatives Considered
GitHub Repository Variables: Store authorized users in a repository variable (e.g.,
AGENTREADY_ALLOWED_USERS). Pros: Easy to manage via GitHub UI. Cons: Less visible, no audit trail, requires repo admin access.GitHub Team Membership: Check if the user belongs to a specific GitHub team. Pros: Scalable, org-level control. Cons: Requires org admin setup, API calls, more complex implementation.
CODEOWNERS Integration: Use CODEOWNERS file to determine authorization. Cons: Mixes code review responsibilities with command authorization.
Use Cases
/agentready assessaccess to their team without modifying workflow files.Additional Context
Current implementation in
agentready-assessment.yml:Proposed workflow structure:
Acceptance Criteria
.github/agentready-acl.ymlschema withauthorized_userslistcheck-acljob to workflow that reads and parses the ACL fileassessjob to depend oncheck-acloutput for authorizationunauthorizedjob to depend oncheck-acloutputworkflow_dispatch(always authorized)Priority
How important is this feature to you?