beeops 0.1.0

package/skills/bo-log-writer/SKILL.md

@@ -0,0 +1,101 @@
+---
+name: bo-log-writer
+description: Record work logs to JSONL. Extract changes, decisions, error resolutions, and learnings from git diff and conversation context.
+---
+
+# bo-log-writer: Work Log Recording
+
+Record session work to `.claude/beeops/logs/log.jsonl` in JSONL format.
+
+## Procedure
+
+1. Get log path and current timestamp:
+   ```bash
+   LOG_BASE=$(python3 "$(dirname "$(python3 -c "import beeops; print(beeops.__file__)" 2>/dev/null || echo "$BO_CONTEXTS_DIR/../hooks/resolve-log-path.py")")/resolve-log-path.py" 2>/dev/null || python3 hooks/resolve-log-path.py) && mkdir -p "$LOG_BASE" && date '+%Y-%m-%dT%H:%M:%S'
+   ```
+   If the above fails, use the simpler fallback:
+   ```bash
+   LOG_BASE=".claude/beeops/logs" && mkdir -p "$LOG_BASE" && date '+%Y-%m-%dT%H:%M:%S'
+   ```
+2. Check changed files with `git diff --name-only` and `git status`
+3. Extract work content, intent, errors, and learnings from conversation context
+4. Append JSONL entry to `$LOG_BASE/log.jsonl`
+
+## Log Format (JSONL)
+
+File: `$LOG_BASE/log.jsonl`
+One line = one JSON object per work unit. All entries appended to a single file.
+
+```json
+{
+  "timestamp": "2026-03-02T14:30:00",
+  "title": "Brief work title",
+  "category": "implementation | review | design | bugfix | refactor | research | meta",
+  "changes": [{ "file": "src/domain/foo.ts", "description": "Added validation" }],
+  "decisions": [
+    { "what": "What was decided", "why": "Rationale", "alternatives": "Alternatives considered" }
+  ],
+  "errors": [
+    {
+      "message": "Error message",
+      "cause": "Root cause",
+      "solution": "How it was resolved",
+      "tags": ["prisma", "enum"]
+    }
+  ],
+  "learnings": ["Reusable insights"],
+  "patterns": ["Recurring patterns observed"],
+  "remaining": ["Unresolved issues / TODOs"],
+  "skills_used": ["bo-task-decomposer"],
+  "agents_used": ["code-reviewer", "planner"],
+  "commands_used": ["commit", "review"],
+  "resources_created": [{ "type": "skill", "name": "meta-task-planner", "action": "created" }]
+}
+```
+
+### Field Description
+
+| Field               | Required  | Purpose                              |
+| ------------------- | --------- | ------------------------------------ |
+| `timestamp`         | Required  | Chronological tracking               |
+| `title`             | Required  | Summary generation, search           |
+| `category`          | Required  | Pattern classification               |
+| `changes`           | Required  | Change tracking, design change detection |
+| `decisions`         | Required  | Knowledge capture of reasoning       |
+| `errors`            | When applicable | Error knowledge accumulation     |
+| `learnings`         | When applicable | Generic knowledge extraction     |
+| `patterns`          | When applicable | Recurring operation detection    |
+| `remaining`         | When applicable | Remaining issue tracking         |
+| `skills_used`       | When applicable | Usage frequency analysis         |
+| `agents_used`       | When applicable | Usage frequency analysis         |
+| `commands_used`     | When applicable | Usage frequency analysis         |
+| `resources_created` | When applicable | Resource change recording        |
+
+### Omission Rules
+
+- `errors`, `learnings`, `patterns`, `remaining`, `skills_used`, `agents_used`, `commands_used`, `resources_created` may be omitted when not applicable (exclude the key entirely)
+- `decisions` must never be omitted — always record at least one
+- `changes` must come from git diff, never guessed
+
+## Deduplication Check (Required)
+
+Before appending, verify no duplicates exist:
+
+1. Read the last 50 lines of `log.jsonl` with the Read tool
+2. Check if any planned entry's `title` is similar to existing entries
+3. Skip if the same session content has already been recorded
+
+**Dedup criteria (skip if any match):**
+- Exact title match
+- Title keywords match AND same category
+- Same changes (2+ matching file paths) already exist
+- Same category + same file changes recorded within the last 24 hours
+
+## Rules
+
+- **timestamp MUST be obtained via `date` command. LLM must never fabricate timestamps**
+- One log entry = one line (JSONL), appended
+- When multiple turn summaries are provided, append one line per turn
+- Increment timestamp by 1 second between turns to avoid duplicates
+- `decisions` must never be omitted — always record why
+- Logs must be fact-based. No embellishment or opinions

