Repository navigation
Conversation
…mand - Add /next-task slash command for parallel-aware task recommendations - Update list-tasks.sh to query all active PRD milestones and output JSON - Document parallel work streams in task-workflow.md Closes #179 Co-Authored-By: Claude Opus 4.5 <[email protected]>
|
Warning Rate limit exceeded
⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (1)
Note Other AI code review bot(s) detectedCodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review. 📝 WalkthroughWalkthroughAdds a parallel-aware "next task" workflow: new command doc, updates to task-workflow docs, and a rewritten Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant Assistant as Claude
participant Script as list-tasks.sh
participant GH as GitHub/API
participant PRDs as Active_PRD_MD
User->>Assistant: "What should I work on next?"
Assistant->>Script: run `list-tasks.sh --all`
Script->>GH: query issues by milestone and non-milestone labels
GH-->>Script: return issues JSON
Script-->>Assistant: {"milestone_tasks":[...],"non_milestone_tasks":[...]}
Assistant->>PRDs: read active PRD markdown(s) and parse Parallelization sections
PRDs-->>Assistant: track definitions and deliverable refs
Assistant->>Assistant: map tasks → tracks, detect busy/idle tracks
Assistant-->>User: structured recommendation (selected task, busy tracks, alternatives, edge cases)
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Comment |
Contributor
PR Reviewer Guide 🔍Here are some key observations to aid the review process:
|
Deploying living-architecture with
|
| Latest commit: |
f2c1d16
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://ccac3965.living-architecture.pages.dev |
| Branch Preview URL: | https://issue-179-parallel-aware-tas.living-architecture.pages.dev |
![qodo-code-review[bot]](https://avatars.githubusercontent.com/in/484649?s=60&v=4){kind=small}
Co-Authored-By: Claude Opus 4.5 <[email protected]>
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In @.claude/commands/next-task.md:
- Around line 58-65: The docs/edge-cases need to explicitly cover the case where
the active PRD directory is missing and list-tasks.sh returns an error payload;
add a bullet under "Edge Cases" (or expand the existing items) describing that
/next-task should detect the missing/empty active PRD directory error returned
by list-tasks.sh and surface a clear message like "Active PRD directory missing
or empty — no tasks available", and reference the code path that invokes
list-tasks.sh (the /next-task handler or the function that shells out to
list-tasks.sh) so implementers know to check the shell error payload and
normalize it into that specific user-facing message.
- Around line 7-13: Prepend a mandatory project overview check to the /next-task
workflow: before running the existing step that invokes ./scripts/list-tasks.sh,
add a step that reads and validates docs/project/project-overview.md to load
project context; ensure the workflow (the sequence in
.claude/commands/next-task.md) performs this read/validation first so subsequent
steps that parse PRDs’ Parallelization section (Section 10), map deliverables,
identify busy tracks, and recommend tasks use the overview for context and
compliance.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (3)
.claude/commands/next-task.mddocs/workflow/task-workflow.mdscripts/list-tasks.sh
🧰 Additional context used
🧠 Learnings (11)
📓 Common learnings
Learnt from: NTCoding
Repo: NTCoding/living-architecture PR: 120
File: docs/workflow/parallel-workflow.md:1-555
Timestamp: 2026-01-10T19:16:56.186Z
Learning: Investigation task documents (like `docs/workflow/parallel-workflow.md`) should focus on design and workflow specification rather than implementation concerns such as phased rollout plans, success metrics, and rollout risk mitigation. These operational details are addressed later when creating tasks to build the workflow.
Learnt from: CR
Repo: NTCoding/living-architecture PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-13T11:37:59.334Z
Learning: Follow docs/workflow/task-workflow.md from start to finish when working on any task. Do not make any changes or commit any code without following these steps exactly
Learnt from: CR
Repo: NTCoding/living-architecture PR: 0
File: packages/riviere-cli/CLAUDE.md:0-0
Timestamp: 2026-01-02T11:58:27.018Z
Learning: When modifying CLI commands in the riviere-cli tool, update the corresponding workflow prompts in docs/workflow/ directory (step-1 through step-6) to keep the extraction workflow in sync
📚 Learning: 2026-01-10T19:16:56.186Z
Learnt from: NTCoding
Repo: NTCoding/living-architecture PR: 120
File: docs/workflow/parallel-workflow.md:1-555
Timestamp: 2026-01-10T19:16:56.186Z
Learning: Investigation task documents (like `docs/workflow/parallel-workflow.md`) should focus on design and workflow specification rather than implementation concerns such as phased rollout plans, success metrics, and rollout risk mitigation. These operational details are addressed later when creating tasks to build the workflow.
Applied to files:
docs/workflow/task-workflow.md.claude/commands/next-task.md
📚 Learning: 2026-01-13T11:37:59.334Z
Learnt from: CR
Repo: NTCoding/living-architecture PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-13T11:37:59.334Z
Learning: Follow docs/workflow/task-workflow.md from start to finish when working on any task. Do not make any changes or commit any code without following these steps exactly
Applied to files:
docs/workflow/task-workflow.md.claude/commands/next-task.md
📚 Learning: 2026-01-13T11:37:59.334Z
Learnt from: CR
Repo: NTCoding/living-architecture PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-13T11:37:59.334Z
Learning: Always use scripts in `./scripts/` for git and GitHub operations (PRs, issues, tasks). Do not use `gh` or `git` commands directly unless no script exists
Applied to files:
docs/workflow/task-workflow.md
📚 Learning: 2026-01-13T11:37:59.334Z
Learnt from: CR
Repo: NTCoding/living-architecture PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-13T11:37:59.334Z
Learning: Read `docs/project/project-overview.md` before work and check `docs/project/PRD/active/*.md` for current PRD
Applied to files:
docs/workflow/task-workflow.md.claude/commands/next-task.md
📚 Learning: 2026-01-10T19:16:48.557Z
Learnt from: NTCoding
Repo: NTCoding/living-architecture PR: 120
File: docs/workflow/parallel-workflow.md:160-281
Timestamp: 2026-01-10T19:16:48.557Z
Learning: In docs/workflow .md files (e.g., docs/workflow/parallel-workflow.md), it's acceptable to reference scripts, commands, or features that don't yet exist in the codebase if the PR is focused on research/design rather than implementation. Treat such references as forward-looking specifications for future tasks, not current capabilities, and ensure the PR clearly communicates the scoped intent (design/research) to avoid misinterpretation as implemented functionality.
Applied to files:
docs/workflow/task-workflow.md
📚 Learning: 2026-01-06T18:02:51.422Z
Learnt from: NTCoding
Repo: NTCoding/living-architecture PR: 58
File: scripts/get-pr-feedback.sh:45-55
Timestamp: 2026-01-06T18:02:51.422Z
Learning: In shell scripts that call GraphQL APIs (e.g., scripts/get-pr-feedback.sh and similar), prefer using sed-based interpolation for GraphQL variables instead of gh api graphql's -f/-F flags. Rationale: sed-based interpolation is typically simpler and more robust in Bash contexts, avoids JSON encoding pitfalls, and keeps the script portable. Implement by building the GraphQL query as a string and substituting variables with sed or parameter expansion, ensuring proper escaping. If you must use -f/-F, provide clear justification in a comment.
Applied to files:
scripts/list-tasks.sh
📚 Learning: 2026-01-06T18:13:47.289Z
Learnt from: NTCoding
Repo: NTCoding/living-architecture PR: 58
File: scripts/reply-to-thread.sh:1-12
Timestamp: 2026-01-06T18:13:47.289Z
Learning: In shell scripts across the repository (e.g., scripts/reply-to-thread.sh), keep the code simple by not adding explicit preflight tool-availability checks for external commands (like gh or jq) when those tools would fail on first use anyway. Such checks add boilerplate without changing behavior. If you must guard against missing tools, prefer a minimal, early startup check or rely on the script failing naturally at the point of use.
Applied to files:
scripts/list-tasks.sh
📚 Learning: 2026-01-11T22:40:43.505Z
Learnt from: NTCoding
Repo: NTCoding/living-architecture PR: 132
File: scripts/submit-pr.sh:76-82
Timestamp: 2026-01-11T22:40:43.505Z
Learning: Shell scripts (any *.sh) can bypass agent tool invocation hooks if the hooks only monitor the direct command invoked by the interpreter. Ensure review checks account for commands executed inside scripts (e.g., git push inside submit-pr.sh). To reduce risk, either ensure hooks wrap or audit calls inside scripts, or refactor critical steps into explicit tool invocations exposed to the agent, or implement script-aware interception within the hook. For this repository, verify how scripts/submit-pr.sh calls tools and add guardrails if necessary.
Applied to files:
scripts/list-tasks.sh
📚 Learning: 2026-01-09T18:10:15.724Z
Learnt from: NTCoding
Repo: NTCoding/living-architecture PR: 85
File: .claude/commands/post-merge-completion.md:35-39
Timestamp: 2026-01-09T18:10:15.724Z
Learning: In .claude/commands/post-merge-completion.md, the review files in `reviews/<branch>/` (code-review.md, bug-scanner.md, task-check.md, doc-suggestions.md) are optional inputs to the reflection process. The post-merge-completion command should work gracefully even if these files are missing or if /complete-task wasn't run before merging.
Applied to files:
.claude/commands/next-task.md
📚 Learning: 2026-01-10T19:16:48.557Z
Learnt from: NTCoding
Repo: NTCoding/living-architecture PR: 120
File: docs/workflow/parallel-workflow.md:160-281
Timestamp: 2026-01-10T19:16:48.557Z
Learning: In the NTCoding/living-architecture repository, design and investigation documents (such as those in docs/workflow/) can reference scripts, commands, or features that don't yet exist in the codebase. These references serve as specifications for future implementation tasks, not documentation of current capabilities. This is acceptable when the PR scope is research/design rather than implementation.
Applied to files:
.claude/commands/next-task.md
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Cloudflare Pages
🔇 Additional comments (9)
.claude/commands/next-task.md (3)
17-24: Track mapping cues are clear and comprehensive.The examples cover milestone, deliverable, and research references succinctly.
36-56: Recommendation format is actionable and user-friendly.The structure is concise and guides the user to confirm or choose an alternative.
66-68: Post-confirmation step aligns with the Start Task workflow.The handoff to
start-task.shafter user confirmation is correct.docs/workflow/task-workflow.md (3)
23-30: /next-task lifecycle entry fits the autonomy table.The permission level aligns with the rest of the workflow.
101-111: Next Task and List Tasks guidance is clear and properly sequenced.The flow from recommendation to confirmation to start-task is explicit and consistent.
129-162: Parallel Work Streams section is well-scoped.The steps and track mapping examples cleanly reflect the new parallel-aware behavior.
scripts/list-tasks.sh (3)
2-46: Argument parsing and exclusive-flag handling look solid.The guard against multiple label flags keeps usage predictable.
48-62: Non-milestone mode output remains backward-compatible.The human-readable listing is consistent with the prior behavior.
65-93: [Your rewritten review comment text here]
[Exactly ONE classification tag]
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
NTCoding
commented
Jan 15, 2026
NTCoding
left a comment
NTCoding
left a comment
Owner
Author
There was a problem hiding this comment.
Regarding the additional suggestions in the review:
-
Edge case for missing PRD directory - The script already handles this case by exiting with error code 1 and outputting an error message to stderr. The /next-task command will see this error and can surface it appropriately. This is sufficient for the current implementation.
-
Prepend project overview check - Reading project-overview.md is not part of this task's requirements. The /next-task command focuses on task discovery and work stream analysis. Adding project overview reading would be scope creep and can be addressed in a follow-up if needed.
All 5 inline comments have been addressed with replies explaining the decisions.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@scripts/list-tasks.sh`:
- Around line 72-73: The find invocation that sets PRD_FILES currently uses a
generic "*.md" pattern and can pick up non-PRD files; change the pattern to
explicitly match PRD-*.md so only files following the PRD-<milestone>.md
convention are returned (update the PRD_FILES assignment that uses find
"$PRD_DIR" -maxdepth 1 -name ... to use "PRD-*.md"); ensure downstream code that
parses filenames (the logic that expects PRD-<milestone>.md around lines where
PRD_FILES is used) continues to work with the new pattern.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
scripts/list-tasks.sh
🧰 Additional context used
🧠 Learnings (8)
📓 Common learnings
Learnt from: CR
Repo: NTCoding/living-architecture PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-13T11:37:59.334Z
Learning: Follow docs/workflow/task-workflow.md from start to finish when working on any task. Do not make any changes or commit any code without following these steps exactly
Learnt from: NTCoding
Repo: NTCoding/living-architecture PR: 120
File: docs/workflow/parallel-workflow.md:1-555
Timestamp: 2026-01-10T19:16:56.186Z
Learning: Investigation task documents (like `docs/workflow/parallel-workflow.md`) should focus on design and workflow specification rather than implementation concerns such as phased rollout plans, success metrics, and rollout risk mitigation. These operational details are addressed later when creating tasks to build the workflow.
Learnt from: CR
Repo: NTCoding/living-architecture PR: 0
File: packages/riviere-cli/CLAUDE.md:0-0
Timestamp: 2026-01-02T11:58:27.018Z
Learning: When modifying CLI commands in the riviere-cli tool, update the corresponding workflow prompts in docs/workflow/ directory (step-1 through step-6) to keep the extraction workflow in sync
Learnt from: NTCoding
Repo: NTCoding/living-architecture PR: 120
File: docs/workflow/parallel-workflow.md:160-281
Timestamp: 2026-01-10T19:16:48.557Z
Learning: In the NTCoding/living-architecture repository, design and investigation documents (such as those in docs/workflow/) can reference scripts, commands, or features that don't yet exist in the codebase. These references serve as specifications for future implementation tasks, not documentation of current capabilities. This is acceptable when the PR scope is research/design rather than implementation.
📚 Learning: 2026-01-09T18:10:15.724Z
Learnt from: NTCoding
Repo: NTCoding/living-architecture PR: 85
File: .claude/commands/post-merge-completion.md:35-39
Timestamp: 2026-01-09T18:10:15.724Z
Learning: In .claude/commands/post-merge-completion.md, the review files in `reviews/<branch>/` (code-review.md, bug-scanner.md, task-check.md, doc-suggestions.md) are optional inputs to the reflection process. The post-merge-completion command should work gracefully even if these files are missing or if /complete-task wasn't run before merging.
Applied to files:
scripts/list-tasks.sh
📚 Learning: 2026-01-07T08:54:48.071Z
Learnt from: CR
Repo: NTCoding/living-architecture PR: 0
File: docs/workflow/code-review.md:0-0
Timestamp: 2026-01-07T08:54:48.071Z
Learning: Applies to docs/workflow/**/*.sh : In shell scripts (.sh files), use `jq` for JSON construction instead of manual string escaping to properly handle backslashes, newlines, and tabs.
Applied to files:
scripts/list-tasks.sh
📚 Learning: 2026-01-06T18:13:47.289Z
Learnt from: NTCoding
Repo: NTCoding/living-architecture PR: 58
File: scripts/reply-to-thread.sh:1-12
Timestamp: 2026-01-06T18:13:47.289Z
Learning: In shell scripts across the repository (e.g., scripts/reply-to-thread.sh), keep the code simple by not adding explicit preflight tool-availability checks for external commands (like gh or jq) when those tools would fail on first use anyway. Such checks add boilerplate without changing behavior. If you must guard against missing tools, prefer a minimal, early startup check or rely on the script failing naturally at the point of use.
Applied to files:
scripts/list-tasks.sh
📚 Learning: 2026-01-13T11:37:59.334Z
Learnt from: CR
Repo: NTCoding/living-architecture PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-13T11:37:59.334Z
Learning: When you encounter a command failure (script doesn't exist, tool errors, missing dependencies), stop and consult with user. When you encounter code quality issues (lint errors, unused dependencies, test failures, knip warnings), fix them directly
Applied to files:
scripts/list-tasks.sh
📚 Learning: 2026-01-13T11:37:59.334Z
Learnt from: CR
Repo: NTCoding/living-architecture PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-13T11:37:59.334Z
Learning: Always use scripts in `./scripts/` for git and GitHub operations (PRs, issues, tasks). Do not use `gh` or `git` commands directly unless no script exists
Applied to files:
scripts/list-tasks.sh
📚 Learning: 2026-01-06T18:02:51.422Z
Learnt from: NTCoding
Repo: NTCoding/living-architecture PR: 58
File: scripts/get-pr-feedback.sh:45-55
Timestamp: 2026-01-06T18:02:51.422Z
Learning: In shell scripts that call GraphQL APIs (e.g., scripts/get-pr-feedback.sh and similar), prefer using sed-based interpolation for GraphQL variables instead of gh api graphql's -f/-F flags. Rationale: sed-based interpolation is typically simpler and more robust in Bash contexts, avoids JSON encoding pitfalls, and keeps the script portable. Implement by building the GraphQL query as a string and substituting variables with sed or parameter expansion, ensuring proper escaping. If you must use -f/-F, provide clear justification in a comment.
Applied to files:
scripts/list-tasks.sh
📚 Learning: 2026-01-11T22:40:43.505Z
Learnt from: NTCoding
Repo: NTCoding/living-architecture PR: 132
File: scripts/submit-pr.sh:76-82
Timestamp: 2026-01-11T22:40:43.505Z
Learning: Shell scripts (any *.sh) can bypass agent tool invocation hooks if the hooks only monitor the direct command invoked by the interpreter. Ensure review checks account for commands executed inside scripts (e.g., git push inside submit-pr.sh). To reduce risk, either ensure hooks wrap or audit calls inside scripts, or refactor critical steps into explicit tool invocations exposed to the agent, or implement script-aware interception within the hook. For this repository, verify how scripts/submit-pr.sh calls tools and add guardrails if necessary.
Applied to files:
scripts/list-tasks.sh
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Cloudflare Pages
🔇 Additional comments (5)
scripts/list-tasks.sh (5)
13-46: LGTM!The argument parsing is well-structured with proper mutual exclusivity enforcement and clear error messages.
48-63: LGTM!The non-milestone mode correctly maintains backward compatibility with a clean display name mapping and appropriate filtering for unassigned issues.
65-70: LGTM!Proper error handling with JSON error format and non-zero exit status.
77-93: LGTM!The loop logic correctly iterates over PRD files, extracts milestone names, queries tasks with appropriate error handling, and merges results. The
jq -s 'add'pattern effectively concatenates JSON arrays.
95-105: LGTM!The non-milestone query correctly implements OR logic for labels using jq's select filter, and the final JSON construction properly uses
jq -n --argjsonfor safe JSON assembly. Based on learnings, this follows the best practice of using jq for JSON construction instead of manual string escaping.
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
- Use PRD-*.md pattern to avoid processing non-PRD markdown files - Document missing PRD directory edge case in /next-task command Co-Authored-By: Claude Opus 4.5 <[email protected]>
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@scripts/list-tasks.sh`:
- Around line 95-99: NON_MILESTONE_TASKS currently selects issues by labels only
and can include issues that belong to a milestone; update the gh query that sets
NON_MILESTONE_TASKS to also filter out issues with a milestone by adding a
condition like select(.milestone == null) (or select(.milestone | not)) to the
--jq expression so only issues without a milestone are returned; modify the
existing --jq '[.[] | select(.labels | map(.name) | any(. == "bug" or . ==
"idea" or . == "tech improvement"))]' in the command that assigns
NON_MILESTONE_TASKS to include the milestone check.
♻️ Duplicate comments (1)
.claude/commands/next-task.md (1)
7-13: Add the mandatory project overview step before task discovery.The workflow still starts with
list-tasks.sh, but the required sequence includes readingdocs/project/project-overview.mdfirst. Based on learnings, this step is mandatory before scanning PRDs.✅ Suggested update
-1. Run `./scripts/list-tasks.sh` to get tasks from all active PRD milestones -2. Read active PRD(s) from `docs/project/PRD/active/` -3. Parse each PRD's Parallelization section (Section 10) to identify tracks -4. Map tasks to tracks via deliverable refs in task body -5. Identify busy tracks (tasks with assignees) -6. Recommend task from idle track -7. Present recommendation with alternatives +1. Read `docs/project/project-overview.md` for current context +2. Run `./scripts/list-tasks.sh` to get tasks from all active PRD milestones +3. Read active PRD(s) from `docs/project/PRD/active/` +4. Parse each PRD's Parallelization section (Section 10) to identify tracks +5. Map tasks to tracks via deliverable refs in task body +6. Identify busy tracks (tasks with assignees) +7. Recommend task from idle track +8. Present recommendation with alternatives
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (2)
.claude/commands/next-task.mdscripts/list-tasks.sh
🧰 Additional context used
🧠 Learnings (14)
📓 Common learnings
Learnt from: NTCoding
Repo: NTCoding/living-architecture PR: 85
File: .claude/commands/post-merge-completion.md:35-39
Timestamp: 2026-01-09T18:10:15.724Z
Learning: In .claude/commands/post-merge-completion.md, the review files in `reviews/<branch>/` (code-review.md, bug-scanner.md, task-check.md, doc-suggestions.md) are optional inputs to the reflection process. The post-merge-completion command should work gracefully even if these files are missing or if /complete-task wasn't run before merging.
Learnt from: NTCoding
Repo: NTCoding/living-architecture PR: 120
File: docs/workflow/parallel-workflow.md:1-555
Timestamp: 2026-01-10T19:16:56.186Z
Learning: Investigation task documents (like `docs/workflow/parallel-workflow.md`) should focus on design and workflow specification rather than implementation concerns such as phased rollout plans, success metrics, and rollout risk mitigation. These operational details are addressed later when creating tasks to build the workflow.
Learnt from: CR
Repo: NTCoding/living-architecture PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-13T11:37:59.334Z
Learning: Follow docs/workflow/task-workflow.md from start to finish when working on any task. Do not make any changes or commit any code without following these steps exactly
Learnt from: CR
Repo: NTCoding/living-architecture PR: 0
File: packages/riviere-cli/CLAUDE.md:0-0
Timestamp: 2026-01-02T11:58:27.018Z
Learning: When modifying CLI commands in the riviere-cli tool, update the corresponding workflow prompts in docs/workflow/ directory (step-1 through step-6) to keep the extraction workflow in sync
📚 Learning: 2026-01-09T18:10:15.724Z
Learnt from: NTCoding
Repo: NTCoding/living-architecture PR: 85
File: .claude/commands/post-merge-completion.md:35-39
Timestamp: 2026-01-09T18:10:15.724Z
Learning: In .claude/commands/post-merge-completion.md, the review files in `reviews/<branch>/` (code-review.md, bug-scanner.md, task-check.md, doc-suggestions.md) are optional inputs to the reflection process. The post-merge-completion command should work gracefully even if these files are missing or if /complete-task wasn't run before merging.
Applied to files:
scripts/list-tasks.sh.claude/commands/next-task.md
📚 Learning: 2026-01-07T08:54:48.071Z
Learnt from: CR
Repo: NTCoding/living-architecture PR: 0
File: docs/workflow/code-review.md:0-0
Timestamp: 2026-01-07T08:54:48.071Z
Learning: Applies to docs/workflow/**/*.sh : In shell scripts (.sh files), use `jq` for JSON construction instead of manual string escaping to properly handle backslashes, newlines, and tabs.
Applied to files:
scripts/list-tasks.sh
📚 Learning: 2026-01-06T18:13:47.289Z
Learnt from: NTCoding
Repo: NTCoding/living-architecture PR: 58
File: scripts/reply-to-thread.sh:1-12
Timestamp: 2026-01-06T18:13:47.289Z
Learning: In shell scripts across the repository (e.g., scripts/reply-to-thread.sh), keep the code simple by not adding explicit preflight tool-availability checks for external commands (like gh or jq) when those tools would fail on first use anyway. Such checks add boilerplate without changing behavior. If you must guard against missing tools, prefer a minimal, early startup check or rely on the script failing naturally at the point of use.
Applied to files:
scripts/list-tasks.sh
📚 Learning: 2026-01-13T11:37:59.334Z
Learnt from: CR
Repo: NTCoding/living-architecture PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-13T11:37:59.334Z
Learning: When you encounter a command failure (script doesn't exist, tool errors, missing dependencies), stop and consult with user. When you encounter code quality issues (lint errors, unused dependencies, test failures, knip warnings), fix them directly
Applied to files:
scripts/list-tasks.sh
📚 Learning: 2026-01-13T11:37:59.334Z
Learnt from: CR
Repo: NTCoding/living-architecture PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-13T11:37:59.334Z
Learning: Always use scripts in `./scripts/` for git and GitHub operations (PRs, issues, tasks). Do not use `gh` or `git` commands directly unless no script exists
Applied to files:
scripts/list-tasks.sh
📚 Learning: 2026-01-06T18:02:51.422Z
Learnt from: NTCoding
Repo: NTCoding/living-architecture PR: 58
File: scripts/get-pr-feedback.sh:45-55
Timestamp: 2026-01-06T18:02:51.422Z
Learning: In shell scripts that call GraphQL APIs (e.g., scripts/get-pr-feedback.sh and similar), prefer using sed-based interpolation for GraphQL variables instead of gh api graphql's -f/-F flags. Rationale: sed-based interpolation is typically simpler and more robust in Bash contexts, avoids JSON encoding pitfalls, and keeps the script portable. Implement by building the GraphQL query as a string and substituting variables with sed or parameter expansion, ensuring proper escaping. If you must use -f/-F, provide clear justification in a comment.
Applied to files:
scripts/list-tasks.sh
📚 Learning: 2026-01-11T22:40:43.505Z
Learnt from: NTCoding
Repo: NTCoding/living-architecture PR: 132
File: scripts/submit-pr.sh:76-82
Timestamp: 2026-01-11T22:40:43.505Z
Learning: Shell scripts (any *.sh) can bypass agent tool invocation hooks if the hooks only monitor the direct command invoked by the interpreter. Ensure review checks account for commands executed inside scripts (e.g., git push inside submit-pr.sh). To reduce risk, either ensure hooks wrap or audit calls inside scripts, or refactor critical steps into explicit tool invocations exposed to the agent, or implement script-aware interception within the hook. For this repository, verify how scripts/submit-pr.sh calls tools and add guardrails if necessary.
Applied to files:
scripts/list-tasks.sh
📚 Learning: 2026-01-10T19:16:56.186Z
Learnt from: NTCoding
Repo: NTCoding/living-architecture PR: 120
File: docs/workflow/parallel-workflow.md:1-555
Timestamp: 2026-01-10T19:16:56.186Z
Learning: Investigation task documents (like `docs/workflow/parallel-workflow.md`) should focus on design and workflow specification rather than implementation concerns such as phased rollout plans, success metrics, and rollout risk mitigation. These operational details are addressed later when creating tasks to build the workflow.
Applied to files:
.claude/commands/next-task.md
📚 Learning: 2026-01-13T11:37:59.334Z
Learnt from: CR
Repo: NTCoding/living-architecture PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-13T11:37:59.334Z
Learning: Follow docs/workflow/task-workflow.md from start to finish when working on any task. Do not make any changes or commit any code without following these steps exactly
Applied to files:
.claude/commands/next-task.md
📚 Learning: 2026-01-02T11:58:27.018Z
Learnt from: CR
Repo: NTCoding/living-architecture PR: 0
File: packages/riviere-cli/CLAUDE.md:0-0
Timestamp: 2026-01-02T11:58:27.018Z
Learning: When modifying CLI commands in the riviere-cli tool, update the corresponding workflow prompts in docs/workflow/ directory (step-1 through step-6) to keep the extraction workflow in sync
Applied to files:
.claude/commands/next-task.md
📚 Learning: 2026-01-13T11:37:59.334Z
Learnt from: CR
Repo: NTCoding/living-architecture PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-13T11:37:59.334Z
Learning: Read `docs/project/project-overview.md` before work and check `docs/project/PRD/active/*.md` for current PRD
Applied to files:
.claude/commands/next-task.md
📚 Learning: 2026-01-07T08:54:48.071Z
Learnt from: CR
Repo: NTCoding/living-architecture PR: 0
File: docs/workflow/code-review.md:0-0
Timestamp: 2026-01-07T08:54:48.071Z
Learning: Applies to docs/workflow/**/*.{ts,tsx,js,jsx} : Review usage of `/* v8 ignore next -- preserve */` coverage skip directives. This is only acceptable for unreachable code needed to satisfy the compiler. Most cases should be solved by extracting code or writing tests to mock behavior.
Applied to files:
.claude/commands/next-task.md
📚 Learning: 2026-01-10T19:16:48.557Z
Learnt from: NTCoding
Repo: NTCoding/living-architecture PR: 120
File: docs/workflow/parallel-workflow.md:160-281
Timestamp: 2026-01-10T19:16:48.557Z
Learning: In the NTCoding/living-architecture repository, design and investigation documents (such as those in docs/workflow/) can reference scripts, commands, or features that don't yet exist in the codebase. These references serve as specifications for future implementation tasks, not documentation of current capabilities. This is acceptable when the PR scope is research/design rather than implementation.
Applied to files:
.claude/commands/next-task.md
🔇 Additional comments (6)
.claude/commands/next-task.md (2)
17-56: Clear mapping guidance and recommendation format.The deliverable mapping examples and the structured recommendation output are concise and actionable.
58-69: Edge-case coverage is strong.The missing PRD directory scenario and fallback behavior are explicitly documented and align with the new workflow.
scripts/list-tasks.sh (4)
10-46: Argument parsing and usage messaging look solid.Clear exclusivity guard and helpful usage output.
48-63: Backward-compatible label-only output is preserved.User-facing label display is a nice touch.
65-93: PRD discovery and milestone aggregation are straightforward.The JSON merging with
jq -s 'add'keeps the output consistent.
101-105: Combined JSON output is well-formed.The single object output aligns with the new /next-task workflow.
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
Prevents duplication when an issue has both a milestone and a bug/idea/tech label. Co-Authored-By: Claude Opus 4.5 <[email protected]>
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@scripts/list-tasks.sh`:
- Around line 95-106: NON_MILESTONE_TASKS currently includes a milestone:null
field for every entry; remove it by changing the jq selection that builds
NON_MILESTONE_TASKS (the gh issue list ... --jq '[.[] | select(.milestone ==
null) | select(...) ]' invocation) to delete the milestone key for each object
(e.g., map(del(.milestone))) so NON_MILESTONE_TASKS contains objects without the
milestone property, and ensure the final jq output that combines
$MILESTONE_TASKS and $NON_MILESTONE_TASKS remains unchanged.
♻️ Duplicate comments (1)
scripts/list-tasks.sh (1)
91-92: Consider usingjq -nwith--argjsonfor JSON merging.The current approach works but relies on echo to pass two JSON arrays to stdin. Using
jq -nwith explicit arguments is more explicit and avoids potential issues if either variable contains unexpected content.♻️ Optional refactor
# Merge into milestone_tasks array - MILESTONE_TASKS=$(echo "$MILESTONE_TASKS" "$TASKS" | jq -s 'add') + MILESTONE_TASKS=$(jq -n --argjson arr1 "$MILESTONE_TASKS" --argjson arr2 "$TASKS" '$arr1 + $arr2')Based on learnings, using
jqfor JSON construction is the recommended approach for this repository.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
scripts/list-tasks.sh
🧰 Additional context used
🧠 Learnings (11)
📓 Common learnings
Learnt from: NTCoding
Repo: NTCoding/living-architecture PR: 120
File: docs/workflow/parallel-workflow.md:1-555
Timestamp: 2026-01-10T19:16:56.186Z
Learning: Investigation task documents (like `docs/workflow/parallel-workflow.md`) should focus on design and workflow specification rather than implementation concerns such as phased rollout plans, success metrics, and rollout risk mitigation. These operational details are addressed later when creating tasks to build the workflow.
Learnt from: CR
Repo: NTCoding/living-architecture PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-13T11:37:59.334Z
Learning: Follow docs/workflow/task-workflow.md from start to finish when working on any task. Do not make any changes or commit any code without following these steps exactly
Learnt from: CR
Repo: NTCoding/living-architecture PR: 0
File: packages/riviere-cli/CLAUDE.md:0-0
Timestamp: 2026-01-02T11:58:27.018Z
Learning: When modifying CLI commands in the riviere-cli tool, update the corresponding workflow prompts in docs/workflow/ directory (step-1 through step-6) to keep the extraction workflow in sync
📚 Learning: 2026-01-09T18:10:15.724Z
Learnt from: NTCoding
Repo: NTCoding/living-architecture PR: 85
File: .claude/commands/post-merge-completion.md:35-39
Timestamp: 2026-01-09T18:10:15.724Z
Learning: In .claude/commands/post-merge-completion.md, the review files in `reviews/<branch>/` (code-review.md, bug-scanner.md, task-check.md, doc-suggestions.md) are optional inputs to the reflection process. The post-merge-completion command should work gracefully even if these files are missing or if /complete-task wasn't run before merging.
Applied to files:
scripts/list-tasks.sh
📚 Learning: 2026-01-07T08:54:48.071Z
Learnt from: CR
Repo: NTCoding/living-architecture PR: 0
File: docs/workflow/code-review.md:0-0
Timestamp: 2026-01-07T08:54:48.071Z
Learning: Applies to docs/workflow/**/*.sh : In shell scripts (.sh files), use `jq` for JSON construction instead of manual string escaping to properly handle backslashes, newlines, and tabs.
Applied to files:
scripts/list-tasks.sh
📚 Learning: 2026-01-06T18:13:47.289Z
Learnt from: NTCoding
Repo: NTCoding/living-architecture PR: 58
File: scripts/reply-to-thread.sh:1-12
Timestamp: 2026-01-06T18:13:47.289Z
Learning: In shell scripts across the repository (e.g., scripts/reply-to-thread.sh), keep the code simple by not adding explicit preflight tool-availability checks for external commands (like gh or jq) when those tools would fail on first use anyway. Such checks add boilerplate without changing behavior. If you must guard against missing tools, prefer a minimal, early startup check or rely on the script failing naturally at the point of use.
Applied to files:
scripts/list-tasks.sh
📚 Learning: 2026-01-13T11:37:59.334Z
Learnt from: CR
Repo: NTCoding/living-architecture PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-13T11:37:59.334Z
Learning: When you encounter a command failure (script doesn't exist, tool errors, missing dependencies), stop and consult with user. When you encounter code quality issues (lint errors, unused dependencies, test failures, knip warnings), fix them directly
Applied to files:
scripts/list-tasks.sh
📚 Learning: 2026-01-13T11:37:59.334Z
Learnt from: CR
Repo: NTCoding/living-architecture PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-13T11:37:59.334Z
Learning: Always use scripts in `./scripts/` for git and GitHub operations (PRs, issues, tasks). Do not use `gh` or `git` commands directly unless no script exists
Applied to files:
scripts/list-tasks.sh
📚 Learning: 2026-01-06T18:02:51.422Z
Learnt from: NTCoding
Repo: NTCoding/living-architecture PR: 58
File: scripts/get-pr-feedback.sh:45-55
Timestamp: 2026-01-06T18:02:51.422Z
Learning: In shell scripts that call GraphQL APIs (e.g., scripts/get-pr-feedback.sh and similar), prefer using sed-based interpolation for GraphQL variables instead of gh api graphql's -f/-F flags. Rationale: sed-based interpolation is typically simpler and more robust in Bash contexts, avoids JSON encoding pitfalls, and keeps the script portable. Implement by building the GraphQL query as a string and substituting variables with sed or parameter expansion, ensuring proper escaping. If you must use -f/-F, provide clear justification in a comment.
Applied to files:
scripts/list-tasks.sh
📚 Learning: 2026-01-13T11:37:59.334Z
Learnt from: CR
Repo: NTCoding/living-architecture PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-13T11:37:59.334Z
Learning: Read `docs/project/project-overview.md` before work and check `docs/project/PRD/active/*.md` for current PRD
Applied to files:
scripts/list-tasks.sh
📚 Learning: 2026-01-10T19:16:48.557Z
Learnt from: NTCoding
Repo: NTCoding/living-architecture PR: 120
File: docs/workflow/parallel-workflow.md:160-281
Timestamp: 2026-01-10T19:16:48.557Z
Learning: In the NTCoding/living-architecture repository, design and investigation documents (such as those in docs/workflow/) can reference scripts, commands, or features that don't yet exist in the codebase. These references serve as specifications for future implementation tasks, not documentation of current capabilities. This is acceptable when the PR scope is research/design rather than implementation.
Applied to files:
scripts/list-tasks.sh
📚 Learning: 2026-01-07T08:54:48.071Z
Learnt from: CR
Repo: NTCoding/living-architecture PR: 0
File: docs/workflow/code-review.md:0-0
Timestamp: 2026-01-07T08:54:48.071Z
Learning: Applies to docs/workflow/**/*.{ts,tsx,js,jsx} : Review usage of `/* v8 ignore next -- preserve */` coverage skip directives. This is only acceptable for unreachable code needed to satisfy the compiler. Most cases should be solved by extracting code or writing tests to mock behavior.
Applied to files:
scripts/list-tasks.sh
📚 Learning: 2026-01-11T22:40:43.505Z
Learnt from: NTCoding
Repo: NTCoding/living-architecture PR: 132
File: scripts/submit-pr.sh:76-82
Timestamp: 2026-01-11T22:40:43.505Z
Learning: Shell scripts (any *.sh) can bypass agent tool invocation hooks if the hooks only monitor the direct command invoked by the interpreter. Ensure review checks account for commands executed inside scripts (e.g., git push inside submit-pr.sh). To reduce risk, either ensure hooks wrap or audit calls inside scripts, or refactor critical steps into explicit tool invocations exposed to the agent, or implement script-aware interception within the hook. For this repository, verify how scripts/submit-pr.sh calls tools and add guardrails if necessary.
Applied to files:
scripts/list-tasks.sh
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Cloudflare Pages
🔇 Additional comments (4)
scripts/list-tasks.sh (4)
1-9: LGTM!Header comments clearly document the dual-mode behavior (JSON default vs. label-filtered output), and
set -euo pipefailensures proper error handling.
13-46: LGTM!The
check_exclusivefunction correctly enforces mutual exclusivity of the label flags, and the argument parsing loop is well-structured with clear error messaging.
48-63: Verify intentional behavior difference between modes.The backward-compatible mode (lines 61) filters for unassigned issues only (
--assignee ""), while the JSON mode (lines 88-89, 97-100) returns all issues regardless of assignment status. If this asymmetry is intentional for the/next-taskcommand to see all issues while legacy usage shows only available work, consider adding a comment to clarify this design choice.
65-70: LGTM!Proper error handling with JSON-formatted error message to stderr and non-zero exit status, enabling consuming scripts to detect and handle failures gracefully.
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
Owner
Author
|
@coderabbitai full review All feedback has been addressed:
Please re-review and update the review status. |
|
🧠 Learnings used✅ Actions performedFull review triggered. |
- Lead with track status summary (one line per track) - Show non-milestone counts (tech/bugs/ideas) - Concise recommendation at the end - Define clear status meanings: in progress, blocked, ready, idle Co-Authored-By: Claude Opus 4.5 <[email protected]>
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In @.claude/commands/next-task.md:
- Around line 17-23: The phrase "Look for deliverable references in task body"
is ambiguous; update the instruction to explicitly state which fields to search
(e.g., "search the task title, task description/body, and labels for deliverable
references such as `PRD Section: M2.3`, `Traceability: M2-D3`, `Deliverable:
D3.1`, `Research-R1`, and section numbers like `3.4` or `D2.5`") and note
whether comments or attachments are excluded or included to avoid ambiguity.
- Line 88: The doc is inconsistent: the "Unmapped Tasks" edge-case mentioned on
line 88 isn't shown in the "Output Format" example; either add an "Unmapped
Tasks" example block to the Output Format section (so the example demonstrates
how to render tasks that don't map to any track) or update the line that
references "Unmapped Tasks" to match the current Output Format; look for the
phrases "Unmapped Tasks" and "Output Format" in next-task.md and either append a
short example after the existing example block or reword the edge-case line to
align with the shown format.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
.claude/commands/next-task.md
🧰 Additional context used
🧠 Learnings (11)
📓 Common learnings
Learnt from: NTCoding
Repo: NTCoding/living-architecture PR: 85
File: .claude/commands/post-merge-completion.md:35-39
Timestamp: 2026-01-09T18:10:15.724Z
Learning: In .claude/commands/post-merge-completion.md, the review files in `reviews/<branch>/` (code-review.md, bug-scanner.md, task-check.md, doc-suggestions.md) are optional inputs to the reflection process. The post-merge-completion command should work gracefully even if these files are missing or if /complete-task wasn't run before merging.
Learnt from: NTCoding
Repo: NTCoding/living-architecture PR: 120
File: docs/workflow/parallel-workflow.md:1-555
Timestamp: 2026-01-10T19:16:56.186Z
Learning: Investigation task documents (like `docs/workflow/parallel-workflow.md`) should focus on design and workflow specification rather than implementation concerns such as phased rollout plans, success metrics, and rollout risk mitigation. These operational details are addressed later when creating tasks to build the workflow.
Learnt from: CR
Repo: NTCoding/living-architecture PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-13T11:37:59.334Z
Learning: Follow docs/workflow/task-workflow.md from start to finish when working on any task. Do not make any changes or commit any code without following these steps exactly
Learnt from: CR
Repo: NTCoding/living-architecture PR: 0
File: packages/riviere-cli/CLAUDE.md:0-0
Timestamp: 2026-01-02T11:58:27.018Z
Learning: When modifying CLI commands in the riviere-cli tool, update the corresponding workflow prompts in docs/workflow/ directory (step-1 through step-6) to keep the extraction workflow in sync
📚 Learning: 2026-01-09T18:10:15.724Z
Learnt from: NTCoding
Repo: NTCoding/living-architecture PR: 85
File: .claude/commands/post-merge-completion.md:35-39
Timestamp: 2026-01-09T18:10:15.724Z
Learning: In .claude/commands/post-merge-completion.md, the review files in `reviews/<branch>/` (code-review.md, bug-scanner.md, task-check.md, doc-suggestions.md) are optional inputs to the reflection process. The post-merge-completion command should work gracefully even if these files are missing or if /complete-task wasn't run before merging.
Applied to files:
.claude/commands/next-task.md
📚 Learning: 2026-01-10T19:16:56.186Z
Learnt from: NTCoding
Repo: NTCoding/living-architecture PR: 120
File: docs/workflow/parallel-workflow.md:1-555
Timestamp: 2026-01-10T19:16:56.186Z
Learning: Investigation task documents (like `docs/workflow/parallel-workflow.md`) should focus on design and workflow specification rather than implementation concerns such as phased rollout plans, success metrics, and rollout risk mitigation. These operational details are addressed later when creating tasks to build the workflow.
Applied to files:
.claude/commands/next-task.md
📚 Learning: 2026-01-13T11:37:59.334Z
Learnt from: CR
Repo: NTCoding/living-architecture PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-13T11:37:59.334Z
Learning: Follow docs/workflow/task-workflow.md from start to finish when working on any task. Do not make any changes or commit any code without following these steps exactly
Applied to files:
.claude/commands/next-task.md
📚 Learning: 2026-01-13T11:37:59.334Z
Learnt from: CR
Repo: NTCoding/living-architecture PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-13T11:37:59.334Z
Learning: Read `docs/project/project-overview.md` before work and check `docs/project/PRD/active/*.md` for current PRD
Applied to files:
.claude/commands/next-task.md
📚 Learning: 2026-01-07T08:54:48.071Z
Learnt from: CR
Repo: NTCoding/living-architecture PR: 0
File: docs/workflow/code-review.md:0-0
Timestamp: 2026-01-07T08:54:48.071Z
Learning: Applies to docs/workflow/**/*.{ts,tsx,js,jsx} : Review usage of `/* v8 ignore next -- preserve */` coverage skip directives. This is only acceptable for unreachable code needed to satisfy the compiler. Most cases should be solved by extracting code or writing tests to mock behavior.
Applied to files:
.claude/commands/next-task.md
📚 Learning: 2026-01-02T11:58:27.018Z
Learnt from: CR
Repo: NTCoding/living-architecture PR: 0
File: packages/riviere-cli/CLAUDE.md:0-0
Timestamp: 2026-01-02T11:58:27.018Z
Learning: When modifying CLI commands in the riviere-cli tool, update the corresponding workflow prompts in docs/workflow/ directory (step-1 through step-6) to keep the extraction workflow in sync
Applied to files:
.claude/commands/next-task.md
📚 Learning: 2026-01-10T19:16:48.557Z
Learnt from: NTCoding
Repo: NTCoding/living-architecture PR: 120
File: docs/workflow/parallel-workflow.md:160-281
Timestamp: 2026-01-10T19:16:48.557Z
Learning: In the NTCoding/living-architecture repository, design and investigation documents (such as those in docs/workflow/) can reference scripts, commands, or features that don't yet exist in the codebase. These references serve as specifications for future implementation tasks, not documentation of current capabilities. This is acceptable when the PR scope is research/design rather than implementation.
Applied to files:
.claude/commands/next-task.md
📚 Learning: 2026-01-07T08:54:48.071Z
Learnt from: CR
Repo: NTCoding/living-architecture PR: 0
File: docs/workflow/code-review.md:0-0
Timestamp: 2026-01-07T08:54:48.071Z
Learning: Applies to docs/workflow/**/*.{ts,tsx,js,jsx,!(**/*.test.ts,**/*.test.tsx,**/*.test.js,**/*.spec.ts,**/*.spec.tsx,**/*.spec.js)} : All production code (not test files) must align with architecture boundaries and layering requirements as defined in `@/docs/architecture/overview.md` and `@/docs/conventions/codebase-structure.md`
Applied to files:
.claude/commands/next-task.md
📚 Learning: 2026-01-07T08:54:48.071Z
Learnt from: CR
Repo: NTCoding/living-architecture PR: 0
File: docs/workflow/code-review.md:0-0
Timestamp: 2026-01-07T08:54:48.071Z
Learning: Applies to docs/workflow/**/*.{ts,tsx,js,jsx,!(**/*.test.ts,**/*.test.tsx,**/*.test.js,**/*.spec.ts,**/*.spec.tsx,**/*.spec.js)} : All production code must comply with coding standards and design principles as defined in `@/docs/conventions/software-design.md` and `@/docs/conventions/standard-patterns.md`
Applied to files:
.claude/commands/next-task.md
📚 Learning: 2026-01-13T11:37:59.334Z
Learnt from: CR
Repo: NTCoding/living-architecture PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-13T11:37:59.334Z
Learning: Applies to **/*.{ts,tsx} : Follow `docs/conventions/software-design.md` when writing, editing, refactoring, or reviewing code
Applied to files:
.claude/commands/next-task.md
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: Analyze
- GitHub Check: Cloudflare Pages
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
Comment on lines
+17
to
+23
| Look for deliverable references in task body: | ||
|
|
||
| - `PRD Section: M2.3` or `Traceability: M2-D3` - Milestone and deliverable reference | ||
| - `Deliverable: D3.1` - Deliverable reference | ||
| - `Research-R1` or `PRD Section: Research-R1` - Research track | ||
| - Section numbers like `3.4`, `D2.5` - Match to PRD deliverable numbering | ||
|
|
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Consider clarifying the scope of "task body" for deliverable references.
The instructions say to "Look for deliverable references in task body" but don't specify whether that includes the task title, description, labels, or all of the above. While the examples are clear, explicitly stating the search scope would reduce ambiguity.
📝 Optional clarification
-Look for deliverable references in task body:
+Look for deliverable references in the task (title, description, or labels):📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| Look for deliverable references in task body: | |
| - `PRD Section: M2.3` or `Traceability: M2-D3` - Milestone and deliverable reference | |
| - `Deliverable: D3.1` - Deliverable reference | |
| - `Research-R1` or `PRD Section: Research-R1` - Research track | |
| - Section numbers like `3.4`, `D2.5` - Match to PRD deliverable numbering | |
| Look for deliverable references in the task (title, description, or labels): | |
| - `PRD Section: M2.3` or `Traceability: M2-D3` - Milestone and deliverable reference | |
| - `Deliverable: D3.1` - Deliverable reference | |
| - `Research-R1` or `PRD Section: Research-R1` - Research track | |
| - Section numbers like `3.4`, `D2.5` - Match to PRD deliverable numbering |
🤖 Prompt for AI Agents
In @.claude/commands/next-task.md around lines 17 - 23, The phrase "Look for
deliverable references in task body" is ambiguous; update the instruction to
explicitly state which fields to search (e.g., "search the task title, task
description/body, and labels for deliverable references such as `PRD Section:
M2.3`, `Traceability: M2-D3`, `Deliverable: D3.1`, `Research-R1`, and section
numbers like `3.4` or `D2.5`") and note whether comments or attachments are
excluded or included to avoid ambiguity.
Owner
Author
There was a problem hiding this comment.
Not fixing: The instruction is clear enough - 'task body' refers to the GitHub issue body which is where deliverable references are placed. Over-specifying would add unnecessary verbosity.
🤖 This is an automated response from Claude Code. The repository owner did not write this message.
There was a problem hiding this comment.
@NTCoding, understood! You're right that "task body" is a well-understood term in the GitHub context. I appreciate the clarification on your preference for conciseness here.
🧠 Learnings used
Learnt from: CR
Repo: NTCoding/living-architecture PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-13T11:37:59.334Z
Learning: Follow docs/workflow/task-workflow.md from start to finish when working on any task. Do not make any changes or commit any code without following these steps exactly
Learnt from: NTCoding
Repo: NTCoding/living-architecture PR: 120
File: docs/workflow/parallel-workflow.md:1-555
Timestamp: 2026-01-10T19:16:56.186Z
Learning: Investigation task documents (like `docs/workflow/parallel-workflow.md`) should focus on design and workflow specification rather than implementation concerns such as phased rollout plans, success metrics, and rollout risk mitigation. These operational details are addressed later when creating tasks to build the workflow.
Learnt from: NTCoding
Repo: NTCoding/living-architecture PR: 85
File: .claude/commands/post-merge-completion.md:35-39
Timestamp: 2026-01-09T18:10:15.724Z
Learning: In .claude/commands/post-merge-completion.md, the review files in `reviews/<branch>/` (code-review.md, bug-scanner.md, task-check.md, doc-suggestions.md) are optional inputs to the reflection process. The post-merge-completion command should work gracefully even if these files are missing or if /complete-task wasn't run before merging.
Learnt from: CR
Repo: NTCoding/living-architecture PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-13T11:37:59.334Z
Learning: Read `docs/project/project-overview.md` before work and check `docs/project/PRD/active/*.md` for current PRD
Learnt from: NTCoding
Repo: NTCoding/living-architecture PR: 120
File: docs/workflow/parallel-workflow.md:160-281
Timestamp: 2026-01-10T19:16:48.557Z
Learning: In the NTCoding/living-architecture repository, design and investigation documents (such as those in docs/workflow/) can reference scripts, commands, or features that don't yet exist in the codebase. These references serve as specifications for future implementation tasks, not documentation of current capabilities. This is acceptable when the PR scope is research/design rather than implementation.
| - **PRD without Parallelization section**: List unassigned tasks sequentially (first available) | ||
| - **All tracks busy**: Recommend non-milestone task (bugs/tech/ideas) first | ||
| - **No tasks available**: Report "No unassigned tasks available" | ||
| - **Task doesn't map to any track**: Include in "Unmapped Tasks" section |
There was a problem hiding this comment.
Inconsistency: "Unmapped Tasks" section not shown in Output Format.
Line 88 states that tasks that don't map to any track should be included in an "Unmapped Tasks" section, but the Output Format example (lines 34-73) does not demonstrate this section.
🔧 Proposed fix
Either add an "Unmapped Tasks" example to the Output Format section (after line 73), or revise line 88 to align with the existing format. For example:
Option 1: Add to Output Format (after line 62)
Track: Ideas
Status: none
Issue: —
────────────────────────────────────────
+Track: Unmapped Tasks
+Status: 1 available
+Issue: `#175`
+────────────────────────────────────────Option 2: Revise Edge Case description (line 88)
-- **Task doesn't map to any track**: Include in "Unmapped Tasks" section
+- **Task doesn't map to any track**: List in the "Available tracks" section with "(unmapped)" suffix📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| - **Task doesn't map to any track**: Include in "Unmapped Tasks" section | |
| - **PRD without Parallelization section**: Omit from track analysis, list tasks separately | |
| - **All tracks busy**: Report "All tracks busy" in output; include Task Recommendations section | |
| - **No tasks available**: Report "No unassigned tasks available" | |
| - **Task doesn't map to any track**: List in the "Available tracks" section with "(unmapped)" suffix | |
| - **Multiple active PRDs**: Run analysis for each and consolidate tracks by name | |
| - **No active PRD directory**: Report the active PRD directory is missing/empty and skip track analysis |
🤖 Prompt for AI Agents
In @.claude/commands/next-task.md at line 88, The doc is inconsistent: the
"Unmapped Tasks" edge-case mentioned on line 88 isn't shown in the "Output
Format" example; either add an "Unmapped Tasks" example block to the Output
Format section (so the example demonstrates how to render tasks that don't map
to any track) or update the line that references "Unmapped Tasks" to match the
current Output Format; look for the phrases "Unmapped Tasks" and "Output Format"
in next-task.md and either append a short example after the existing example
block or reword the edge-case line to align with the shown format.
Owner
Author
There was a problem hiding this comment.
Not fixing: Removing 'Unmapped Tasks' from edge cases - it's not needed with the new track ID format (PRD12-A). Tasks are mapped via deliverable refs in body.
🤖 This is an automated response from Claude Code. The repository owner did not write this message.
There was a problem hiding this comment.
@NTCoding, understood. Since tasks are mapped via deliverable references in the task body with the new track ID format, the "Unmapped Tasks" edge case isn't applicable. Thank you for clarifying.
🧠 Learnings used
Learnt from: CR
Repo: NTCoding/living-architecture PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-13T11:37:59.334Z
Learning: Follow docs/workflow/task-workflow.md from start to finish when working on any task. Do not make any changes or commit any code without following these steps exactly
Learnt from: NTCoding
Repo: NTCoding/living-architecture PR: 120
File: docs/workflow/parallel-workflow.md:1-555
Timestamp: 2026-01-10T19:16:56.186Z
Learning: Investigation task documents (like `docs/workflow/parallel-workflow.md`) should focus on design and workflow specification rather than implementation concerns such as phased rollout plans, success metrics, and rollout risk mitigation. These operational details are addressed later when creating tasks to build the workflow.
Learnt from: NTCoding
Repo: NTCoding/living-architecture PR: 85
File: .claude/commands/post-merge-completion.md:35-39
Timestamp: 2026-01-09T18:10:15.724Z
Learning: In .claude/commands/post-merge-completion.md, the review files in `reviews/<branch>/` (code-review.md, bug-scanner.md, task-check.md, doc-suggestions.md) are optional inputs to the reflection process. The post-merge-completion command should work gracefully even if these files are missing or if /complete-task wasn't run before merging.
Learnt from: CR
Repo: NTCoding/living-architecture PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-13T11:37:59.334Z
Learning: Read `docs/project/project-overview.md` before work and check `docs/project/PRD/active/*.md` for current PRD
Learnt from: NTCoding
Repo: NTCoding/living-architecture PR: 120
File: docs/workflow/parallel-workflow.md:160-281
Timestamp: 2026-01-10T19:16:48.557Z
Learning: In the NTCoding/living-architecture repository, design and investigation documents (such as those in docs/workflow/) can reference scripts, commands, or features that don't yet exist in the codebase. These references serve as specifications for future implementation tasks, not documentation of current capabilities. This is acceptable when the PR scope is research/design rather than implementation.
No longer needed with PRD-prefixed track IDs. Co-Authored-By: Claude Opus 4.5 <[email protected]>
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #179
Summary
/next-taskslash command for parallel-aware task recommendationslist-tasks.shto query all active PRD milestones and output JSONChanges
New
/next-taskcommand (.claude/commands/next-task.md)Updated
list-tasks.shUpdated
task-workflow.mdCloses #179
Summary by CodeRabbit
Documentation
New Features
Reliability
✏️ Tip: You can customize this high-level summary in your review settings.