request-tracking
Request Tracking Skill
Trigger
- Keywords: request document, request, progress tracking, status, acceptance criteria, tech spec
When NOT to Use
- Create new request document (use /create-request)
- Write tech spec (use /tech-spec)
- Code development (use feature-dev)
Document Hierarchy
requests/ Request documents (scope + acceptance)
↓ references
planning/ Tech specs (implementation details)
↓ references
adr/ Decision records (rationale)
↓ references
architecture/ Architecture docs (system design)
File Location
docs/features/{feature}/
├── requests/ # Active request documents
│ └── archived/ # Completed
├── planning/ # Tech specs
├── adr/ # Decision records
└── architecture/ # Architecture docs
Naming Convention
Format: YYYY-MM-DD-kebab-case-title.md
Status & Priority
| Status | Description |
|---|---|
| Pending | Not started |
| In Dev | In progress |
| Approved | Spec confirmed |
| Priority | Timeline |
|---|---|
| P0 | Immediate |
| P1 | This week |
| P2 | This iteration |
Output
## Request Status
| Request | Status | Priority | Updated |
|---------|--------|----------|---------|
| ... | ... | ... | ... |
Verification
- Request document includes: background, requirements, acceptance criteria
- File naming follows convention
- Correctly linked to tech spec
References
references/template.md- Request document templatereferences/operations.md- Operations guide
Examples
Input: How to write a request document?
Action: Explain template structure + reference references/template.md
Input: How to track progress for this request?
Action: Explain progress table / Phase breakdown approach
More from sd0xdev/sd0x-dev-flow
statusline-config
Customize Claude Code statusline. Use when: user says 'statusline', 'status line', 'customize statusline', 'modify statusline', 'statusline settings', 'statusline theme', 'change theme', 'color scheme', wants to add/remove/change segments (cost, git, model, context), switch color themes (catppuccin, dracula, nord), or asks what can be shown in the statusline.
52tech-spec
Tech spec generation and review. Use when: designing features, writing specs, spec review. Not for: requirements analysis (use req-analyze), implementation (use feature-dev), architecture advice (use codex-architect). Output: numbered tech spec document.
45codex-brainstorm
Adversarial brainstorming via Claude+Codex debate. Use when: exploring solutions, feasibility analysis, exhaustive enumeration. Not for: implementation (use feature-dev), architecture only (use codex-architect). Output: Nash equilibrium consensus + action items.
7security-review
Security review via Codex MCP. Use when: OWASP Top 10 audit, dependency vulnerability check, security-sensitive changes. Not for: code review (use codex-code-review), test review (use test-review). Output: security findings + audit report.
7test-review
Test coverage review via Codex MCP. Use when: reviewing test sufficiency, identifying coverage gaps, test quality audit. Not for: generating tests (use codex-test-gen), code review (use codex-code-review). Output: coverage analysis + gap report.
7post-dev-test
Post-development test completion. Use when: checking test coverage after feature-dev, writing missing integration/e2e tests. Not for: unit test generation (use codex-test-gen), test review (use test-review). Output: test files + coverage report.
6