technical-specification について
ソフトウェアプロジェクトの技術仕様書を作成するスキルです。テンプレートはアーキテクチャ、API、セキュリティ、リスク、リリース、実装計画を扱い、測定可能な要件やレビューの指針も示します。
主な機能
- 01メタデータ付き仕様書テンプレート
- 02アーキテクチャと API 設計の項目
- 03セキュリティとリスク分析
- 04実装、リリース、ロールバック計画
- 05受け入れ基準とレビューの指針
活用シーン
- 01実装前のソフトウェア機能の仕様化
- 02API と受け入れ基準に関する関係者の合意形成
- 03セキュリティリスク、依存関係、リリース計画の記録
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ secondsky/ claude-skills --skill technical-specificationインストール後、Claude Code で/technical-specificationを入力して読み込まれたか確認します。
同梱ファイルreferences/template.md
詳細
技術仕様
ソフトウェアプロジェクトの包括的な技術仕様を作成します。
仕様テンプレート
# Technical Specification: [Feature Name]
## Metadata
- **Status**: Draft | In Review | Approved
- **Author**: [Name]
- **Reviewers**: [Names]
- **Last Updated**: [Date]
## Executive Summary
[2-3 sentences: What problem does this solve? What's the proposed solution?]
## Background & Context
- Current pain points
- Why now?
- Related work
## Goals
### Primary Goals
1. [Measurable goal]
### Non-Goals
- [What this spec explicitly does NOT cover]
## Functional Requirements
| ID | Requirement | Priority |
|----|-------------|----------|
| FR-1 | [Description] | P0 |
| FR-2 | [Description] | P1 |
## Non-Functional Requirements
- **Performance**: Response time < 200ms
- **Scalability**: Support 10K concurrent users
- **Availability**: 99.9% uptime
- **Security**: [Requirements]
## Technical Design
### Architecture
[Diagram or description]
### API Design
POST /api/v1/resource Request: { "field": "value" } Response: { "id": "123", "field": "value" }
### Database Schema
```sql
CREATE TABLE resources (
id UUID PRIMARY KEY,
field VARCHAR(255)
);
実装計画
| フェーズ | 期間 | 成果物 |
|---|---|---|
| 1 | 1~2 週目 | コア機能 |
| 2 | 3 週目 | API エンドポイント |
| 3 | 4 週目 | テストとドキュメント |
テスト戦略
- 単体テスト:カバレッジ 80%
- 統合テスト:API エンドポイント
- E2E テスト:重要なフロー
リスクと軽減策
| リスク | 発生確率 | 影響 | 軽減策 |
|---|---|---|---|
| [リスク] | 中 | 高 | [計画] |
成功基準
- すべての P0 要件を実装済み
- テストに合格
- パフォーマンス目標を達成
- ドキュメントを完成
## Full Template
See [references/template.md](references/template.md) for a comprehensive copy-paste template including:
- Complete metadata section
- Success metrics tables
- Architecture diagrams
- Detailed API design sections
- Security threat analysis
- Monitoring & observability
- Risk assessment matrix
- Rollout and rollback plans
- Dependencies tracking
- Open questions section
## Best Practices
**Do:**
- Include measurable acceptance criteria
- Add architecture diagrams
- Define explicit API contracts
- Quantify performance targets
- Document risks and mitigations
- Get stakeholder review before implementation
- Include security considerations
- Define rollback procedures
**Don't:**
- Use vague requirements ("fast", "scalable")
- Skip non-functional requirements
- Ignore security considerations
- Leave alternatives unexplored
- Omit testing strategy
- Forget dependencies and risks
コメント
Markdown 対応