RsDT

RsDT (Requirements, Specs, Design & Tasks) Instructions

Instructions for AI coding assistants using RsDT for specification-driven development.

IMPORTANT: All files generated by this skill (requirement-spec.md, design.md, tasks.md, ADRs, Design Docs) MUST be written in Japanese unless explicitly requested otherwise by the user.

TL;DR Quick Checklist

• Review existing work: Related codebase, existing features under RsDT/
• Decide <feature_name>: kebab-case, verb-led (add-, fix-, update-, refactor-)
• Deepen understanding: Codebase investigation, websearch, context7 MCP server, user questions
• Generate 3 files: requirement-spec.md, design.md, tasks.md (all in Japanese)
• Review drafts: Call rsdt-spec-reviewer sub-agent to verify compliance
• Implementation: Follow tasks.md order and check off upon completion

Workflow Overview

Stage 1: Draft - Requirements and Design Specification

Trigger Examples:

• "I want to add 〇〇 feature"
• "Fix this bug"
• "Create a refactoring plan"

Process:

1. Context Gathering
2. Read and understand related codebase
3. Check existing features under RsDT/ for duplicates or conflicts
4. If using external tools/libraries, check latest documentation via context7 MCP server
5. Use websearch for latest information as needed

1. Requirements Clarification
2. Assume user input may be memo-level quality
3. Identify unclear or ambiguous points
4. Read related code before asking questions to enable discussion
5. Use AskUserQuestion tool to clarify requirements

1. Feature Name Decision
2. kebab-case, verb-led naming
3. Examples: add-user-authentication, fix-login-bug, refactor-api-client
4. Create directory: RsDT/<feature_name>/

1. Generate 3 Files (in Japanese)
2. requirement-spec.md: Requirements and specifications
3. design.md: Design (as needed)
4. tasks.md: Task breakdown

1. Review Drafts (MANDATORY)
2. Call rsdt-spec-reviewer sub-agent using Task tool
3. Verify compliance with Design Philosophy and Important Reminders
4. Address any feedback before proceeding to Stage 2

Stage 2: Implementation - Build

Follow tasks while tracking with TodoWrite tool:

1. Read requirement-spec.md - Understand what to build
2. Read design.md - Understand how to build
3. Read tasks.md - Check implementation steps
4. Implement tasks sequentially - Follow tasks.md order
5. Confirm completion - Verify all tasks in tasks.md are finished
6. Update checklist - Mark all tasks as - [x] after completion

Stage 3: Archive - Post-Completion Cleanup

After implementation completion, organize as follows:

1. Delete tasks.md
2. Completed task list is no longer needed

1. Create ADRs (if needed)
2. Only if project manages ADRs (Architecture Decision Records)
3. Create individual ADRs for each architecture decision made
4. Check project's ADR policy and match existing format and file structure
5. Review existing ADRs to confirm naming conventions and location

1. Create Design Doc (if needed)
2. Only if content is worth keeping as specification documentation
3. Summarize requirements and design from requirement-spec.md and design.md
4. Place in appropriate project location (e.g., docs/design/, docs/specs/)

1. Delete Working Files
2. Delete requirement-spec.md
3. Delete design.md
4. Finally delete entire RsDT/<feature_name>/ directory

Directory Structure

RsDT/
└── <feature_name>/          # Work in progress (delete after completion)
    ├── requirement-spec.md  # Requirements and specs (Japanese)
    ├── design.md           # Design (optional, Japanese)
    └── tasks.md            # Task breakdown (Japanese)

Note: Directories under RsDT are temporary working directories. After implementation completion, create ADRs or Design Docs as needed, then delete the working directory.

File Format Guide

requirement-spec.md

IMPORTANT: Write this file in Japanese.

Include the following sections:

# <Feature Name>

## 背景・目的

[Why this feature is needed, what problem it solves]

## スコープ

### 実装すること
- [List of changes]
- [Mark BREAKING CHANGE with **BREAKING** if applicable]

