skills/sdd-pr/SKILL.md
# sdd-pr — Create Pull Request ## Slash Command ``` /sdd-pr <slug> ``` ## Purpose Create a GitHub Pull Request enriched with SDD-specific content: a REQ → TASK → commit traceability table, review summary, and an acceptance-criteria-derived test plan checklist. Delegates the actual PR creation to the project's `git-pr` skill. --- ## Prerequisites - `sdd-review` has been run: `review.md` must contain a `## Code Review` section. - The feature branch must be pushed to the remote. - No unresol
npx skillsauth add sc30gsw/claude-code-customes skills/sdd-prInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
/sdd-pr <slug>
Create a GitHub Pull Request enriched with SDD-specific content: a REQ → TASK → commit traceability table, review summary, and an acceptance-criteria-derived test plan checklist. Delegates the actual PR creation to the project's git-pr skill.
sdd-review has been run: review.md must contain a ## Code Review section.review.md (see Warning below).| File | Purpose |
| -------------------------------------- | ----------------------------------------- |
| .claude/specs/<slug>/requirements.md | REQ definitions and acceptance criteria |
| .claude/specs/<slug>/tasks.md | TASK definitions with REQ references |
| .claude/specs/<slug>/design.md | Architecture summary for PR context |
| .claude/specs/<slug>/progress.md | Task completion status and mode setting |
| .claude/specs/<slug>/review.md | Review findings to surface in the PR body |
Both standard and auto modes produce the same PR content.
| Aspect | standard | auto |
| ------------------------ | -------------------------------------- | ------------------------------------- |
| Before creating PR | Show draft PR body, wait for CONFIRM | Create PR immediately |
| If CRITICAL issues exist | Stop and require user decision | Stop and require user decision (same) |
Read .claude/specs/<slug>/review.md. Search for unchecked CRITICAL findings:
### CRITICAL
- [ ] ... ← unchecked = still open
- [x] ... ← checked = resolved
If any unchecked CRITICAL findings exist under either ## Code Review or ## Security Review, output:
WARNING: Open CRITICAL issues found in review.md:
- [src/features/foo/api/mutations.ts:42] Description of issue
Resolve all CRITICAL issues before creating the PR.
After fixing, re-run /sdd-review <slug> to update review.md.
Stop. Do not proceed until the user explicitly confirms they want to continue (exceptional case only, e.g., known false positive).
Collect commits on the feature branch that reference task IDs:
git log main...HEAD --oneline --grep="TASK-"
Parse each ### TASK-xxx block in tasks.md for its linked REQ ID (look for REQ-xxx references in the task description or metadata).
Build the table:
| REQ | Description | Tasks | Key Commits |
| ---------- | ----------------------------------- | ------------------ | ---------------------------------------- |
| REQ-001 | User can log in with email/password | TASK-001, TASK-002 | feat(TASK-001): Create login schema |
| REQ-002 | Show validation errors inline | TASK-003 | feat(TASK-003): Add inline error display |
| (Untraced) | — | TASK-012 | feat(TASK-012): Fix loading state |
Tasks with no REQ reference appear in an (Untraced) row at the bottom.
Extract acceptance criteria from requirements.md. Each ### REQ-xxx section typically contains an "Acceptance Criteria" or "AC" subsection. Convert each criterion into a checklist item:
## Test Plan
- [ ] REQ-001: Login with valid credentials redirects to dashboard
- [ ] REQ-001: Login with wrong password shows "メールアドレスまたはパスワードが正しくありません"
- [ ] REQ-002: Empty email field shows inline validation error before submit
- [ ] REQ-002: Invalid email format triggers Valibot error message
- [ ] Regression: pnpm test:run passes (all existing tests green)
- [ ] Build: pnpm check passes (lint + format + tsc)
Review summary — extract from review.md:
## Review Summary
| Severity | Code Review | Security Review |
| -------- | ----------- | --------------- |
| CRITICAL | 0 open | 0 open |
| HIGH | 2 open | 1 open |
| MEDIUM | 3 open | 0 open |
> Outstanding HIGH issues (must resolve before merge):
>
> - [src/features/foo/components/foo-form.tsx:15] Using relative import path
> - [src/lib/api-client.ts:88] Missing input validation at boundary
Count open (unchecked - [ ]) vs resolved (checked - [x]) findings per severity.
Spec reference — link to all spec documents:
## Spec Reference
| Document | Path |
| ----------------------- | --------------------------------------- |
| Source (Notion archive) | `.claude/specs/<slug>/source-notion.md` |
| Requirements | `.claude/specs/<slug>/requirements.md` |
| Design | `.claude/specs/<slug>/design.md` |
| Tasks | `.claude/specs/<slug>/tasks.md` |
| Review | `.claude/specs/<slug>/review.md` |
| Progress | `.claude/specs/<slug>/progress.md` |
git-pr SkillPass the additional SDD context to the project's git-pr skill. The git-pr skill handles git push -u origin <branch> (if not yet pushed) and gh pr create.
The full PR body structure:
## Summary
<3-5 bullet points from git-pr — what changed and why>
## Spec Reference
<built in Step 4>
## Traceability
<built in Step 2>
## Review Summary
<built in Step 4>
## Test Plan
<built in Step 3>
🤖 Generated with [Claude Code](https://claude.com/claude-code)
If the git-pr skill is unavailable, fall back to running gh pr create directly:
gh pr create --title "<feature title>" --body "$(cat <<'EOF'
## Summary
...
EOF
)"
After the PR is created, append to .claude/specs/<slug>/progress.md:
## PR
- URL: https://github.com/enechange/e_value_management_frontend/pull/42
- Created: 2026-05-26
- Status: open
Date format: YYYY-MM-DD. This entry allows sdd-workflow to detect that the PR phase is complete.
| File | Change |
| ---------------------------------- | ----------------------------------------------- |
| .claude/specs/<slug>/progress.md | ## PR section appended with URL, date, status |
| GitHub | New PR created |
== PHASE COMPLETE: sdd-pr ==
Artifact: .claude/specs/<slug>/progress.md
Summary:
- PR created: https://github.com/enechange/e_value_management_frontend/pull/42
- Traceability table: 3 REQs traced across 12 TASKs and 12 commits
- Test plan: 8 checklist items derived from acceptance criteria
- Review summary: 0 CRITICAL, 3 HIGH open (surfaced in PR body for reviewers)
- PR URL recorded in progress.md
⏸ WAITING FOR CONFIRMATION
Type `CONFIRM sdd-workflow` to view final workflow status, or describe changes needed.
tools
Guide for creating effective skills. This skill should be used when users want to create a new skill (or update an existing skill) that extends Claude's capabilities with specialized knowledge, workflows, or tool integrations.
testing
# sdd-workflow — Workflow Status Dashboard ## Slash Command ``` /sdd-workflow [slug] ``` ## Purpose Read-only meta skill. Displays the current state of the SDD workflow — which phases are complete, which is next, and any blockers. Does NOT modify any files. --- ## This Skill is Read-Only `sdd-workflow` never writes to or modifies any file. It only reads spec files and git history to report status. There is no approval gate for this skill. --- ## Usage: Specific Feature ``` /sdd-workflo
content-media
# sdd-tasks **Slash command**: `/sdd-tasks <slug>` **Purpose**: Generate `tasks.md` (TASK-001..N) and `progress.md` from `requirements.md` and `design.md`. --- ## Prerequisites - `.claude/specs/<slug>/requirements.md` must exist - `.claude/specs/<slug>/design.md` must exist (run `/sdd-design` first) --- ## Steps ### 1. Read spec inputs ``` .claude/specs/<slug>/requirements.md .claude/specs/<slug>/design.md ``` Extract: - Every REQ-XXX ID with its acceptance criteria - Every design sect
development
# sdd-review — Post-Implementation Code Review ## Slash Command ``` /sdd-review <slug> ``` ## Purpose Run code review and security review on all changes introduced by the feature branch. Append structured findings to `review.md`. Does NOT auto-apply fixes — only proposes them. --- ## Prerequisites - `sdd-impl` has completed: all tasks in `progress.md` are `done` (or at least one is `done`; partial reviews are allowed). - The feature branch must have at least one commit ahead of `main`. -