Conversation
…erage Rewrote all 3 skill descriptions with action-oriented phrasing, concrete trigger examples, and clearer skill boundaries to improve auto-triggering accuracy. Added missing content sections: SRS Overview creation and change management workflow (spec-writer), incomplete spec handling with inline decomposition example and sprint capacity planning (requirement-decomposer), check modes (full/focused/quick) and common anti-patterns (traceability-checker). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 85cb0c74a0
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| When the user reports a requirement change or mentions that something needs to change in approved specs: | ||
| 1. Create a Change Request using `templates/software_spec/input_management/change_request.template.md` → `docs/spec/change_requests/CR-NNNN_<Title>.md` | ||
| 2. Suggest running `/impact-analysis <CR code>` to assess blast radius | ||
| 3. After CR approval, guide the user to `/apply-change` or `/phase-delta` for implementation |
There was a problem hiding this comment.
Route approved CR implementations through /apply-change
This step makes /phase-delta an alternative implementation path after CR approval, but the documented workflow requires /apply-change at implementation time (change_management_rules.md §1/§2). If users follow this guidance and run only /phase-delta, they create a delta file without applying the rest of the approved change set (story/sprint updates and end-to-end verification), which can leave a CR partially implemented while appearing complete.
Useful? React with 👍 / 👎.
| - Before presenting traceability to stakeholders | ||
|
|
||
| ### Focused Check (for a specific scope) | ||
| When the user specifies a scope (e.g., a single epic, spec, or directory), only scan the relevant artifacts and their direct references. Use when: |
There was a problem hiding this comment.
Remove unsupported directory scope from focused checks
This guidance says focused checks can target a directory, but /check-traceability only defines all, specs-only, delivery-only, or a single artifact code as valid scope values (commands/check-traceability.md argument docs and step 3). A user following this instruction with a directory path will not get the intended focused scan, leading to missed or misleading traceability results.
Useful? React with 👍 / 👎.
Summary
Test plan
🤖 Generated with Claude Code