feat: add change-request skill#122
Open
tigra wants to merge 2 commits into
Open
Conversation
Adds an opt-in /awos:change-request command that captures *why* a previously-agreed requirement changed (trigger, driver, business-level impact) and saves a numbered record under context/change-requests/. - commands/change-request.md + claude/commands/change-request.md wrapper - templates/change-request-template.md - integration hooks: product.md, roadmap.md (offer a CR before writing the artifact) and spec.md (offer a CR when a new spec revises a prior requirement). All hooks are opt-in — the skill opens with a skip option, so existing flows are unchanged unless the user opts in.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughAdds an opt-in Change Request Analyst command, a structured change-request template, and optional prompts to product, roadmap, and spec workflows to log requirement changes with interview, impact mapping, and filesystem persistence. ChangesChange Request Workflow and Integration
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
commands/change-request.md (1)
45-46: ⚡ Quick winConsider breaking the business-value principle into sub-bullets.
The principle at line 45 spans multiple concerns (stay at business level, no technical detail, exception for architecture) in a single dense paragraph. Breaking it into a main bullet with sub-bullets would improve scannability:
-- **Stay at the business-value level; no technical implementation detail in the CR.** A change request records _why_ a previously-agreed requirement is changing and _what business capability_ moves as a result — not how the code will be reorganised. Do not name source files, function signatures, interface seams, test files, flag names, module boundaries, or step-by-step refactoring plans in any section of the CR. Those belong in the technical-considerations doc and tasks list that follow. Stop at the level of "capability X is added / replaced / withdrawn", "artifact Y is rescoped", "previously-completed work Z remains valid as the local-mode baseline". - - **Exception — when architecture _is_ the business matter.** If the product's stated purpose is to _demonstrate certain architectural patterns_ (e.g., a reference / training / capability-showcase project), then naming those patterns at a high level _is_ the business statement and belongs in the CR. Even then, name the pattern (e.g., "OAuth2 as the authentication model") rather than the implementation (e.g., "extract a `TokenStore` interface from the session module"). Resist the urge to descend into implementation just because architecture is in scope. +- **Stay at the business-value level; no technical implementation detail in the CR.** + - A change request records _why_ a previously-agreed requirement is changing and _what business capability_ moves as a result — not how the code will be reorganised. + - Do not name source files, function signatures, interface seams, test files, flag names, module boundaries, or step-by-step refactoring plans. + - Stop at the level of "capability X is added / replaced / withdrawn", "artifact Y is rescoped". + - **Exception:** If the product's stated purpose is to _demonstrate architectural patterns_ (e.g., reference/training project), naming those patterns at a high level _is_ the business statement. Even then, name the pattern (e.g., "OAuth2 authentication") rather than implementation (e.g., "extract a `TokenStore` interface").🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@commands/change-request.md` around lines 45 - 46, Split the long "Stay at the business-value level; no technical implementation detail in the CR." bullet into a main bullet and 2–3 sub-bullets: one sub-bullet stating "Record why requirements change and which business capability is added/replaced/withdrawn" (examples: "capability X is added / replaced / withdrawn"), a second sub-bullet explicitly forbidding naming implementation artifacts (source files, function signatures, tests, flags, module boundaries, refactoring steps), and a separate sub-bullet for the exception: move the existing "Exception — when architecture _is_ the business matter." sentence into its own sub-bullet and reword it to focus on naming architectural patterns (e.g., "OAuth2 as the authentication model") rather than implementation details; keep the example sentence about naming patterns vs. implementation but remove any procedural phrasing.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@templates/change-request-template.md`:
- Line 47: The template heading "**Could this have been anticipated earlier?**"
is presented as a required bracketed field but should match the command spec in
commands/change-request.md which describes it as "Optional, lightweight —
captures lessons"; update the template so the field is explicitly optional
(e.g., change the bracketed text to "[optional — captures lessons]") or
alternatively append guidance such as "[optional; leave empty if not
applicable]" to that same heading to make the intent clear and consistent with
the spec.
---
Nitpick comments:
In `@commands/change-request.md`:
- Around line 45-46: Split the long "Stay at the business-value level; no
technical implementation detail in the CR." bullet into a main bullet and 2–3
sub-bullets: one sub-bullet stating "Record why requirements change and which
business capability is added/replaced/withdrawn" (examples: "capability X is
added / replaced / withdrawn"), a second sub-bullet explicitly forbidding naming
implementation artifacts (source files, function signatures, tests, flags,
module boundaries, refactoring steps), and a separate sub-bullet for the
exception: move the existing "Exception — when architecture _is_ the business
matter." sentence into its own sub-bullet and reword it to focus on naming
architectural patterns (e.g., "OAuth2 as the authentication model") rather than
implementation details; keep the example sentence about naming patterns vs.
implementation but remove any procedural phrasing.
🪄 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 Plus
Run ID: f63d3767-f928-4d70-8fac-a168f195b197
📒 Files selected for processing (6)
claude/commands/change-request.mdcommands/change-request.mdcommands/product.mdcommands/roadmap.mdcommands/spec.mdtemplates/change-request-template.md
|
|
||
| **Detailed reasoning:** [free text — what specifically led here, in the author's own words; cite the trigger if there is one] | ||
|
|
||
| **Could this have been anticipated earlier?** [optional — captures lessons] |
There was a problem hiding this comment.
Mark optional field consistently with command spec.
Line 84 in commands/change-request.md describes this field as "Optional, lightweight — captures lessons," but the template presents it as a required [bracketed] field. Consider either:
- Making it optional in the template:
**Could this have been anticipated earlier?** [optional — captures lessons] - Or including guidance that it can be left empty:
[optional; leave empty if not applicable]
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@templates/change-request-template.md` at line 47, The template heading
"**Could this have been anticipated earlier?**" is presented as a required
bracketed field but should match the command spec in commands/change-request.md
which describes it as "Optional, lightweight — captures lessons"; update the
template so the field is explicitly optional (e.g., change the bracketed text to
"[optional — captures lessons]") or alternatively append guidance such as
"[optional; leave empty if not applicable]" to that same heading to make the
intent clear and consistent with the spec.
tigra
pushed a commit
to tigra/awos
that referenced
this pull request
Jun 1, 2026
Supersedes provectus#122–provectus#125. Following the architectural review in #proj_awos, the three skills ship as a plugin sibling to plugins/awos rather than modifying core commands — keeps the spec→tech→tasks→implement→verify pipeline lean and removes the perpetual upstream-merge conflict surface the prior branches created. Discoverability is bundled with the plugin: a UserPromptSubmit hook declared inline in plugin.json (bug #10225 workaround — hooks/hooks.json does not fire) matches 6 core AWOS phases plus the 3 plugin commands; the awos-next skill conditionally suggests a plugin command via free-text inspection of the just-completed phase's output, staying silent when uncertain. Test additions stay generic: one new Layer 1 assertion that every plugin SKILL.md has valid frontmatter, plus explicit hardcoded entries per plugin-contributed command in the /awos:<name> cross-reference test (independent ground truth, not SUT-derived). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
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.
What
Adds an opt-in
/awos:change-requestcommand that captures why a previously-agreed requirement changed — the trigger, the driver, and its business-level impact on already-implemented work — and saves a numbered record undercontext/change-requests/.Files
commands/change-request.md+claude/commands/change-request.mdwrappertemplates/change-request-template.mdcommands/product.md,commands/roadmap.md— offer a CR before writing the artifactcommands/spec.md— offer a CR when a new spec revises a prior requirementBackward compatibility
All hooks are opt-in: the skill opens with an
AskUserQuestionskip option, so existingproduct/roadmap/specflows are unchanged unless the user chooses to log a CR.Validation
npm test→ 69/69 pass (static prompt lint + installer + fixtures)npx prettier --check .cleanSuggested release-drafter label: minor (new feature skill).
Summary by CodeRabbit