ken/opengroupware
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore: initialize repository with project docs and tooling

Browse Source 
- Add persistent docs: PRD, functional design, architecture, repository structure, development guidelines, milestones

- Add brainstorming notes (docs/ideas/)

- Configure tooling: package.json, tsconfig, eslint, prettier, vitest

- Add opencode configuration (commands, skills, agents)

- Add .gitignore for node_modules, .env, data/, backups/, build outputs
This commit is contained in:
Ken Yasue
2026-06-24 23:31:06 +02:00
commit 80e195b3dc
51 changed files with 12716 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

332
.opencode/skills/prd-writing/SKILL.md Normal file
View File

@ -0,0 +1,332 @@
---
name: prd-writing
description: A detailed guide and template for creating a Product Requirements Document (PRD). Use only when creating a PRD.
---
# PRD Writing Skill
This skill is a detailed guide for creating a high-quality Product Requirements Document (PRD).
## Prerequisites
Before you begin creating a PRD, the following must be complete:
### The idea has been refined through brainstorming
The user must have completed refining the product idea through dialogue with opencode.
### docs/ideas/initial-requirements.md has been created
**Important**: The brainstorming content must be saved by the user in the following file:
**File path**: `docs/ideas/initial-requirements.md`
This file must include the following content:
- The basic idea of the product
- The problem to be solved
- An overview of the target users
- The main features to be implemented
- The scope of the MVP
When creating the PRD, refer to the content of this file to add detail.
## Priority of existing documents
**Important**: If an existing PRD is present at `docs/product-requirements.md`,
follow the priority order below:
1. **Existing PRD (`docs/product-requirements.md`)** - Highest priority
- Contains project-specific requirements
- Takes precedence over this skill's guide
2. **This skill's guide** - Reference material
- Generic templates and examples
- Use when there is no existing PRD, or as a supplement
**When creating from scratch**: Refer to this skill's template and guide
**When updating**: Update while preserving the structure and content of the existing PRD
## Output destination
Save the PRD you create to the following location:
```
docs/product-requirements.md
```
## Template reference
When creating the PRD, use the following template: ./template.md
## PRD creation process
### 1. Review initial-requirements.md
First, review the initial requirements specification created by the user:
Read `docs/ideas/initial-requirements.md`
### 2. Generate the PRD draft
Based on the content of initial-requirements.md, generate the PRD following the template.
### 3. Review and improve the PRD
Review the generated PRD from the following perspectives:
#### Review perspectives
1. Is the product vision clear?
2. Are the target users specific?
3. Are the success metrics measurable?
4. Are the functional requirements detailed to an implementable level?
5. Are the non-functional requirements comprehensive?
#### Criteria for evaluating review results
Evaluate the generated PRD in the following format:
**✅ Strengths**
- A clear vision is described in a measurable and specific way
- The functional specifications are detailed to an implementation level
- KPIs are defined with quantitative metrics
**⚠️ Points that need improvement**
Ambiguity in functional requirements:
- Problem: There are areas where the concrete implementation specification is unclear
- Recommendation: Clearly state specific command specifications and error handling
Measurement method for success metrics:
- Problem: The measurement method is unclear
- Recommendation: Clearly state the measurement method and considerations for privacy
### 4. Improvement after review
Review the issues raised in the review one by one, and improve the areas that need more detail:
1. Review the raised issues one by one
2. Improve the areas that need more detail
3. After improving, conduct the review again
4. Repeat until there are no more issues
**Cautions**:
- Do not take the AI's review at face value; the final judgment must always be made by a human
- Clearly specify the review perspectives
- Have a human verify the validity of the improvement proposals
## Key points for creating a PRD
### 1. Specificity and measurability
Every requirement must be specific and measurable.
**Bad examples**:
- The system needs to be fast
- Users feel it is easy to use
**Good examples**:
- Command execution time: within 100ms (on an average PC environment)
- A new user can learn the basic operations within 5 minutes (measured by usability testing)
### 2. User-centered design
Every feature must solve a clear user problem.
**User story format**:
```
As a [user], I want [feature] so that [goal]
```
**Example**:
```
As a developer, I want a CLI-based task management tool
so that I can manage tasks without leaving the terminal
```
### 3. Clarifying priorities
Set a priority for every feature:
- **P0 (Required)**: Features to include in the MVP (Minimum Viable Product). Without these, the product does not stand as a product
- **P1 (Important)**: Features that should be added immediately after the initial release
- **P2 (Nice to have)**: Features to consider adding in the future
## Details of the main PRD sections
### 1. Product overview
#### Components
1. **Name**: Product name and subtitle
2. **Product concept**: Three main concepts
3. **Product vision**: The world you aim for, in 3-5 sentences
4. **Purpose**: A list of specific purposes
#### Example
```markdown
### Name
**Devtask** - A task management CLI tool for developers
### Product concept
- Task management that is complete within the CLI: Complete all operations without leaving the terminal
- Automatic priority estimation: Automatically estimate priority from a task's due date, creation time, status change history, and so on
- A simple and fast operating feel: Complete operations with minimal keystrokes, with instant response
### Product vision
Provide a CLI tool that lets developers efficiently manage tasks without leaving the terminal.
Specialized for command-line operation, it delivers lightweight, fast task management that does not interrupt the development flow.
With automatic priority estimation, developers can focus on essential work.
```
**Include a specific value proposition**
Bad example:
```
Build a convenient task management tool
```
Good example:
```
A CLI tool that lets developers manage tasks without leaving the terminal.
Value provided:
- Reduced context switching (zero GUI ↔ terminal switching)
- Improved work efficiency (no mouse operation, averaging a 30% time reduction)
- Integration with automation (can be embedded in shell scripts)
```
### 2. Target users (personas)
#### Required elements
1. **Basic attributes**: Age, occupation, years of experience
2. **Technology stack**: Tools and languages in use
3. **Current problems**: Specific pain points
4. **Expected solution**: What they want to become
5. **A typical daily workflow**
#### Example
```markdown
### Primary persona: Taro Tanaka (29, full-stack engineer)
- Freelancer running 3-5 projects in parallel
- Vim/Emacs + terminal environment
- Does not want to spend time on task management
- Prefers Markdown, Git, and CLI tools
```
### 3. Success metrics (KPIs)
#### SMART principles
- **S**pecific: Clear about what is being measured
- **M**easurable: Can be measured numerically
- **A**chievable: A realistic target
- **R**elevant: Related to business goals
- **T**ime-bound: Sets a deadline for achievement
#### Example
```markdown
### Primary KPIs
- Daily active users (DAU): 100 (in 3 months)
- Task completion rate: 70% or higher
- Average number of commands executed per day: 10 or more
```
### 4. Functional requirements
#### Core features (MVP)
Include the following for each feature:
- User story
- Acceptance criteria (in checklist form)
- Priority (P0/P1/P2)
**Format**:
```markdown
### [Feature name]
User story:
As a [user], I want [feature] so that [goal]
Acceptance criteria:
- [ ] Criterion 1 (measurable)
- [ ] Criterion 2 (measurable)
Priority: P0 (Required) / P1 (Important) / P2 (Nice to have)
```
#### CLI interface
For a CLI tool, include specific command examples:
```bash
# Basic operations
devtask add "Task name" --due 2025-01-15 --priority high
devtask list
devtask next # Show the task to do now
devtask done <task-id>
devtask show <task-id>
```
### 5. Non-functional requirements
Describe them in a measurable form:
**Example**:
```markdown
### Performance
- Command execution time: within 100ms (on an average PC environment)
- Task list display: within 1 second for up to 1000 items
### Usability
- A new user can learn the basic operations within 5 minutes
- All features can be checked via the help command
### Reliability
- Zero data loss (automatic backup)
- Rollback on error
```
## Quality standards and checkpoints
To ensure the quality of the PRD, confirm the following checkpoints:
### Vision and goals
- [ ] Is the product vision clear and measurable?
- [ ] Is the specific value provided defined?
- [ ] Is the target market clear?
### Target users
- [ ] Is the persona specifically defined?
- [ ] Are the current problems and expected solution clear?
- [ ] Are the technology stack and daily workflow described?
### Success metrics
- [ ] Are KPIs defined following the SMART principles?
- [ ] Is the measurement method clear?
- [ ] Is an achievement deadline set?
### Functional requirements
- [ ] Is every feature described in user story form?
- [ ] Are acceptance criteria defined in a measurable form?
- [ ] Is the priority (P0/P1/P2) clearly set?
### Non-functional requirements
- [ ] Are performance standards defined with specific numbers?
- [ ] Are usability standards measurable?
- [ ] Are reliability and security requirements clear?
## Summary
Keys to success in creating a PRD:
1. **Create based on initial-requirements.md**: Refer to the brainstorming content created by the user
2. **Specificity and measurability**: Make every requirement clear
3. **User-centered**: Only features that solve user problems
4. **Clarifying priorities**: Classify by P0/P1/P2
5. **Review and improvement**: Self-review and final human judgment
6. **Applying the SMART principles**: Especially important when defining KPIs

