docs-starter-kit

ドキュメントスターターキット

あらゆるプロジェクト向けに、完全でプロフェッショナルなドキュメントを作成します。

基本的なワークフロー

1. プロジェクトの種類を判断する：OSS の公開プロジェクト、社内プロジェクト、ライブラリ、アプリケーション
2. テンプレートを選択する：プロジェクトの種類に応じて適切なドキュメントを選びます
3. 内容をカスタマイズする：プロジェクト固有の情報を入力します
4. セクションを追加する：プロジェクトに関連するセクションを含めます
5. 網羅性を確認する：必須のドキュメントがすべて揃っていることを確認します
6. 書式を統一する：一貫したスタイルと構成を適用します

必須のドキュメントファイル

README.md（必須）

プロジェクトの概要と利用開始ガイド

• プロジェクトの説明と目的
• 機能と能力
• クイックスタートガイド
• インストール手順
• 使用例
• 設定オプション
• コントリビューションへのリンク
• ライセンス情報

CONTRIBUTING.md（推奨）

コントリビューター向けガイド

• コントリビューションの方法
• 開発環境のセットアップ
• コードスタイルのガイドライン
• テスト要件
• プルリクエストの手順
• 行動規範へのリンク

LICENSE（OSS では必須）

プロジェクトのライセンス

• MIT、Apache 2.0、GPL、BSD など
• 著作権者と年

CODE_OF_CONDUCT.md（OSS のベストプラクティス）

コミュニティのガイドライン

• 期待される行動
• 許容されない行動
• 適用手順
• 連絡先情報

SECURITY.md（推奨）

セキュリティポリシーと報告方法

• サポート対象バージョン
• 脆弱性の報告方法
• 対応までの期間
• セキュリティアップデートの手順

CHANGELOG.md（推奨）

バージョン履歴

• バージョンごとの主な変更点
• 破壊的変更を明記
• リリース日
• Keep a Changelog 形式に準拠

README.md テンプレート

# Project Name

Brief description of what this project does and who it's for.

## Features

- ✨ Feature 1
- 🚀 Feature 2
- 🎯 Feature 3

## Quick Start

```bash
# Clone the repository
git clone https://github.com/username/project-name.git

# Install dependencies
npm install

# Run development server
npm run dev
```

インストール

前提条件

• Node.js 20+
• npm または pnpm
• PostgreSQL 15+（該当する場合）

セットアップ

1. クローンしてインストールします：

   git clone <repo>
   npm install
   

2. 環境を設定します：

   cp .env.example .env
   # Edit .env with your values
   

3. データベースをセットアップします（該当する場合）：

   npm run db:migrate
   npm run db:seed
   

4. 開発を開始します：

   npm run dev
   

使用方法

基本的な例

import { something } from "project-name";

const result = something();

高度な使用方法

［より詳細な例］

設定

利用可能な環境変数：

変数	説明	デフォルト
API_KEY	API 認証キー	-
PORT	サーバーポート	3000
DATABASE_URL	データベース接続	-

ドキュメント

• API リファレンス
• アーキテクチャ
• コントリビューションガイド

テスト

# Run all tests
npm test

# Run with coverage
npm run test:coverage

# Run specific test file
npm test path/to/test

デプロイ

［デプロイ手順］

使用技術

• Next.js - React フレームワーク
• Prisma - データベース ORM
• Tailwind CSS - スタイリング

コントリビューション

コントリビューションを歓迎します！行動規範とプルリクエストの提出手順については、CONTRIBUTING.mdをお読みください。

ライセンス

このプロジェクトは MIT License の下でライセンスされています。詳細はLICENSEファイルをご覧ください。

作成者

• Your Name - 初期開発 - YourGitHub

謝辞

• コードを使用させていただいた方々への感謝
• インスピレーション
• 参考資料

## CONTRIBUTING.md Template

