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

129
.opencode/command/add-feature.md Normal file
View File

@ -0,0 +1,129 @@
---
description: Implement a new feature following existing patterns, fully autonomously without stopping
agent: build
---
# Adding a New Feature (Fully Autonomous Execution Mode)
**Important:** This workflow is designed to run fully automatically from start to finish without user intervention. After completing each step, immediately move on to the next step. Do not ask the user for confirmation mid-thought or interrupt the work.
**Feature name**: `$ARGUMENTS` (e.g. `/add-feature User profile editing`)
---
## Step 1: Preparation and Context Setup
1. Establish the current task context:
- Feature name: `$ARGUMENTS`
- Date: `[get the current date in YYYYMMDD format]`
- Steering directory path: `.steering/[date]-[feature name]/`
2. Create the steering directory above.
3. Create the following three empty files:
- `[steering directory path]/requirements.md`
- `[steering directory path]/design.md`
- `[steering directory path]/tasklist.md`
## Step 2: Understand the Project
1. Read `AGENTS.md` to grasp the overall picture of the project.
2. Review the persistent documents in the `docs/` directory to understand the relevant design philosophy and architecture.
## Step 3: Investigate Existing Patterns
1. Use the grep tool to search the source code (`src/`) for keywords related to the feature name.
2. Analyze the search results to identify existing implementation patterns, naming conventions, and how components are used.
## Step 4: Planning Phase (Automatic Generation of Steering Files)
1. Follow the **steering** skill (loaded automatically) in **planning mode** to generate the contents of the three files created in Step 1 (`requirements.md`, `design.md`, `tasklist.md`).
2. **Once this step completes successfully, never stop; immediately proceed to Step 5.**
## Step 5: Implementation Loop (Fully Working Through tasklist.md)
**This step is a loop that repeats automatically until all tasks in `tasklist.md` are `[x]`.**
**Once this step completes successfully, never stop; immediately proceed to Step 6.**
**Loop start:**
1. Read the task list:
- Read the `[steering directory path]/tasklist.md` file.
2. Check progress:
- Check whether any incomplete tasks (`[ ]`) exist in the file.
- **If no incomplete tasks exist:** consider this implementation loop complete and immediately proceed to **Step 6**.
- **If incomplete tasks exist:** proceed to the next step (3. Execute the task).
3. Execute the task:
- Identify one **incomplete task at the top** of `tasklist.md`.
- Carry out the implementation work needed to complete that task.
- Follow the **steering** skill in **implementation mode**.
- Always follow the coding standards in the **development-guidelines** skill.
4. Update the task list:
- Once the executed task is complete, use the edit tool to update `tasklist.md`, changing the task from `[ ]` to `[x]`.
5. Continue the loop:
- **Return to the top of Step 5 (1. Read the task list) and repeat the process.**
---
### * Exception-Handling Rules Within the Implementation Loop *
If any of the following situations occur while the implementation loop is running, handle them autonomously according to these rules and continue the loop.
- **Rule A: When a task is too large**
- **Handling:** Break the current task into multiple smaller subtasks. Use the edit tool to delete the original task and insert the new subtasks (with `[ ]`) in its place. Then continue the loop.
- **Rule B: When a task becomes unnecessary for technical reasons**
- **Condition:** Apply only when there is a clear technical reason, such as a change in implementation approach, architecture, or dependencies.
- **Handling:** Use the edit tool to update the task in the format `[x] ~~task name~~ (Reason: [briefly describe the specific technical reason])`. Then continue the loop.
- **❌ Strictly Forbidden Actions:**
- Intentionally skipping an incomplete task for reasons such as "do it later" or "make it a separate task."
- Leaving incomplete tasks unaddressed and ending the loop without reason.
- Asking the user to make a decision.
---
## Step 6: Implementation Validation (Launch a Subagent)
1. Do a final check that all tasks in `tasklist.md` are complete.
2. Use the Task tool to launch the `implementation-validator` subagent to validate quality:
- `subagent_type`: "implementation-validator"
- `description`: "Implementation quality validation"
- `prompt`: "Please validate the quality of all the changes related to the `[feature name]` implemented this time. The target files are `[list of paths of the implemented files]`. Focus on coding standards, error handling, testability, and consistency with existing patterns."
**Once this step completes successfully, never stop; immediately proceed to Step 7.**
## Step 7: Run Automated Tests
1. Run the following commands in order and confirm that all tests pass.
```bash
npm test
npm run lint
npm run typecheck
```
2. If any command produces an error, analyze the problem, generate and apply a fix, and then run this step again.
**Once this step completes successfully, never stop; immediately proceed to Step 8.**
## Step 8: Retrospective and Document Updates
1. Follow the **steering** skill in **retrospective mode** and record handover notes in `tasklist.md`.
- Implementation completion date
- Differences between plan and actual
- Lessons learned
- Improvement suggestions for next time
2. Determine whether this change affects the project's fundamental design or architecture.
3. If there is an impact, use the edit tool to update the relevant persistent documents in `docs/`.
## Completion Criteria
This workflow completes automatically once all of the following conditions are met.
- Step 5: All tasks in `tasklist.md` are complete (`[x]` or skipped for a valid reason).
- Step 6: The `implementation-validator` subagent's validation passes.
- Step 7: The `test`, `lint`, and `typecheck` commands all succeed without errors.
- Step 8: Handover notes are recorded in `tasklist.md`.
Until these completion criteria are met, continue to think autonomously, solve problems, and carry on the work.