package/skills/bo-review-backend/SKILL.md

@@ -0,0 +1,234 @@
+---
+name: bo-review-backend
+description: Triggered for backend code and API design reviews, INCLUDING after bugfixes and implementation changes. [Required pair: bo-review-security] Auto-trigger after any implementation/bugfix to server-side code (.ts/.js/.py etc., including CLI scripts like bin/*.js), API design docs (doc/design/api), domain models. Use bo-review-frontend for frontend, bo-review-database for DB.
+---
+
+## Usage Contract
+
+When using this skill, always include the following at the beginning of your output:
+
+```
+[SKILL_USED: bo-review-backend]
+```
+
+---
+
+# Backend Review Guide
+
+Checklist for reviewing backend code.
+
+---
+
+## API Design
+
+### RESTful Design
+
+- [ ] Are resource names nouns in plural form (`/users`, `/orders`)?
+- [ ] Are HTTP methods used appropriately?
+
+| Method | Purpose      | Idempotent |
+| ------ | ------------ | ---------- |
+| GET    | Retrieve     | Yes        |
+| POST   | Create       | No         |
+| PUT    | Full update  | Yes        |
+| PATCH  | Partial update | Yes      |
+| DELETE | Delete       | Yes        |
+
+### Status Codes
+
+| Code | Usage                     |
+| ---- | ------------------------- |
+| 200  | Success                   |
+| 201  | Created                   |
+| 204  | Success (no content)      |
+| 400  | Bad request               |
+| 401  | Authentication error      |
+| 403  | Authorization error       |
+| 404  | Resource not found        |
+| 409  | Conflict                  |
+| 422  | Validation error          |
+| 429  | Rate limited              |
+| 500  | Server error              |
+
+### Endpoint Design
+
+- [ ] Does the URL express hierarchical structure (`/users/:id/orders`)?
+- [ ] Are query parameters used appropriately (filtering, sorting, pagination)?
+- [ ] Is the versioning strategy clear (`/v1/users` or Header)?
+
+### Response Design
+
+- [ ] Does it return only the minimum necessary data (Excessive Data Exposure prevention)?
+- [ ] Is pagination implemented (cursor-based recommended)?
+- [ ] Is the response format consistent?
+
+```json
+{
+  "data": { ... },
+  "meta": { "page": 1, "total": 100 },
+  "errors": []
+}
+```
+
+---
+
+## Domain Model
+
+### Entity Design
+
+- [ ] Do entities accurately represent business concepts?
+- [ ] Is the ID generation strategy appropriate (UUID v7 recommended)?
+- [ ] Are invariants maintained?
+
+### Value Objects
+
+- [ ] Are business concepts expressed using primitive types inappropriately?
+- [ ] Are value objects immutable?
+- [ ] Is equality determined by value?
+
+```typescript
+// Bad: primitives
+function processOrder(userId: string, amount: number) {}
+
+// Good: value objects
+function processOrder(userId: UserId, amount: Money) {}
+```
+
+### Domain Logic
+
+- [ ] Is business logic consolidated in domain objects?
+- [ ] Is logic leaking into the service layer?
+- [ ] Are business rules expressed as collections of if/switch statements?
+
+---
+
+## Error Handling
+
+### Error Classification
+
+| Type           | Example              | Response                |
+| -------------- | -------------------- | ----------------------- |
+| Business error | Out of stock         | Notify user             |
+| Technical error| DB connection failed | Retry + alert           |
+| Input error    | Validation failed    | Return details          |
+
+### Exception Handling
+
+- [ ] Are exceptions caught at the appropriate layer?
+- [ ] Are there swallowed exceptions (catch with no action)?
+- [ ] Are retryable errors distinguished?
+
+### Error Response
+
+```json
+{
+  "error": {
+    "code": "INSUFFICIENT_BALANCE",
+    "message": "Insufficient balance",
+    "details": { "required": 1000, "available": 500 }
+  }
+}
+```
+
+- [ ] Are technical details (stack traces, etc.) not exposed?
+- [ ] Are error codes systematic?
+
+---
+
+## Performance
+
+### Database
+
+- [ ] Are there N+1 query problems?
+- [ ] Are appropriate indexes set?
+- [ ] Is unnecessary data being fetched (avoid SELECT \*)?
+- [ ] Is cursor-based pagination used for large datasets?
+
+### Caching
+
+- [ ] Has a caching strategy been considered?
+- [ ] Is cache invalidation handled properly?
+- [ ] Are cache keys appropriate?
+
+| Strategy      | Use case                   |
+| ------------- | -------------------------- |
+| Cache-Aside   | General purpose            |
+| Write-Through | Write consistency priority |
+| Write-Behind  | Write performance priority |
+
+### Async Processing
+
+- [ ] Are heavy operations made asynchronous?
+- [ ] Are timeouts configured?
+- [ ] Is concurrency control appropriate?
+- [ ] Is there a retry strategy (Exponential Backoff)?
+
+---
+
+## Testing
+
+### Unit Tests
+
+- [ ] Is domain logic tested?
+- [ ] Are boundary values tested?
+- [ ] Are error cases tested?
+
+### Integration Tests
+
+- [ ] Are API endpoints tested?
+- [ ] Are external services mocked?
+- [ ] Is database integration tested?
+
+### Test Quality
+
+- [ ] Can tests be read as specifications?
+- [ ] Are tests tightly coupled to implementation details?
+- [ ] Is coverage of critical paths prioritized over raw coverage numbers?
+
+### Cross-Platform Compatibility (Node.js CLI / package.json scripts)
+
+- [ ] Does `package.json` `test` script use a glob pattern? If so, verify it works on **Linux CI** (not just macOS/zsh).
+  - `node --test 'test/**/*.test.js'` fails on Linux because the shell does not expand single-quoted globs
+  - Fix: pass a literal path (`node --test test/cli.test.js`) or use a glob library (`glob` npm package or `--test-reporter` options)
+  - Root cause: macOS/zsh expands globs before passing to node, Linux/sh does not
+
+---
+
+## Code Quality
+
+- [ ] Is Dependency Injection (DI) used appropriately?
+- [ ] Are interfaces and implementations separated?
+- [ ] Are transaction boundaries appropriate?
+- [ ] Is resource cleanup ensured (DB connections, file handles)?
+
+---
+
+## Anti-Pattern Detection
+
+- [ ] Is there business logic in controllers?
+- [ ] Is there domain logic in repositories?
+- [ ] Are there god classes (classes that do everything)?
+- [ ] Are there circular dependencies?
+
+---
+
+## Output Format
+
+```
+## Backend Review Result
+[LGTM / Needs Changes / Needs Discussion]
+
+## Check Results
+| Category | Status | Notes |
+|----------|--------|-------|
+| API Design | OK/NG | ... |
+| Domain Model | OK/NG | ... |
+| Error Handling | OK/NG | ... |
+| Performance | OK/NG | ... |
+| Testing | OK/NG | ... |
+
+## Issues Found
+- Problem: [what is the issue]
+- Location: [file:line_number]
+- Suggestion: [how to fix]
+```

package/skills/bo-review-database/SKILL.md

@@ -0,0 +1,243 @@
+---
+name: bo-review-database
+description: Triggered for DB schema, query, and migration reviews. [Required pair: bo-review-security] Targets: SQL, ORM schema definitions, DB design docs (doc/design/database). PostgreSQL-centric.
+---
+
+## Usage Contract
+
+When using this skill, always include the following at the beginning of your output:
+
+```
+[SKILL_USED: bo-review-database]
+```
+
+---
+
+# Database Review Guide
+
+Checklist for reviewing database design and queries.
+
+---
+
+## Schema Design
+
+### Table Design
+
+- [ ] Are table names clear and consistent (snake_case, plural recommended)?
+- [ ] Are primary keys properly set (UUID v7 recommended)?
+- [ ] Are foreign key constraints set?
+- [ ] Is the normalization level appropriate?
+
+| Normalization | Criteria                        |
+| ------------- | ------------------------------- |
+| 3NF           | Default (most cases)            |
+| Denormalized  | Only when read performance is critical |
+
+### Column Design
+
+- [ ] Are column names semantically clear?
+- [ ] Are data types appropriate?
+
+| Use Case  | Recommended Type (PostgreSQL) |
+| --------- | ----------------------------- |
+| ID        | UUID (v7)                     |
+| Money     | DECIMAL / NUMERIC             |
+| Datetime  | TIMESTAMPTZ                   |
+| JSON      | JSONB (not JSON)              |
+| Text      | TEXT (VARCHAR unnecessary)     |
+| Enum      | ENUM or CHECK constraint      |
+
+- [ ] Is NULL allowance appropriate (default NOT NULL)?
+- [ ] Are default values set?
+
+### Constraints
+
+- [ ] Are UNIQUE constraints set where needed?
+- [ ] Are CHECK constraints enforcing data integrity?
+- [ ] Are CASCADE delete/update settings appropriate?
+
+### Audit Columns
+
+- [ ] Are `created_at` / `updated_at` present?
+- [ ] Are `created_by` / `updated_by` present if needed?
+- [ ] Is `deleted_at` present for soft deletes?
+
+---
+
+## Index Design
+
+### Index Selection
+
+- [ ] Are columns frequently used in WHERE clauses indexed?
+- [ ] Are JOIN condition columns indexed?
+- [ ] Have columns used in ORDER BY / GROUP BY been considered?
+- [ ] Are foreign keys indexed?
+
+### Index Types (PostgreSQL)
+
+| Type   | Use Case                   |
+| ------ | -------------------------- |
+| B-tree | General purpose (default)  |
+| Hash   | Equality comparisons only  |
+| GIN    | Arrays, JSONB, full-text search |
+| GiST   | Geographic, range          |
+| BRIN   | Large data, time-series    |
+
+### Composite Indexes
+
+- [ ] Is column order appropriate (highest selectivity first)?
+- [ ] Has cardinality been considered?
+- [ ] Has a covering index been considered?
+
+### Cautions
+
+- [ ] Are there unnecessary indexes (impact on write performance)?
+- [ ] Has a partial index been considered?
+- [ ] Should the index be created CONCURRENTLY?
+
+---
+
+## Query Optimization
+
+### SELECT
+
+- [ ] Is SELECT \* avoided?
+- [ ] Are only necessary columns fetched?
+- [ ] Is LIMIT used to restrict result count?
+
+### JOIN
+
+- [ ] Are JOIN conditions appropriate?
+- [ ] Are there unnecessary JOINs?
+- [ ] Is JOIN order optimal (start from smaller tables)?
+
+### N+1 Problem
+
+- [ ] Are queries being issued inside loops?
+- [ ] Is necessary data fetched in bulk upfront?
+- [ ] Is Eager Loading / Batch Loading used?
+
+### Subqueries
+
+- [ ] Has replacing subqueries with JOINs been considered?
+- [ ] Are correlated subqueries avoided?
+- [ ] Is the choice between EXISTS and IN appropriate (EXISTS is usually faster)?
+
+### EXPLAIN
+
+- [ ] Has the execution plan (EXPLAIN ANALYZE) been checked?
+- [ ] Has the absence of Seq Scan been verified?
+- [ ] Is there a discrepancy between estimated and actual row counts?
+
+---
+
+## Migrations
+
+### Safe Migrations
+
+- [ ] Can the migration be applied without downtime?
+- [ ] Is a rollback procedure prepared?
+- [ ] Has the impact on large datasets been considered?
+
+### Expand and Contract Pattern
+
+| Phase    | Description                          |
+| -------- | ------------------------------------ |
+| Expand   | Add new structure (maintain compatibility) |
+| Migrate  | Move data to new structure           |
+| Contract | Remove old structure                 |
+
+### Safe Changes
+
+| Change        | Safe Method                                    |
+| ------------- | ---------------------------------------------- |
+| Add column    | NULL-allowed or with default value             |
+| Drop column   | Stop using first, drop later                   |
+| Rename column | Add new column -> migrate data -> drop old     |
+| Type change   | Add new column -> convert data -> swap         |
+
+### Large Data Handling
+
+- [ ] Is batch processing used?
+- [ ] Can progress be checked and resumed?
+- [ ] Is lock time minimized?
+
+---
+
+## Data Integrity
+
+### Transactions
+
+- [ ] Are transaction boundaries appropriate?
+- [ ] Is the isolation level appropriate?
+
+| Isolation Level | Use Case                        |
+| --------------- | ------------------------------- |
+| READ COMMITTED  | General purpose (PostgreSQL default) |
+| REPEATABLE READ | Reports, aggregations           |
+| SERIALIZABLE    | Financial transactions, strict consistency |
+
+- [ ] Has deadlock risk been considered?
+- [ ] Is the choice between optimistic and pessimistic locking appropriate?
+
+### Referential Integrity
+
+- [ ] Are foreign key constraints appropriate?
+- [ ] Is the choice between soft and hard deletes appropriate?
+
+---
+
+## Performance Monitoring
+
+- [ ] Is pg_stat_statements enabled?
+- [ ] Is slow query logging configured?
+- [ ] Are statistics up to date (ANALYZE)?
+- [ ] Is connection pooling properly configured?
+
+### Recommended Tools
+
+| Tool               | Use Case          |
+| ------------------ | ----------------- |
+| EXPLAIN ANALYZE    | Query analysis    |
+| pg_stat_statements | Query statistics  |
+| pgMustard          | Plan visualization|
+| pgBadger           | Log analysis      |
+
+---
+
+## Migration Management
+
+- [ ] Is a migration tool (Flyway, Prisma, etc.) being used?
+- [ ] Are migrations version-controlled?
+- [ ] Are rollback migrations available?
+
+---
+
+## Output Format
+
+```
+## Database Review Result
+[LGTM / Needs Changes / Needs Discussion]
+
+## Check Results
+| Category | Status | Notes |
+|----------|--------|-------|
+| Schema Design | OK/NG | ... |
+| Indexes | OK/NG | ... |
+| Query Optimization | OK/NG | ... |
+| Migrations | OK/NG | ... |
+| Data Integrity | OK/NG | ... |
+
+## Issues Found
+- Problem: [what is the issue]
+- Location: [table name / query]
+- Suggestion: [how to fix]
+```
+
+---
+
+## References
+
+- [PostgreSQL Documentation](https://www.postgresql.org/docs/current/)
+- [Use The Index, Luke](https://use-the-index-luke.com/)
+- [pgMustard](https://www.pgmustard.com/)