```markdown
# Contributing to [Project Name]

Thank you for your interest in contributing! This document provides guidelines for contributing to this project.

## Code of Conduct

This project adheres to a [Code of Conduct](CODE_OF_CONDUCT.md). By participating, you are expected to uphold this code.

## How Can I Contribute?

### Reporting Bugs

Before creating bug reports, please check existing issues to avoid duplicates. When creating a bug report, include:

- Clear and descriptive title
- Detailed description of the issue
- Steps to reproduce
- Expected vs actual behavior
- Environment details (OS, Node version, etc.)
- Screenshots if applicable

### Suggesting Enhancements

Enhancement suggestions are tracked as GitHub issues. When creating an enhancement suggestion, include:

- Clear and descriptive title
- Detailed description of the proposed feature
- Explanation of why this enhancement would be useful
- Possible implementation approach

### Pull Requests

1. Fork the repository
2. Create a feature branch (`git checkout -b feature/amazing-feature`)
3. Make your changes
4. Add tests for new functionality
5. Ensure all tests pass (`npm test`)
6. Commit using conventional commits (`git commit -m 'feat: add amazing feature'`)
7. Push to your fork (`git push origin feature/amazing-feature`)
8. Open a Pull Request

## Development Setup

See [README.md](README.md) for initial setup instructions.

### Development Workflow

```bash
# Install dependencies
npm install

# Start development server
npm run dev

# Run tests in watch mode
npm run test:watch

# Run linter
npm run lint

# Format code
npm run format

コードスタイル

• 既存のコードスタイルに従ってください
• 新しいコードはすべて TypeScript を使用してください
• コミット前に npm run lint と npm run format を実行してください
• Conventional Commits に従って、内容が明確なコミットメッセージを書いてください

コミットメッセージの形式

<type>(<scope>): <description>

[optional body]

[optional footer]

種類：feat、fix、docs、style、refactor、test、chore

テスト

• すべての新機能にテストを書いてください
• テストカバレッジを 80% 以上に保ってください
• PR を提出する前にテストを実行してください
• 適切な場合は、ユニットテストと統合テストの両方を含めてください

ドキュメント

• 機能を追加した場合は README.md を更新してください
• 新しい環境変数を文書化してください
• 公開 API に JSDoc コメントを追加してください
• 重要な変更について CHANGELOG.md を更新してください

レビュープロセス

1. 自動チェック（テスト、リンティング、ビルド）に合格する必要があります
2. 少なくとも 1 人のメンテナーによる承認が必要です
3. すべてのレビューコメントに対応してください
4. 承認後、メンテナーがマージします

ご質問はありますか？

ご質問がある場合は、お気軽に issue を作成するか、[email protected] までお問い合わせください。

ライセンス

コントリビュートすることで、あなたのコントリビューションがプロジェクトと同じライセンスの下でライセンスされることに同意したものとみなされます。

## SECURITY.md Template

