fix: make GitHub Project association optional in create-beaver-issue#18
fix: make GitHub Project association optional in create-beaver-issue#18sii-xinglong wants to merge 1 commit intomainfrom
Conversation
Add a confirmation step at the start of the workflow asking whether to associate the issue with a GitHub Project. When declined, project-related steps (load config, add to project, set fields) are skipped and the user specifies the target repo directly. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
📝 WalkthroughWalkthroughThe create-beaver-issue skill's workflow now makes GitHub Project association optional. When users decline project association, the skill collects a target repository instead and branches the parent-association logic to list existing repository issues. Tracking rules, milestone lookup, and post-creation behavior adapt based on the project association choice. Changes
Sequence Diagram(s)sequenceDiagram
actor User
participant Skill as Skill Workflow
participant GitHub as GitHub API
User->>Skill: Start create-beaver-issue wizard
Skill->>User: Is project association desired?
alt Project Association Chosen
User->>Skill: Yes, associate with project
Skill->>User: Request project config setup
Skill->>GitHub: Fetch Project V2 items
GitHub-->>Skill: Project items list
Skill->>User: Select parent from project items
else No Project Association
User->>Skill: No, use repository instead
Skill->>User: Request target repository (org/repo)
Skill->>GitHub: Fetch existing issues in repo
GitHub-->>Skill: Issues list
Skill->>User: Select parent from repository issues
end
Skill->>User: Configure tracking rules (context-dependent)
Skill->>User: Set milestone (from chosen context)
Skill->>GitHub: Create issue
GitHub-->>Skill: Issue created
Skill->>User: Display summary (omit project fields if not associated)
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Code Review
This pull request updates the SKILL.md documentation for the create-beaver-issue skill to support creating issues without a GitHub Project association, introducing conditional workflow steps and clarifying prerequisites. A review comment identifies ambiguity in the use of repository variables like {repo} and {issueRepo} across different workflow paths, suggesting clearer differentiation to avoid confusion during milestone selection and issue creation.
| 4. **Associate parent** (Task/SubTask only) -- If project associated: list project items via `gh project item-list`, filter by parent level, let user pick. If no project: list issues in target repo via `gh api repos/{org}/{repo}/issues`, filter by parent level, let user pick. | ||
| 5. **Collect title and description** -- Structure into 目标 (objective) and 验收标准 (acceptance criteria) sections. | ||
| 6. **Tracking rules** (Task/SubTask only) -- If project associated: select repos from config's `repositories` list (pre-check remembered defaults). If no project: let user specify repos manually. Optionally add paths and keywords. Goal issues use child rollup. | ||
| 7. **Select milestone** -- Query `gh api repos/{org}/{repo}/milestones`, let user pick or skip. |
There was a problem hiding this comment.
The use of {repo} here is ambiguous. It's defined in step 1 for the "no project" case, but for the "project associated" case, step 2 defines issueRepo. This makes it unclear which repository is being referred to when a project is associated.
To improve clarity and align with the structure of steps 4 and 6, consider explicitly mentioning both scenarios. For example:
7. **Select milestone** -- Query milestones from the appropriate repository (issueRepo if project-associated, or the user-provided repo otherwise) and let the user pick or skip.
As a related point, the Create issue: command on line 81 still uses {issueRepo}, which seems incorrect for the "no project" case and may need to be updated as well.
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (4)
plugins/beaver/skills/create-beaver-issue/SKILL.md (4)
3-3:⚠️ Potential issue | 🟡 MinorUpdate description to reflect optional Project association.
The description states the skill creates issues "with Project V2 field setup", but the PR makes project association optional. This could mislead users into thinking project integration is always required.
📝 Suggested description update
-description: Create a Beaver-tracked GitHub Issue (Goal/Task/SubTask) with Project V2 field setup and tracking rules. Trigger this skill whenever the user wants to create a GitHub issue. +description: Create a Beaver-tracked GitHub Issue (Goal/Task/SubTask) with optional Project V2 field setup and tracking rules. Trigger this skill whenever the user wants to create a GitHub issue.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@plugins/beaver/skills/create-beaver-issue/SKILL.md` at line 3, Update the description in SKILL.md for the create-beaver-issue skill to indicate project association is optional: change the phrase "with Project V2 field setup" to something like "optionally with Project V2 field setup" or "supports optional Project V2 association" so users won't assume project integration is mandatory; locate the description line in SKILL.md for the create-beaver-issue skill and revise it accordingly.
8-8:⚠️ Potential issue | 🟡 MinorUpdate opening paragraph to reflect optional Project association.
The opening paragraph claims "automatic Project V2 field setup" is always performed, but project association is now optional per this PR.
📝 Suggested paragraph update
-Create a single Beaver-tracked GitHub Issue (Goal / Task / SubTask) with automatic Project V2 field setup and tracking rule configuration. The wizard collects issue details, builds a structured body with a `beaver-tracking` comment block, creates the issue via `gh api`, adds it to the Project V2, sets Level/Status/Progress fields, and links to the parent issue via GitHub's native sub-issues if applicable. +Create a single Beaver-tracked GitHub Issue (Goal / Task / SubTask) with optional Project V2 field setup and tracking rule configuration. The wizard collects issue details, builds a structured body with a `beaver-tracking` comment block, creates the issue via `gh api`, and optionally adds it to a Project V2 with Level/Status/Progress fields. Links to the parent issue via GitHub's native sub-issues if applicable.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@plugins/beaver/skills/create-beaver-issue/SKILL.md` at line 8, Update the opening paragraph in SKILL.md to state that Project V2 field setup is optional rather than always performed: change the sentence that currently claims "automatic Project V2 field setup" to indicate the wizard will perform Project V2 setup and tracking rule configuration only when a Project is associated (e.g., "optional Project V2 field setup when a project is selected"); keep references to the `beaver-tracking` comment block, creation via `gh api`, adding to Project V2, and linking sub-issues intact so readers understand the other steps remain unchanged.
80-86:⚠️ Potential issue | 🟠 MajorRepository reference must be conditional on project association.
The create issue command uses
repos/{org}/{issueRepo}/issues, butissueRepoonly exists when associating with a Project (from thebeaver-config). In non-project mode, the target repository from step 1 should be used instead.📝 Suggested conditional documentation
**Create issue:** + +Use `{issueRepo}` from the project config when associating with a Project, or the target `{repo}` collected in step 1 when not associating with a Project. + ```bash gh api repos/{org}/{issueRepo}/issues --method POST \Alternatively, use a generic placeholder like
{targetRepo}throughout and define it at the beginning of the commands section.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@plugins/beaver/skills/create-beaver-issue/SKILL.md` around lines 80 - 86, The docs currently hardcode the API call to repos/{org}/{issueRepo}/issues but {issueRepo} only exists when a Project is selected, so update the documentation for the create-beaver-issue skill to conditionally reference the repository: either show two variants (project-associated: repos/{org}/{issueRepo}/issues, non-project: repos/{org}/{targetRepo}/issues) or replace all uses with a single placeholder {targetRepo} and add a short preamble that defines {targetRepo} as "the selected target repository (from step 1) or the project's issueRepo if a Project is associated)"; ensure the text also mentions adding -f milestone={number} when applicable and the retry behavior when -f type fails.
101-110:⚠️ Potential issue | 🟠 MajorParent linking commands also need conditional repository references.
The parent linking commands use
{issueRepo}in three places (lines 104, 107, 107), but this field only exists with project association. In non-project mode, use the target repository instead.📝 Suggested note
Add a note at the beginning of the "Link to parent" subsection:
**Link to parent** (Task/SubTask only): Use GitHub's native sub-issues API to establish the parent-child relationship. Use `{issueRepo}` from config when associating with a Project, or the target `{repo}` when not.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@plugins/beaver/skills/create-beaver-issue/SKILL.md` around lines 101 - 110, Update the "Link to parent" subsection to conditionally use the repository variable depending on project mode: replace the hardcoded {issueRepo} usage in the gh api commands (the lines that compute CHILD_ID and post to /issues/{parent_number}/sub_issues) with a variable that selects {issueRepo} when project-associated and falls back to the target {repo} when not; also add the suggested note at the start of the subsection explaining "Use {issueRepo} from config when associating with a Project, or the target {repo} when not" so readers know which repo placeholder to use.
🧹 Nitpick comments (4)
plugins/beaver/skills/create-beaver-issue/SKILL.md (4)
37-37: Explicitly document milestone repository branching.Step 7 uses
{org}/{repo}for milestone lookup but doesn't explicitly state which repo this refers to based on project association. The AI summary mentions "Milestone lookup now depends on the chosen context (project uses the configissueRepo; non-project uses the target repo)" but the workflow step should make this branching explicit.♻️ Suggested clarification
-7. **Select milestone** -- Query `gh api repos/{org}/{repo}/milestones`, let user pick or skip. +7. **Select milestone** -- Query `gh api repos/{org}/{repo}/milestones` where `{repo}` is the config's `issueRepo` (if project associated) or the target repo (if not), let user pick or skip.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@plugins/beaver/skills/create-beaver-issue/SKILL.md` at line 37, Update Step 7 in SKILL.md to explicitly state the repo used for milestone lookup: clarify that when the user is creating an issue within a project context the milestone API call uses the project's configured issueRepo (config field `issueRepo`), and when not in a project context it uses the target repository (`{org}/{repo}`); mention the branching logic so readers know to query `gh api repos/{org}/{repo}/milestones` against either the project's `issueRepo` or the target repo depending on the chosen context.
114-114: Specify which project fields are omitted from the summary.The note "omit project fields if no project association" could be more specific. Based on the workflow, these fields would include: project URL/identifier, status, progress, and level (if not set via issue type API).
♻️ Suggested clarification
-1. Print summary (issue URL, level, label, milestone, status, progress, parent link, project — omit project fields if no project association). +1. Print summary (issue URL, level, label, milestone, parent link, and if project associated: project identifier, status, progress).🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@plugins/beaver/skills/create-beaver-issue/SKILL.md` at line 114, Update the "Print summary" bullet in SKILL.md (the line starting "Print summary (issue URL, level, label, milestone, status, progress, parent link, project — omit project fields if no project association).") to explicitly list which project-related fields are omitted when there is no project association: project URL/identifier, project status, project progress, and project level (if level is only set via the issue type API); keep the rest of the summary fields unchanged.
14-14: Simplify the beaver-config code fence reference.The nested backticks (
```yaml beaver-config`) make the formatting harder to read. Consider using a simpler reference or example.♻️ Suggested simplification
-- If associating with a Project: Project README must contain a fenced ```` ```yaml beaver-config ```` block with `repositories` and `issueRepo` +- If associating with a Project: Project README must contain a YAML code fence with identifier `beaver-config` that defines `repositories` and `issueRepo`🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@plugins/beaver/skills/create-beaver-issue/SKILL.md` at line 14, Replace the nested backtick code-fence reference ```` ```yaml beaver-config ```` in SKILL.md with a simpler, clearer phrasing such as "a YAML code fence labeled `beaver-config`" or "a fenced YAML code block with identifier `beaver-config`" and keep the requirement that it defines `repositories` and `issueRepo`; update the sentence that currently reads "If associating with a Project: Project README must contain a fenced ```` ```yaml beaver-config ```` block with `repositories` and `issueRepo`" to the simplified wording.
31-31: Clarify the workflow branching rather than "skip to step 3".The phrasing "skip to step 3" is misleading because step 3 is the next step anyway. The key point is that project-related steps (2, parts of 4, parts of 6, and 8) are omitted.
♻️ Suggested clarification
-1. **Confirm Project association** -- Ask user: "是否要关联到 GitHub Project?" If yes, continue to step 2. If no, ask for target repo (`org/repo`) and skip to step 3 (all project-related steps are skipped). +1. **Confirm Project association** -- Ask user: "是否要关联到 GitHub Project?" If yes, continue to step 2. If no, ask for target repo (`org/repo`) and continue with non-project workflow (skip step 2 and project-specific substeps in steps 4, 6, and 8).🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@plugins/beaver/skills/create-beaver-issue/SKILL.md` at line 31, The step text "If no, ask for target repo (`org/repo`) and skip to step 3 (all project-related steps are skipped)" is misleading; reword this branching to clearly state that answering "no" omits all project-related steps — specifically step 2, parts of step 4, parts of step 6, and step 8 — and that the flow continues by asking for the target repo and proceeding with the non-project path starting at step 3. Update the sentence in SKILL.md for the Confirm Project association section to explicitly say: if the user chooses not to associate a GitHub Project, ask for the target repo (`org/repo`), omit project-related steps (2, portions of 4 and 6, and 8), and continue with the non-project workflow beginning at step 3.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@plugins/beaver/skills/create-beaver-issue/SKILL.md`:
- Line 34: The doc's "Associate parent" step is ambiguous about filtering by
parent level when using gh api repos/{org}/{repo}/issues; update that sentence
to specify a concrete mechanism — e.g., query all issues via gh api
repos/{org}/{repo}/issues and then filter client-side by standardized labels
(e.g., "Goal", "Task", "SubTask") plus the "Control-By-Beaver" label so the code
can reliably identify parent level; mention this label-based filtering approach
and that the alternative options (type field, body parsing, or manual selection)
are valid fallbacks.
---
Outside diff comments:
In `@plugins/beaver/skills/create-beaver-issue/SKILL.md`:
- Line 3: Update the description in SKILL.md for the create-beaver-issue skill
to indicate project association is optional: change the phrase "with Project V2
field setup" to something like "optionally with Project V2 field setup" or
"supports optional Project V2 association" so users won't assume project
integration is mandatory; locate the description line in SKILL.md for the
create-beaver-issue skill and revise it accordingly.
- Line 8: Update the opening paragraph in SKILL.md to state that Project V2
field setup is optional rather than always performed: change the sentence that
currently claims "automatic Project V2 field setup" to indicate the wizard will
perform Project V2 setup and tracking rule configuration only when a Project is
associated (e.g., "optional Project V2 field setup when a project is selected");
keep references to the `beaver-tracking` comment block, creation via `gh api`,
adding to Project V2, and linking sub-issues intact so readers understand the
other steps remain unchanged.
- Around line 80-86: The docs currently hardcode the API call to
repos/{org}/{issueRepo}/issues but {issueRepo} only exists when a Project is
selected, so update the documentation for the create-beaver-issue skill to
conditionally reference the repository: either show two variants
(project-associated: repos/{org}/{issueRepo}/issues, non-project:
repos/{org}/{targetRepo}/issues) or replace all uses with a single placeholder
{targetRepo} and add a short preamble that defines {targetRepo} as "the selected
target repository (from step 1) or the project's issueRepo if a Project is
associated)"; ensure the text also mentions adding -f milestone={number} when
applicable and the retry behavior when -f type fails.
- Around line 101-110: Update the "Link to parent" subsection to conditionally
use the repository variable depending on project mode: replace the hardcoded
{issueRepo} usage in the gh api commands (the lines that compute CHILD_ID and
post to /issues/{parent_number}/sub_issues) with a variable that selects
{issueRepo} when project-associated and falls back to the target {repo} when
not; also add the suggested note at the start of the subsection explaining "Use
{issueRepo} from config when associating with a Project, or the target {repo}
when not" so readers know which repo placeholder to use.
---
Nitpick comments:
In `@plugins/beaver/skills/create-beaver-issue/SKILL.md`:
- Line 37: Update Step 7 in SKILL.md to explicitly state the repo used for
milestone lookup: clarify that when the user is creating an issue within a
project context the milestone API call uses the project's configured issueRepo
(config field `issueRepo`), and when not in a project context it uses the target
repository (`{org}/{repo}`); mention the branching logic so readers know to
query `gh api repos/{org}/{repo}/milestones` against either the project's
`issueRepo` or the target repo depending on the chosen context.
- Line 114: Update the "Print summary" bullet in SKILL.md (the line starting
"Print summary (issue URL, level, label, milestone, status, progress, parent
link, project — omit project fields if no project association).") to explicitly
list which project-related fields are omitted when there is no project
association: project URL/identifier, project status, project progress, and
project level (if level is only set via the issue type API); keep the rest of
the summary fields unchanged.
- Line 14: Replace the nested backtick code-fence reference ```` ```yaml
beaver-config ```` in SKILL.md with a simpler, clearer phrasing such as "a YAML
code fence labeled `beaver-config`" or "a fenced YAML code block with identifier
`beaver-config`" and keep the requirement that it defines `repositories` and
`issueRepo`; update the sentence that currently reads "If associating with a
Project: Project README must contain a fenced ```` ```yaml beaver-config ````
block with `repositories` and `issueRepo`" to the simplified wording.
- Line 31: The step text "If no, ask for target repo (`org/repo`) and skip to
step 3 (all project-related steps are skipped)" is misleading; reword this
branching to clearly state that answering "no" omits all project-related steps —
specifically step 2, parts of step 4, parts of step 6, and step 8 — and that the
flow continues by asking for the target repo and proceeding with the non-project
path starting at step 3. Update the sentence in SKILL.md for the Confirm Project
association section to explicitly say: if the user chooses not to associate a
GitHub Project, ask for the target repo (`org/repo`), omit project-related steps
(2, portions of 4 and 6, and 8), and continue with the non-project workflow
beginning at step 3.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 88557ca3-6526-444e-913a-edd4c993459b
📒 Files selected for processing (1)
plugins/beaver/skills/create-beaver-issue/SKILL.md
| 1. **Confirm Project association** -- Ask user: "是否要关联到 GitHub Project?" If yes, continue to step 2. If no, ask for target repo (`org/repo`) and skip to step 3 (all project-related steps are skipped). | ||
| 2. **Load project config** (project only) -- Parse project identifier (`org/number` or URL), run `gh project view {number} --owner {org} --format json`, extract `readme` and `id` (project node ID). Parse `beaver-config` YAML block from the README for `repositories`, `issueRepo`, and optional `customFields`. | ||
| 3. **Choose level** -- Goal (high-level objective), Task (breakdown of a Goal), or SubTask (finest granularity). | ||
| 4. **Associate parent** (Task/SubTask only) -- If project associated: list project items via `gh project item-list`, filter by parent level, let user pick. If no project: list issues in target repo via `gh api repos/{org}/{repo}/issues`, filter by parent level, let user pick. |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check how other parts of the beaver workflow identify issue levels
# Search for level detection patterns in existing beaver skills
rg -n -C3 'level|Level|Goal|Task|SubTask' --type=md plugins/beaver/Repository: primatrix/skills
Length of output: 11488
🏁 Script executed:
# Look for any implementation files or scripts in beaver plugin that show filtering patterns
find plugins/beaver -type f \( -name "*.sh" -o -name "*.bash" -o -name "*.js" -o -name "*.ts" \) 2>/dev/null | head -20Repository: primatrix/skills
Length of output: 42
🏁 Script executed:
# Search for how issue listing/filtering is done in other beaver skills
rg -l 'gh api repos.*issues' plugins/beaver/Repository: primatrix/skills
Length of output: 110
🏁 Script executed:
# Check if there are any references to issue type filtering in the codebase
rg -n 'type.*filter|filter.*type' plugins/beaver/ --type=mdRepository: primatrix/skills
Length of output: 42
🏁 Script executed:
# Check if there are any configuration files or documentation about implementation
find plugins/beaver -type f -name "*.md" -o -name "*.yaml" -o -name "*.yml" | xargs ls -la 2>/dev/null | head -20Repository: primatrix/skills
Length of output: 347
🏁 Script executed:
# Search for any comments or hints in SKILL.md about filtering implementation
cat plugins/beaver/skills/create-beaver-issue/SKILL.md | grep -A5 -B5 "filter\|Filter"Repository: primatrix/skills
Length of output: 1545
🏁 Script executed:
# Check the structure and content of the beaver plugin directory
ls -la plugins/beaver/Repository: primatrix/skills
Length of output: 343
🏁 Script executed:
# Search for any mention of "parent" filtering patterns in all beaver documentation
rg -n 'parent' plugins/beaver/ -A2 -B2Repository: primatrix/skills
Length of output: 4202
🏁 Script executed:
# Check if there's a README or overview that explains the architecture
cat plugins/beaver/.claude-plugin/instructions.md 2>/dev/null || echo "No instructions file"Repository: primatrix/skills
Length of output: 80
Clarify how to filter issues by parent level in non-project mode.
Line 34 requires filtering issues by "parent level" when using gh api repos/{org}/{repo}/issues, but doesn't specify the mechanism. The GitHub REST issues API doesn't guarantee the type field is queryable in list responses. Specify one of these approaches:
- Query the type field directly if available in API responses
- Filter by labels (e.g., Goal/Task/SubTask labels alongside Control-By-Beaver)
- Parse issue bodies for level metadata
- Let users filter manually from the full list
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@plugins/beaver/skills/create-beaver-issue/SKILL.md` at line 34, The doc's
"Associate parent" step is ambiguous about filtering by parent level when using
gh api repos/{org}/{repo}/issues; update that sentence to specify a concrete
mechanism — e.g., query all issues via gh api repos/{org}/{repo}/issues and then
filter client-side by standardized labels (e.g., "Goal", "Task", "SubTask") plus
the "Control-By-Beaver" label so the code can reliably identify parent level;
mention this label-based filtering approach and that the alternative options
(type field, body parsing, or manual selection) are valid fallbacks.
Summary
create-beaver-issueworkflow asking whether to associate the issue with a GitHub Project V2Test plan
create-beaver-issue, choose "no" for project association, verify project steps are skippedcreate-beaver-issue, choose "yes" for project association, verify full workflow works as before🤖 Generated with Claude Code
Summary by CodeRabbit