64
.opencode/command/review-docs.md Normal file
View File

@ -0,0 +1,64 @@
---
description: Run a detailed document review using a subagent
agent: build
---
# Document Review
**Document path**: `$ARGUMENTS` (e.g. `/review-docs docs/product-requirements.md`)
## How to Run
```
opencode
> /review-docs docs/product-requirements.md
```
## Procedure
### Step 1: Verify the Document Exists
Check whether the specified document exists.
### Step 2: Launch the doc-reviewer Subagent
Launch the doc-reviewer subagent to run the review:
Use the Task tool to launch the doc-reviewer subagent:
- subagent_type: "doc-reviewer"
- description: "Document detailed review"
- prompt: "Please review $ARGUMENTS in detail.\n\nEvaluate it from the following perspectives:\n1. Completeness: Are all required items included?\n2. Specificity: Are there any ambiguous expressions?\n3. Consistency: Is it consistent with other documents?\n4. Measurability: Are success metrics measurable? (for a PRD)\n\nPlease produce a review report."
### Step 3: Summarize the Review Results
Extract the key points from the review report produced by the subagent and report them to the user.
## Output Format
```markdown
# Document Review Results
## Document: [file name]
### Key Improvements
1. [Improvement 1] (Priority: High/Medium/Low)
2. [Improvement 2] (Priority: High/Medium/Low)
3. [Improvement 3] (Priority: High/Medium/Low)
### Overall Rating
[1-5]/5
### Next Actions
- [Recommended action 1]
- [Recommended action 2]
For the full report, refer to the subagent's output.
```
## Notes
- The review involves detailed analysis and may take a few minutes.
- The subagent runs in an independent context, so it does not consume the main agent's context.

112
.opencode/command/setup-project.md Normal file
View File

@ -0,0 +1,112 @@
---
description: Initial setup - interactively create the six persistent documents
agent: build
---
# Initial Project Setup
This command interactively creates the project's six persistent documents.
## How to Run
```
opencode
> /setup-project
```
## Pre-Run Check
Check the files in the `docs/ideas/` directory.
```bash
# Check
ls docs/ideas/
# If files exist
✅ Found docs/ideas/initial-requirements.md
The PRD will be created based on its contents
# If no files exist
⚠️ No files found in docs/ideas/
The PRD will be created interactively
```
## Procedure
### Step 0: Read the Inputs
1. Read all markdown files in `docs/ideas/`
2. Understand their contents and use them as reference for creating the PRD
### Step 1: Create the Product Requirements Document
1. Follow the **prd-writing** skill (loaded automatically) to guide PRD creation
2. Create `docs/product-requirements.md` based on the contents of `docs/ideas/`
3. Flesh out the ideas raised during brainstorming:
- Detailed user stories
- Acceptance criteria
- Non-functional requirements
- Success metrics
4. Ask the user for confirmation and **wait until approved**
**The subsequent steps are based on the Product Requirements Document, so they are created automatically**
### Step 2: Create the Functional Design Document
1. Follow the **functional-design** skill (loaded automatically)
2. Read `docs/product-requirements.md`
3. Create `docs/functional-design.md` following the skill's template and guide
### Step 3: Create the Architecture Design Document
1. Follow the **architecture-design** skill (loaded automatically)
2. Read the existing documents
3. Create `docs/architecture.md` following the skill's template and guide
### Step 4: Create the Repository Structure Document
1. Follow the **repository-structure** skill (loaded automatically)
2. Read the existing documents
3. Create `docs/repository-structure.md` following the skill's template
### Step 5: Create the Development Guidelines
1. Follow the **development-guidelines** skill (loaded automatically)
2. Read the existing documents
3. Create `docs/development-guidelines.md` following the skill's template
### Step 6: Create the Glossary
1. Follow the **glossary-creation** skill (loaded automatically)
2. Read the existing documents
3. Create `docs/glossary.md` following the skill's template
## Completion Criteria
- All six persistent documents have been created
Completion message:
```
"Initial setup is complete!
Documents created:
✅ docs/product-requirements.md
✅ docs/functional-design.md
✅ docs/architecture.md
✅ docs/repository-structure.md
✅ docs/development-guidelines.md
✅ docs/glossary.md
You are now ready to start development.
How to use going forward:
- Editing documents: just ask in normal conversation
Examples: 'Add a new feature to the PRD', 'Review architecture.md'
- Adding features: run /add-feature [feature name]
Example: /add-feature User authentication
- Document review: run /review-docs [path]
Example: /review-docs docs/product-requirements.md
"
```