```markdown
# Security Policy

## Supported Versions

| Version | Supported          |
| ------- | ------------------ |
| 2.x.x   | :white_check_mark: |
| 1.x.x   | :x:                |

## Reporting a Vulnerability

We take security seriously. If you discover a security vulnerability, please follow these steps:

### Do Not

- Open a public GitHub issue
- Disclose the vulnerability publicly before we've addressed it

### Do

1. **Email us** at [email protected]
2. **Include details:**
   - Description of the vulnerability
   - Steps to reproduce
   - Potential impact
   - Suggested fix (if any)

### What to Expect

- **Acknowledgment:** Within 48 hours
- **Initial assessment:** Within 1 week
- **Regular updates:** Every 2 weeks
- **Resolution:** Depends on severity and complexity

### Disclosure Policy

- We will investigate and respond promptly
- We will work with you to understand the issue
- We will keep you informed of our progress
- We will credit you for the discovery (unless you prefer to remain anonymous)

### Security Update Process

1. Patch is developed and tested
2. Security advisory is prepared
3. New version is released
4. Advisory is published
5. Users are notified

## Best Practices

When using this project:

- Keep dependencies up to date
- Use environment variables for secrets
- Enable security features in production
- Follow principle of least privilege
- Regularly review access logs

## Known Security Considerations

[Document any known security considerations or limitations]

## Security-Related Configuration

[Document security-related configuration options]

CODE_OF_CONDUCT.md テンプレート

# Code of Conduct

## Our Pledge

We pledge to make participation in our project a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.

## Our Standards

### Positive Behavior

- Using welcoming and inclusive language
- Being respectful of differing viewpoints and experiences
- Gracefully accepting constructive criticism
- Focusing on what is best for the community
- Showing empathy towards other community members

### Unacceptable Behavior

- Trolling, insulting/derogatory comments, and personal attacks
- Public or private harassment
- Publishing others' private information without permission
- Other conduct which could reasonably be considered inappropriate

## Our Responsibilities

Project maintainers are responsible for clarifying standards of acceptable behavior and will take appropriate and fair corrective action in response to unacceptable behavior.

## Scope

This Code of Conduct applies within all project spaces and when representing the project or its community.

## Enforcement

Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the project team at [[email protected]]. All complaints will be reviewed and investigated promptly and fairly.

## Attribution

This Code of Conduct is adapted from the [Contributor Covenant](https://www.contributor-covenant.org), version 2.0.

LICENSE テンプレート

MIT ライセンス

MIT License

Copyright (c) [year] [fullname]

Permission is hereby granted, free of charge, to any person obtaining a copy...

Apache 2.0

Apache License
Version 2.0, January 2004
http://www.apache.org/licenses/

CHANGELOG.md テンプレート

# Changelog

All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

## [Unreleased]

### Added

- New feature X

### Changed

- Updated dependency Y

### Fixed

- Bug Z

## [1.0.0] - 2024-01-15

### Added

- Initial release
- Feature A
- Feature B

### Security

- Fixed vulnerability in dependency

[unreleased]: https://github.com/user/project/compare/v1.0.0...HEAD
[1.0.0]: https://github.com/user/project/releases/tag/v1.0.0

その他のドキュメント

API.md

API リファレンスドキュメント

ARCHITECTURE.md

システム設計とアーキテクチャ

DEPLOYMENT.md

デプロイ手順

DEVELOPMENT.md

開発環境のセットアップ

FAQ.md

よくある質問

TROUBLESHOOTING.md

一般的な問題と解決策

ドキュメント作成のベストプラクティス

1. 最新の状態に保つ：リリースごとにドキュメントを見直します
2. 簡潔にする：明確に、要点を絞って記述します
3. 例を使う：説明だけでなく、実例を示します
4. 関連ドキュメントにリンクする：適切に相互参照します
5. 読者を考慮する：ユーザーの知識レベルに合わせて記述します
6. 一貫した書式を使う：スタイルガイドに従います
7. ビジュアルを含める：図、スクリーンショット、例を掲載します

プロジェクトの種類ごとの違い

ライブラリ／パッケージ

重点項目：API リファレンス、使用例、インストール

アプリケーション

重点項目：セットアップ、設定、デプロイ

CLI ツール

重点項目：コマンド、オプション、例

内部ツール

重点項目：アクセス、認証、会社固有のプロセス

チェックリスト

プロジェクトのドキュメントを完成させるには：

• 明確な説明とクイックスタートを含む README.md
• 開発ガイドラインを記載した CONTRIBUTING.md
• LICENSE ファイル（オープンソースの場合）
• CODE_OF_CONDUCT.md（オープンソースの場合）
• 脆弱性の報告方法を記載した SECURITY.md
• バージョン履歴を記載した CHANGELOG.md
• バグ報告と機能提案用の .github/ISSUE_TEMPLATE/
• .github/PULL_REQUEST_TEMPLATE.md
• 追加ドキュメント用の docs/ フォルダー
• API リファレンス（ライブラリの場合）
• アーキテクチャドキュメント（複雑な場合）