mcpField
T
technical-specification

technical-specification

github.com/secondsky开发240480 次安装5 周前更新
代码仓库

关于 technical-specification

用于编写软件项目技术规格的技能。模板涵盖架构、API、安全、风险、发布和实施计划，并提供可衡量需求与评审方面的建议。

主要功能

  1. 01含元数据的规格模板
  2. 02架构与 API 设计章节
  3. 03安全与风险分析
  4. 04实施、发布和回滚规划
  5. 05验收标准与评审指南

适用场景

  1. 01在实施前记录拟开发的软件功能
  2. 02围绕 API 和验收标准协调相关方
  3. 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