### 実装しないこと
- [Explicitly list what's out of scope]

## 要件・仕様

### [Requirement Category] - ADDED/MODIFIED/REMOVED

#### 要件: [Requirement Name]

[Requirement description]

##### Scenario: [Scenario Name]
- **GIVEN** [Preconditions]
- **WHEN** [Actions/Events]
- **THEN** [Expected Results]

Or

##### Scenario: [Scenario Name]
- **Arrange** [Setup preconditions]
- **Act** [Execute actions]
- **Assert** [Verify results]

## 制約条件

- [Technical constraints]
- [Performance requirements]
- [Security requirements]
- [Other constraints]

Key Points:

• Each requirement must have at least one scenario
• Scenarios must use Given-When-Then or Arrange-Act-Assert format
• Explicitly mark whether requirement is ADDED, MODIFIED, or REMOVED

design.md

IMPORTANT: Write this file in Japanese.

Include as needed (not all sections are mandatory):

# <Feature Name> 設計

## 設計選択肢の検討

**Note: 複数の選択肢が存在する設計判断がある場合のみ記述。単純な要件で選択肢がほぼない場合は省略可。**

### [設計判断項目名]

| 選択肢 | 概要 | メリット | デメリット |
|--------|------|----------|------------|
| A: [選択肢A名] | [簡潔な説明] | [利点] | [欠点] |
| B: [選択肢B名] | [簡潔な説明] | [利点] | [欠点] |
| C: [選択肢C名] | [簡潔な説明] | [利点] | [欠点] |

**採用**: [選択肢X]
**理由**: [なぜこの選択肢を選んだか1-2文で簡潔に]

## Refactoring Analysis (REQUIRED)

### Existing Code Modification/Deletion Review

| Target | File:Line | Current State | Proposal | Reason |
|--------|-----------|---------------|----------|--------|
| [Function/Class name] | `file.ts:42` | [Current impl] | Delete/Modify/Merge | [Reason] |

### Deletion Targets
- [ ] `function_name` in `file.ts:XX` - [Reason for deletion]

### Modification Targets (including breaking changes)
- [ ] `function_name` in `file.ts:XX` - [Change details and reason]

### Consolidation Targets
- [ ] `func_a` + `func_b` → `new_func` - [Reason for consolidation]

### Justification for New Additions

**Only fill this section if new code is truly necessary**

| New Item | Reason Required | Why Existing Code Cannot Be Used |
|----------|-----------------|----------------------------------|
| [Function/Class name] | [Reason] | [Why existing code is insufficient] |

### Code Volume Estimate

- Lines to delete: XX
- Lines to modify: XX
- Lines to add: XX
- **Net change: ±XX lines** (Goal: minimize net increase)

## 全体構成

[System architecture diagram/explanation]

## コンポーネント設計

### [Component Name]
- 責務: [Component's responsibilities]
- インターフェース: [Public API]
- 依存関係: [Relationships with other components]

## データベース設計

### テーブル: [Table Name]
- カラム定義
- インデックス
- 制約

## API設計

### [Endpoint Name]
- メソッド: GET/POST/PUT/DELETE
- パス: /api/...
- リクエスト: [Parameters]
- レスポンス: [Return values]

## UI設計

[Screen transitions, component composition, etc.]

## 外部連携設計

[External API, library usage]

## セキュリティ設計

[Authentication, authorization, data protection, etc.]

## テスト設計

### テスト方針
- **テスト対象**: [public API / export関数 / クラスの公開メソッド]
- **モック対象**: [外部API名]（理由: 課金/不安定）
- **実DB使用**: [はい/いいえ]
- **テストインフラ**: [testcontainers / docker-compose / in-memory DB / N/A]
- **高コストテスト**: [あり/なし] → 環境変数制御

### [Test Type: Integration / E2E / Unit]

#### Test: [Test Name]
- **対応シナリオ**: requirement-spec.mdの[シナリオ名]
- **テスト対象**: [public関数/メソッド名]
- **Given/Arrange**: [Preconditions]
- **When/Act**: [Execution]
- **Then/Assert**: [Verification]
- **モック**: [なし / 外部API名]

Key Points:

• Tests must correspond to scenarios in requirement-spec.md
• Use the same Given-When-Then or Arrange-Act-Assert format for tests

tasks.md

IMPORTANT: Write this file in Japanese.

IMPORTANT: Tasks MUST be structured for TDD (Test-Driven Development). Each task should include writing the test first, then the implementation.

# <Feature Name> タスク

## Phase 1: [Phase Name]