feat: initial commit - opencode spec-driven development boilerplate

Converted from Claude Code boilerplate to opencode:
- CLAUDE.md -> AGENTS.md (opencode instructions)
- .claude/settings.json -> opencode.json (permissions schema)
- .claude/agents/ -> .opencode/agent/ (subagents with mode: subagent)
- .claude/commands/ -> .opencode/command/ (slash commands with )
- .claude/skills/ -> .opencode/skills/ (7 skills, removed allowed-tools)
- DevContainer updated to install opencode
- All .claude/ paths and Claude Code references updated
This commit is contained in:
2026-06-24 22:32:45 +02:00
commit ced279e2df
45 changed files with 7439 additions and 0 deletions

View File

@ -0,0 +1,96 @@
# Design Document
## Architecture Overview
{Describe the architecture pattern to adopt}
```
{Describe the architecture diagram in text or Mermaid}
```
## Component Design
### 1. {Component name 1}
**Responsibilities**:
- {Responsibility 1}
- {Responsibility 2}
**Implementation highlights**:
- {Points to note during implementation}
- {Technical constraints}
### 2. {Component name 2}
**Responsibilities**:
- {Responsibility 1}
- {Responsibility 2}
**Implementation highlights**:
- {Points to note during implementation}
- {Technical constraints}
## Data Flow
### {Use case name}
```
1. {Step 1}
2. {Step 2}
3. {Step 3}
```
## Error Handling Strategy
### Custom Error Classes
{Define the necessary error classes}
### Error Handling Patterns
{How errors are handled}
## Test Strategy
### Unit Tests
- {Test target 1}
- {Test target 2}
### Integration Tests
- {Test scenario 1}
- {Test scenario 2}
## Dependent Libraries
{Describe any newly added libraries}
```json
{
"dependencies": {
"{library name}": "{version}"
}
}
```
## Directory Structure
```
{File structure to be added or changed}
```
## Implementation Order
1. {Implementation step 1}
2. {Implementation step 2}
3. {Implementation step 3}
## Security Considerations
- {Security-related points to note}
## Performance Considerations
- {Performance-related points to note}
## Future Extensibility
{A design that accounts for future extensions}

View File

@ -0,0 +1,48 @@
# Requirements
## Overview
{Describe the feature overview in 1-2 sentences}
## Background
{Why this feature is needed and what problem it solves}
## Features to Implement
### 1. {Feature name 1}
- {Specific feature description}
- {What the user will be able to do}
### 2. {Feature name 2}
- {Specific feature description}
- {What the user will be able to do}
## Acceptance Criteria
### {Feature name 1}
- [ ] {Verifiable condition 1}
- [ ] {Verifiable condition 2}
- [ ] {Verifiable condition 3}
### {Feature name 2}
- [ ] {Verifiable condition 1}
- [ ] {Verifiable condition 2}
## Success Metrics
- {Describe quantitative goals if any}
- {Describe qualitative goals if any}
## Out of Scope
The following will not be implemented in this phase:
- {Feature not implemented 1}
- {Feature not implemented 2}
## Reference Documents
- `docs/product-requirements.md` - Product Requirements Document
- `docs/functional-design.md` - Functional design document
- `docs/architecture.md` - Architecture design document

View File

@ -0,0 +1,107 @@
# Task List
## 🚨 Principle of Fully Completing Tasks
**Keep working until all tasks in this file are complete**
### Mandatory Rules
- **Make every task `[x]`**
- "Planned as a separate task due to time constraints" is forbidden
- "Postponed because the implementation is too complex" is forbidden
- Do not finish work while leaving incomplete tasks (`[ ]`)
### Plan Only Tasks That Can Be Implemented
- At the planning stage, list only "tasks that can be implemented"
- Do not include "tasks that might be done in the future"
- Do not include "tasks under consideration"
### The Only Case Where Skipping a Task Is Permitted
Skipping is possible only when one of the following technical reasons applies:
- A change in the implementation approach made the feature itself unnecessary
- An architecture change replaced it with a different implementation method
- A change in dependencies made the task impossible to execute
When skipping, always state the reason clearly:
```markdown
- [x] ~~task name~~ (unnecessary due to a change in approach: specific technical reason)
```
### If a Task Is Too Large
- Split the task into smaller subtasks
- Add the split subtasks to this file
- Complete the subtasks one by one
---
## Phase 1: {Phase name}
- [ ] {Task 1}
- [ ] {Subtask 1-1}
- [ ] {Subtask 1-2}
- [ ] {Task 2}
- [ ] {Subtask 2-1}
- [ ] {Subtask 2-2}
## Phase 2: {Phase name}
- [ ] {Task 1}
- [ ] {Subtask 1-1}
- [ ] {Subtask 1-2}
- [ ] {Task 2}
## Phase 3: Quality Check and Fixes
- [ ] Confirm that all tests pass
- [ ] `npm test`
- [ ] Confirm that there are no lint errors
- [ ] `npm run lint`
- [ ] Confirm that there are no type errors
- [ ] `npm run typecheck`
- [ ] Confirm that the build succeeds
- [ ] `npm run build`
## Phase 4: Documentation Updates
- [ ] Update README.md (as needed)
- [ ] Post-implementation retrospective (record at the bottom of this file)
---
## Post-Implementation Retrospective
### Implementation Completion Date
{YYYY-MM-DD}
### Differences Between Plan and Actual
**Points that differed from the plan**:
- {Technical changes not anticipated at planning time}
- {Changes in the implementation approach and the reasons}
**Tasks that became newly necessary**:
- {Tasks added during implementation}
- {Why the addition was necessary}
**Tasks skipped for technical reasons** (only when applicable):
- {Task name}
- Reason for skipping: {specific technical reason}
- Alternative implementation: {what it was replaced with}
**⚠️ Note**: Do not list tasks skipped for reasons such as "time constraints" or "difficulty" here. Completing all tasks is the principle.
### Lessons Learned
**Technical insights**:
- {Technical knowledge gained through implementation}
- {New technologies or patterns used}
**Process improvements**:
- {What went well in task management}
- {How the steering files were leveraged}
### Improvement Suggestions for Next Time
- {Things to watch out for in the next feature addition}
- {More efficient implementation methods}
- {Improvements to task planning}