Unify OpenCode and Codex starter kits
- Add .shared/prompts/ with tool-neutral prompts - Add .opencode/config/project.md, rules/, skills/ from opencode-kit - Add .codex/config/project.md from codex-kit - Copy .shared/prompts/ to both .opencode/prompts/ and .codex/prompts/ - Add features/INDEX.md and features/README.md - Update README with unified structure The two original starter kits are now redundant.
This commit is contained in:
Worker Skeletton
70
.opencode/skills/architecture/SKILL.md
Normal file
70
.opencode/skills/architecture/SKILL.md
Normal file
@@ -0,0 +1,70 @@
|
||||
---
|
||||
name: architecture
|
||||
description: Designs technical architecture for feature specs
|
||||
category: development
|
||||
---
|
||||
|
||||
# Solution Architect
|
||||
|
||||
Designs the technical architecture for a feature and adds it to the feature spec.
|
||||
|
||||
## When to Use
|
||||
|
||||
Run this skill after `/requirements` to design the technical approach:
|
||||
|
||||
```
|
||||
/architecture features/PROJ-X-feature-name.md
|
||||
```
|
||||
|
||||
## Skill Steps
|
||||
|
||||
1. **Read feature spec**
|
||||
- Read the feature spec file created by `/requirements`
|
||||
|
||||
2. **Design architecture**
|
||||
- **Component hierarchy**: List all components needed
|
||||
- **API design**: Endpoints (method, path, request/response shapes)
|
||||
- **Database schema**: Tables, columns, RLS policies (if Supabase)
|
||||
- **Implementation order**: What to build first, dependencies
|
||||
|
||||
3. **Add Tech Design section**
|
||||
- Append "Tech Design" section to the feature spec
|
||||
|
||||
4. **Update tracking**
|
||||
- Update `features/INDEX.md` status to "Designed"
|
||||
|
||||
5. **Suggest next step**
|
||||
- Recommend running `/frontend` or `/backend` next
|
||||
|
||||
## Tech Design Section Format
|
||||
|
||||
```markdown
|
||||
## Tech Design
|
||||
|
||||
### Components
|
||||
- ComponentName: description, props
|
||||
|
||||
### API Endpoints
|
||||
| Method | Path | Request | Response |
|
||||
|--------|------|---------|----------|
|
||||
| POST | /api/entities | {...} | {id, ...} |
|
||||
|
||||
### Database Schema
|
||||
- Table: entities
|
||||
- id: uuid (PK)
|
||||
- name: text
|
||||
- created_at: timestamp
|
||||
|
||||
### Implementation Order
|
||||
1. Create database schema
|
||||
2. Build API endpoints
|
||||
3. Build UI components
|
||||
4. Add tests
|
||||
```
|
||||
|
||||
## Context Recovery
|
||||
|
||||
If context is compacted:
|
||||
1. Re-read the feature spec
|
||||
2. Check if Tech Design section already exists
|
||||
3. Continue from implementation order
|
||||
64
.opencode/skills/backend/SKILL.md
Normal file
64
.opencode/skills/backend/SKILL.md
Normal file
@@ -0,0 +1,64 @@
|
||||
---
|
||||
name: backend
|
||||
description: Builds APIs, database schemas, and RLS policies with Supabase
|
||||
category: development
|
||||
---
|
||||
|
||||
# Backend Developer
|
||||
|
||||
Builds API endpoints, database schemas, and RLS policies for a feature.
|
||||
|
||||
## When to Use
|
||||
|
||||
```
|
||||
/backend features/PROJ-X-feature-name.md
|
||||
```
|
||||
|
||||
## Skill Steps
|
||||
|
||||
1. **Read context**
|
||||
- Read feature spec Tech Design section
|
||||
- Check existing APIs: `ls src/app/api/`
|
||||
- Check Supabase client: `cat src/lib/supabase.ts`
|
||||
|
||||
2. **Implement backend**
|
||||
- Create API routes in `src/app/api/[entity]/`
|
||||
- Create database migrations if needed
|
||||
- Add RLS policies for new tables
|
||||
- Use Supabase client from `src/lib/supabase.ts`
|
||||
|
||||
3. **Write tests**
|
||||
- Unit tests for all endpoints
|
||||
- Integration tests for API routes
|
||||
|
||||
4. **Verify**
|
||||
- Run `npm test` to ensure tests pass
|
||||
|
||||
5. **Update tracking**
|
||||
- Mark feature as "Backend Done" in `features/INDEX.md`
|
||||
|
||||
6. **Suggest next step**
|
||||
- Recommend `/qa` next
|
||||
|
||||
## API Route Pattern
|
||||
|
||||
```
|
||||
src/app/api/[entity]/
|
||||
├── route.ts # GET, POST
|
||||
├── [id]/route.ts # GET, PUT, DELETE
|
||||
```
|
||||
|
||||
## Rules
|
||||
|
||||
- Use Supabase client from `src/lib/supabase.ts`
|
||||
- Follow existing route patterns
|
||||
- Add RLS policies for all new tables
|
||||
- Write tests for all endpoints
|
||||
- Run `npm test` after implementation
|
||||
|
||||
## Context Recovery
|
||||
|
||||
If context is compacted:
|
||||
1. Re-read feature spec Tech Design
|
||||
2. Check `git diff` for uncommitted changes
|
||||
3. Continue from next endpoint
|
||||
60
.opencode/skills/deploy/SKILL.md
Normal file
60
.opencode/skills/deploy/SKILL.md
Normal file
@@ -0,0 +1,60 @@
|
||||
---
|
||||
name: deploy
|
||||
description: Deploys to Vercel with production-ready checks
|
||||
category: devops
|
||||
---
|
||||
|
||||
# DevOps
|
||||
|
||||
Deploys the project to Vercel with production-ready checks.
|
||||
|
||||
## When to Use
|
||||
|
||||
```
|
||||
/deploy
|
||||
```
|
||||
|
||||
## Skill Steps
|
||||
|
||||
1. **Pre-deployment checks**
|
||||
- Run `npm run build` - must succeed
|
||||
- Run `npm run lint` - no errors
|
||||
|
||||
2. **Deploy**
|
||||
- Run `vercel --prod`
|
||||
- Capture deployment URL
|
||||
|
||||
3. **Verify deployment**
|
||||
- Test the deployed URL
|
||||
- Run smoke tests on key features
|
||||
|
||||
4. **Post-deployment**
|
||||
- Update `features/INDEX.md` with deployment URL
|
||||
- Mark feature as "Deployed"
|
||||
|
||||
## Rules
|
||||
|
||||
- Build must succeed before deployment
|
||||
- Lint must pass before deployment
|
||||
- Verify deployment URL is accessible
|
||||
|
||||
## If Build Fails
|
||||
|
||||
1. Fix compilation errors
|
||||
2. Re-run `npm run build`
|
||||
3. Re-run `npm run lint`
|
||||
4. Then deploy
|
||||
|
||||
## If Lint Fails
|
||||
|
||||
1. Run `npm run lint:fix`
|
||||
2. Commit fixes
|
||||
3. Re-run `npm run lint`
|
||||
4. Then deploy
|
||||
|
||||
## Context Recovery
|
||||
|
||||
If context is compacted during deployment:
|
||||
1. Check if `vercel` deployment completed
|
||||
2. Verify deployment URL
|
||||
3. Mark as deployed if successful
|
||||
109
.opencode/skills/docs/SKILL.md
Normal file
109
.opencode/skills/docs/SKILL.md
Normal file
@@ -0,0 +1,109 @@
|
||||
---
|
||||
name: docs
|
||||
description: Documents API endpoints, generates wiki structure, and tracks documentation coverage
|
||||
category: development
|
||||
---
|
||||
|
||||
# Documentation Engineer
|
||||
|
||||
Documents API endpoints, maintains wiki structure, and reports documentation gaps.
|
||||
|
||||
## When to Use
|
||||
|
||||
```
|
||||
/docs
|
||||
/docs api
|
||||
/docs wiki
|
||||
/docs check
|
||||
```
|
||||
|
||||
## Sub-Commands
|
||||
|
||||
### `/docs api`
|
||||
Scans `src/` for API endpoints and updates `docs/api/`.
|
||||
|
||||
### `/docs wiki`
|
||||
Suggests or updates wiki structure in `docs/wiki/`.
|
||||
|
||||
### `/docs check`
|
||||
Reports which endpoints/classes lack documentation.
|
||||
|
||||
## Skill Steps
|
||||
|
||||
### 1. Scan for API Endpoints
|
||||
- Search `src/` for route files (REST patterns: `*Route.php`, `*Controller.php`)
|
||||
- Search for HTTP method annotations: `@Route`, `@Get`, `@Post`, `@Put`, `@Delete`
|
||||
- Detect endpoint patterns in plain PHP files
|
||||
|
||||
### 2. Update API Documentation
|
||||
- Create/update `docs/api/ENDPOINTS.md` with endpoint inventory
|
||||
- Create individual files per resource: `docs/api/users.md`, `docs/api/tasks.md`
|
||||
- Format:
|
||||
|
||||
```markdown
|
||||
# Users API
|
||||
|
||||
## Endpoints
|
||||
|
||||
| Method | Path | Description |
|
||||
|--------|------|-------------|
|
||||
| GET | /api/users | List all users |
|
||||
| GET | /api/users/{id} | Get single user |
|
||||
| POST | /api/users | Create user |
|
||||
| PUT | /api/users/{id} | Update user |
|
||||
| DELETE | /api/users/{id} | Delete user |
|
||||
|
||||
## Request/Response Examples
|
||||
|
||||
### GET /api/users
|
||||
**Response:**
|
||||
```json
|
||||
{
|
||||
"data": [...],
|
||||
"total": 42,
|
||||
"page": 1,
|
||||
"per_page": 20
|
||||
}
|
||||
```
|
||||
```
|
||||
|
||||
### 3. Wiki Structure
|
||||
If `docs/wiki/` doesn't exist, suggest structure:
|
||||
|
||||
```
|
||||
docs/wiki/
|
||||
├── README.md <- Wiki home
|
||||
├── getting-started.md <- Setup guide
|
||||
├── api-reference.md <- API overview
|
||||
├── database.md <- DB schema
|
||||
└── deployment.md <- Hosting guide
|
||||
```
|
||||
|
||||
### 4. Documentation Coverage Report
|
||||
Track which classes/features have docs:
|
||||
|
||||
| Class/File | Has Docs | Last Updated |
|
||||
|------------|----------|--------------|
|
||||
| UserController | ✅ docs/api/users.md | 2026-01-15 |
|
||||
| TaskController | ❌ missing | - |
|
||||
|
||||
## Output
|
||||
|
||||
- `docs/api/*.md` - API endpoint documentation
|
||||
- `docs/wiki/README.md` - Wiki home (if created)
|
||||
- Coverage report printed to user
|
||||
|
||||
## Rules
|
||||
|
||||
- Use English for all documentation content
|
||||
- One endpoint file per resource
|
||||
- Include request/response examples
|
||||
- Document error responses (400, 401, 403, 404, 500)
|
||||
- Keep docs in sync with code (check on every run)
|
||||
|
||||
## Context Recovery
|
||||
|
||||
If context is compacted:
|
||||
1. Re-scan `src/` for endpoint files
|
||||
2. Check which docs already exist
|
||||
3. Continue from missing documentation
|
||||
59
.opencode/skills/frontend/SKILL.md
Normal file
59
.opencode/skills/frontend/SKILL.md
Normal file
@@ -0,0 +1,59 @@
|
||||
---
|
||||
name: frontend
|
||||
description: Builds UI components with React, Tailwind CSS, and shadcn/ui
|
||||
category: development
|
||||
---
|
||||
|
||||
# Frontend Developer
|
||||
|
||||
Builds the UI components for a feature using React, Next.js, Tailwind CSS, and shadcn/ui.
|
||||
|
||||
## When to Use
|
||||
|
||||
```
|
||||
/frontend features/PROJ-X-feature-name.md
|
||||
```
|
||||
|
||||
## Skill Steps
|
||||
|
||||
1. **Read context**
|
||||
- Read `features/INDEX.md` for feature overview
|
||||
- Read the feature spec for requirements
|
||||
- Check existing components: `ls src/components/ui/`
|
||||
|
||||
2. **Check shadcn/ui availability**
|
||||
- List installed components in `src/components/ui/`
|
||||
- Install missing with: `npx shadcn@latest add <component-name>`
|
||||
|
||||
3. **Implement UI**
|
||||
- Build components in `src/components/` and `src/app/`
|
||||
- Use existing shadcn/ui components (NEVER recreate)
|
||||
- Follow Tailwind CSS patterns
|
||||
- Add TypeScript types
|
||||
|
||||
4. **Write tests**
|
||||
- Unit tests next to source files (`*.test.ts` next to `*.ts`)
|
||||
|
||||
5. **Lint**
|
||||
- Run `npm run lint` after changes
|
||||
|
||||
6. **Update tracking**
|
||||
- Mark feature as "Frontend Done" in `features/INDEX.md`
|
||||
|
||||
7. **Suggest next step**
|
||||
- Recommend `/backend` or `/qa` next
|
||||
|
||||
## Rules
|
||||
|
||||
- **shadcn/ui first**: Always check `src/components/ui/` before creating new components
|
||||
- **Tailwind CSS**: Use utility classes, never raw CSS
|
||||
- **TypeScript**: All components must be typed
|
||||
- **Tests**: Write unit tests for all components
|
||||
- **Lint**: Run lint after every change
|
||||
|
||||
## Context Recovery
|
||||
|
||||
If context is compacted:
|
||||
1. Re-read feature spec
|
||||
2. Check `git diff` for uncommitted changes
|
||||
3. Continue implementation
|
||||
@@ -16,15 +16,22 @@ skeleton/
|
||||
├── .gitignore ✓
|
||||
├── AGENTS.md ✓
|
||||
├── .opencode/
|
||||
│ ├── settings.json ✓
|
||||
│ ├── config/project.md ✓
|
||||
│ ├── rules/ ✓
|
||||
│ └── skills/ ✓
|
||||
├── .codex/
|
||||
│ ├── config/project.md ✓
|
||||
│ └── prompts/ ✓
|
||||
├── .shared/prompts/ ✓
|
||||
├── docs/
|
||||
│ ├── doku/ ✓
|
||||
│ └── planung/ ✓
|
||||
├── www/
|
||||
│ ├── api/public/ ✓
|
||||
│ ├── game/public/ ✓
|
||||
│ └── www/public/ ✓
|
||||
└── README.md ✓
|
||||
```
|
||||
│ └── <domain>/
|
||||
│ ├── doku/ ✓
|
||||
│ ├── planung/ ✓
|
||||
│ └── todos/ ✓
|
||||
├── features/
|
||||
│ ├── INDEX.md ✓
|
||||
│ └── README.md ✓
|
||||
└── www/
|
||||
└── <domain>/
|
||||
└── public/ ✓
|
||||
```
|
||||
90
.opencode/skills/php/SKILL.md
Normal file
90
.opencode/skills/php/SKILL.md
Normal file
@@ -0,0 +1,90 @@
|
||||
---
|
||||
name: php
|
||||
description: Builds PHP code, database migrations, and PHPUnit tests
|
||||
category: development
|
||||
---
|
||||
|
||||
# PHP Developer
|
||||
|
||||
Builds PHP code, database migrations, and tests for a feature.
|
||||
|
||||
## When to Use
|
||||
|
||||
```
|
||||
/php features/PROJ-X-feature-name.md
|
||||
```
|
||||
|
||||
## Skill Steps
|
||||
|
||||
1. **Read context**
|
||||
- Read `features/INDEX.md` for feature overview
|
||||
- Read the feature spec for requirements and tech design
|
||||
- Check existing structure: `ls src/`, `ls tests/`
|
||||
|
||||
2. **Implement PHP code**
|
||||
- Create/update classes in `src/` directory
|
||||
- Follow PSR-12 coding standard
|
||||
- Use typed properties and return types
|
||||
- Add `declare(strict_types=1);` to all PHP files
|
||||
|
||||
3. **Implement migrations**
|
||||
- Add migration file in `migrations/` directory
|
||||
- Use portable SQL (see `docs/production/database-portability.md`)
|
||||
- Use `IF NOT EXISTS` for idempotency
|
||||
|
||||
4. **Write tests**
|
||||
- PHPUnit tests in `tests/` directory
|
||||
- Test one thing per method
|
||||
- Test both happy path and error paths
|
||||
|
||||
5. **Run checks**
|
||||
- `composer lint` (fix any style issues)
|
||||
- `composer analyze` (fix any static analysis errors)
|
||||
- `composer test` (all tests must pass)
|
||||
|
||||
6. **Update tracking**
|
||||
- Mark feature as "Implemented" in `features/INDEX.md`
|
||||
|
||||
7. **Suggest next step**
|
||||
- Recommend `/qa` next
|
||||
|
||||
## Tech Design Section Format (for feature specs)
|
||||
|
||||
```markdown
|
||||
## Tech Design
|
||||
|
||||
### Classes
|
||||
- `UserRepository`: handles user CRUD operations
|
||||
- `UserService`: business logic for users
|
||||
|
||||
### Database Schema
|
||||
```sql
|
||||
CREATE TABLE users (
|
||||
id INTEGER PRIMARY KEY,
|
||||
email TEXT NOT NULL UNIQUE,
|
||||
name TEXT NOT NULL,
|
||||
created_at DATETIME DEFAULT CURRENT_TIMESTAMP
|
||||
);
|
||||
```
|
||||
|
||||
### Implementation Order
|
||||
1. Create migration
|
||||
2. Implement UserRepository
|
||||
3. Implement UserService
|
||||
4. Write tests
|
||||
```
|
||||
|
||||
## Rules
|
||||
|
||||
- **PSR-12**: All code follows PSR-12 coding standard
|
||||
- **Strict types**: All files start with `declare(strict_types=1);`
|
||||
- **Parameterized queries**: Never interpolate user input into SQL
|
||||
- **Portable SQL**: Works on SQLite, MariaDB, and PostgreSQL
|
||||
- **Tests**: Write tests for all new classes/methods
|
||||
|
||||
## Context Recovery
|
||||
|
||||
If context is compacted:
|
||||
1. Re-read feature spec
|
||||
2. Check `git status` for uncommitted changes
|
||||
3. Continue from next class/method to implement
|
||||
64
.opencode/skills/qa/SKILL.md
Normal file
64
.opencode/skills/qa/SKILL.md
Normal file
@@ -0,0 +1,64 @@
|
||||
---
|
||||
name: qa
|
||||
description: Tests features against acceptance criteria and performs security audit
|
||||
category: development
|
||||
---
|
||||
|
||||
# QA Engineer
|
||||
|
||||
Tests a feature implementation against its acceptance criteria and performs a security audit.
|
||||
|
||||
## When to Use
|
||||
|
||||
```
|
||||
/qa features/PROJ-X-feature-name.md
|
||||
```
|
||||
|
||||
## Skill Steps
|
||||
|
||||
1. **Read context**
|
||||
- Read the feature spec, especially:
|
||||
- Acceptance criteria
|
||||
- User stories
|
||||
- Edge cases
|
||||
|
||||
2. **Run tests**
|
||||
- `npm test` - Unit/integration tests
|
||||
- `npm run test:e2e` - E2E tests (requires dev server)
|
||||
|
||||
3. **Manual testing**
|
||||
- Start dev server: `npm run dev`
|
||||
- Test each acceptance criterion manually
|
||||
- Test edge cases
|
||||
|
||||
4. **Security audit**
|
||||
- Check for exposed secrets in code
|
||||
- Verify auth is properly implemented
|
||||
- Check input validation
|
||||
|
||||
5. **Report results**
|
||||
- Document what passed/failed
|
||||
- List any bugs found
|
||||
- Identify fixes needed
|
||||
|
||||
6. **Fix failures**
|
||||
- Fix any test failures
|
||||
- Fix any acceptance criteria not met
|
||||
- Re-run tests until all pass
|
||||
|
||||
7. **Update tracking**
|
||||
- Mark feature as "QA Passed" in `features/INDEX.md`
|
||||
|
||||
## Rules
|
||||
|
||||
- All acceptance criteria must pass
|
||||
- All tests must pass (unit + E2E)
|
||||
- No security vulnerabilities
|
||||
- Fix all failures before declaring done
|
||||
|
||||
## Context Recovery
|
||||
|
||||
If context is compacted:
|
||||
1. Re-read feature spec
|
||||
2. Check which tests have passed
|
||||
3. Continue from failures
|
||||
90
.opencode/skills/requirements/SKILL.md
Normal file
90
.opencode/skills/requirements/SKILL.md
Normal file
@@ -0,0 +1,90 @@
|
||||
---
|
||||
name: requirements
|
||||
description: Creates feature specs with user stories, acceptance criteria, and edge cases
|
||||
category: development
|
||||
---
|
||||
|
||||
# Requirements Engineer
|
||||
|
||||
Creates detailed feature specifications for the AI Coding Starter Kit workflow.
|
||||
|
||||
## When to Use
|
||||
|
||||
Run this skill when you want to add a new feature to the project. It:
|
||||
1. Reads the existing PRD to understand project context
|
||||
2. Checks the feature index for the next available ID
|
||||
3. Creates a feature spec with user stories, acceptance criteria, and edge cases
|
||||
4. Updates the feature tracking index
|
||||
|
||||
## Usage
|
||||
|
||||
```
|
||||
/requirements
|
||||
```
|
||||
|
||||
Then describe your feature idea. The skill will ask follow-up questions to clarify scope.
|
||||
|
||||
## Skill Steps
|
||||
|
||||
1. **Read project context**
|
||||
- Read `docs/PRD.md` for project vision and constraints
|
||||
- Read `features/INDEX.md` to see existing features and next PROJ-X ID
|
||||
|
||||
2. **Clarify requirements** (interactive)
|
||||
- Ask about target users
|
||||
- Ask about core functionality
|
||||
- Ask about MVP scope
|
||||
- Ask about edge cases to handle
|
||||
|
||||
3. **Create feature spec**
|
||||
- Create file `features/PROJ-X-feature-name.md`
|
||||
- Include: Feature name, ID, user stories, acceptance criteria, edge cases, dependencies
|
||||
|
||||
4. **Update tracking**
|
||||
- Update `features/INDEX.md` with new feature status (Pending)
|
||||
|
||||
5. **Suggest next step**
|
||||
- Recommend running `/architecture` next
|
||||
|
||||
## Output
|
||||
|
||||
- `features/PROJ-X-feature-name.md` - The feature specification
|
||||
- Updated `features/INDEX.md` - Feature tracking updated
|
||||
|
||||
## Feature Spec Format
|
||||
|
||||
```markdown
|
||||
# Feature: [Name]
|
||||
|
||||
## ID
|
||||
PROJ-X
|
||||
|
||||
## Status
|
||||
Pending
|
||||
|
||||
## User Stories
|
||||
- As a [role], I want [action], so that [benefit]
|
||||
- ...
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] Criterion 1 (testable)
|
||||
- [ ] Criterion 2 (testable)
|
||||
|
||||
## Edge Cases
|
||||
- Case 1: description
|
||||
- Case 2: description
|
||||
|
||||
## Dependencies
|
||||
- PROJ-Y (required first)
|
||||
- ...
|
||||
|
||||
## Tech Design
|
||||
(Added later by /architecture skill)
|
||||
```
|
||||
|
||||
## Context Recovery
|
||||
|
||||
If context is compacted mid-task:
|
||||
1. Re-read `docs/PRD.md` and `features/INDEX.md`
|
||||
2. Check if feature spec was already created
|
||||
3. Continue from where you left off
|
||||
Reference in New Issue
Block a user