116
.opencode/skills/prd-writing/template.md Normal file
View File

@ -0,0 +1,116 @@
# Product Requirements Document
## Product overview
### Name
**[Product name]** - [Subtitle]
### Product concept
- **[Concept 1]**: [Description]
- **[Concept 2]**: [Description]
- **[Concept 3]**: [Description]
### Product vision
[Describe the world this product aims for, in 3-5 sentences]
### Purpose
- [Purpose 1]
- [Purpose 2]
- [Purpose 3]
## Target users
### Primary persona: [Name] ([Age], [Occupation])
- [Attribute 1: e.g., freelancer running 3-5 projects in parallel]
- [Attribute 2: e.g., Vim/Emacs + terminal environment]
- [Current problem: e.g., does not want to spend time on task management]
- [Expected solution]
- [A typical daily workflow]
## Success metrics (KPIs)
### Primary KPIs
- [Metric 1]: [Target value] ([Deadline])
- Example: Daily active users (DAU): 100 (in 3 months)
- [Metric 2]: [Target value] ([Deadline])
- Example: Task completion rate: 70% or higher
### Secondary KPIs
- [Metric 1]: [Target value] ([Deadline])
- [Metric 2]: [Target value] ([Deadline])
## Functional requirements
### Core features (MVP)
#### [Feature 1]
**User story**:
As a [user], I want [feature] so that [goal]
**Acceptance criteria**:
- [ ] [Criterion 1: described in a measurable form]
- [ ] [Criterion 2: described in a measurable form]
- [ ] [Criterion 3: described in a measurable form]
**Priority**: P0 (Required)
#### [Feature 2]
**User story**:
[Description]
**Acceptance criteria**:
- [ ] [Criterion 1]
- [ ] [Criterion 2]
**Priority**: P1 (Important)
### CLI interface (if applicable)
```bash
# Example of basic operations
[command] [subcommand] [options]
# Write specific command examples
```
### Future features (Post-MVP)
#### [Feature 3]
[Brief description]
**Priority**: P2 (Nice to have)
## Non-functional requirements
### Performance
- [Requirement 1]: [Measurable standard]
- Example: Command execution time: within 100ms
- [Requirement 2]: [Measurable standard]
- Example: Task list display: within 1 second for up to 1000 items
### Usability
- [Requirement 1]: [Measurable standard]
- Example: A new user can learn the basic operations within 5 minutes
- [Requirement 2]: [Measurable standard]
### Reliability
- [Requirement 1]: [Measurable standard]
- Example: Zero data loss (automatic backup)
- [Requirement 2]: [Measurable standard]
### Security
- [Requirement 1]: [Measurable standard]
- [Requirement 2]: [Measurable standard]
### Scalability
- [Requirement 1]: [Measurable standard]
- [Requirement 2]: [Measurable standard]
## Out of scope
Items explicitly considered out of scope:
- [Item 1]
- [Item 2]
- [Item 3]