oh-my-opencode-lite 0.1.0

package/src/skills/sdd-spec/SKILL.md

@@ -0,0 +1,105 @@
+---
+name: sdd-spec
+description: Write OpenSpec delta specs with RFC 2119 language and GWT scenarios.
+---
+
+# SDD Spec Skill
+
+Write or update the change specifications for one or more affected domains.
+
+## Shared Conventions
+
+- Shared references:
+- `~/.config/opencode/skills/_shared/openspec-convention.md`
+- `~/.config/opencode/skills/_shared/persistence-contract.md`
+- `~/.config/opencode/skills/_shared/thoth-mem-convention.md`
+
+## Persistence Mode
+
+The orchestrator passes the artifact store mode (`thoth-mem`, `openspec`, or
+`hybrid`). Follow
+`~/.config/opencode/skills/_shared/persistence-contract.md` for read/write
+rules per mode.
+
+- `thoth-mem`: persist to thoth-mem only — do NOT create or modify
+  `openspec/` files.
+- `openspec`: write files only — do NOT call thoth-mem save tools.
+- `hybrid`: persist to both (default).
+
+## When to Use
+
+- A proposal is approved and must be converted into testable requirements
+- Existing change specs need to be expanded or corrected
+
+## Prerequisites
+
+- `change-name`
+- The proposal artifact must exist
+- Access to any current main specs for impacted domains
+
+## Workflow
+
+1. Read the shared conventions.
+2. Recover the proposal using the retrieval protocol in
+   `~/.config/opencode/skills/_shared/persistence-contract.md`.
+3. If the change already has spec work, recover `sdd/{change-name}/spec` with
+   the same mode-aware retrieval rules before editing.
+4. Read `openspec/specs/{domain}/spec.md` for each affected domain to determine
+   whether you are writing a delta spec or a brand-new spec.
+5. If the selected mode includes OpenSpec, write canonical change artifacts
+   under `openspec/changes/{change-name}/specs/{domain}/spec.md`. In
+   `thoth-mem` mode, produce the same canonical content without creating files.
+6. Use this structure in every spec file:
+
+   ```md
+   # Delta for {Domain}
+
+   ## ADDED Requirements
+   ### Requirement: {Name}
+   The system MUST ...
+
+   #### Scenario: {Name}
+   - GIVEN ...
+   - WHEN ...
+   - THEN ...
+
+   ## MODIFIED Requirements
+   ## REMOVED Requirements
+   ```
+
+   For a brand-new domain, write a full spec instead of a delta.
+
+7. If the selected mode includes thoth-mem, persist the complete spec payload
+   with:
+
+   ```text
+   thoth_mem_mem_save(
+     title: "sdd/{change-name}/spec",
+     topic_key: "sdd/{change-name}/spec",
+     type: "architecture",
+     project: "{project}",
+     scope: "project",
+     content: "{full spec markdown across all domains}"
+   )
+   ```
+
+## Output Format
+
+Return:
+
+- `Change`
+- `Artifacts`: list of domain spec paths written
+- `Topic Key`: `sdd/{change-name}/spec`
+- `Coverage Summary`: requirements and scenarios added or modified
+- `Next Step`: usually `sdd-design`
+
+## Rules
+
+- Every requirement must use RFC 2119 keywords.
+- Every requirement must have at least one Given/When/Then scenario.
+- Specs describe behavior, not implementation details.
+- Keep domain boundaries explicit.
+- Use the retrieval protocol from
+  `~/.config/opencode/skills/_shared/persistence-contract.md` for every SDD
+  dependency.
+- Never reference engram.

package/src/skills/sdd-tasks/SKILL.md

@@ -0,0 +1,116 @@
+---
+name: sdd-tasks
+description: Generate phased `tasks.md` checklists from specs and design.
+---
+
+# SDD Tasks Skill
+
+Translate the approved spec and design into an implementation checklist.
+
+## Shared Conventions
+
+- Shared references:
+- `~/.config/opencode/skills/_shared/openspec-convention.md`
+- `~/.config/opencode/skills/_shared/persistence-contract.md`
+- `~/.config/opencode/skills/_shared/thoth-mem-convention.md`
+
+## Persistence Mode
+
+The orchestrator passes the artifact store mode (`thoth-mem`, `openspec`, or
+`hybrid`). Follow
+`~/.config/opencode/skills/_shared/persistence-contract.md` for read/write
+rules per mode.
+
+- `thoth-mem`: persist to thoth-mem only — do NOT create or modify
+  `openspec/` files.
+- `openspec`: write files only — do NOT call thoth-mem save tools.
+- `hybrid`: persist to both (default).
+
+## When to Use
+
+- Proposal, spec, and design are ready for execution planning
+- A task plan must be refreshed after design or scope changes
+
+## Prerequisites
+
+- `change-name`
+- Proposal artifact
+- Spec artifact
+- Design artifact
+
+## Workflow
+
+1. Read the shared conventions.
+2. Recover `proposal`, `spec`, and `design` via the retrieval protocol in
+   `~/.config/opencode/skills/_shared/persistence-contract.md`.
+3. If a task plan already exists, recover `sdd/{change-name}/tasks` with the
+   same mode-aware retrieval rules before rewriting it.
+4. Build a phased checklist for `openspec/changes/{change-name}/tasks.md`. In
+   `thoth-mem` mode, produce the same canonical checklist content without
+   creating the file.
+5. Use hierarchical numbering and Markdown checkboxes:
+
+   ```md
+   # Tasks: {Change Title}
+
+   ## Phase 1: Foundation
+   - [ ] 1.1 ...
+
+   ## Phase 2: Core Implementation
+   - [ ] 2.1 ...
+
+   ## Phase 3: Integration
+   - [ ] 3.1 ...
+
+   ## Phase 4: Verification
+   - [ ] 4.1 ...
+   ```
+
+   Recognized task states:
+
+   - `- [ ]` pending
+   - `- [~]` in progress
+   - `- [x]` completed
+   - `- [-]` skipped with reason
+
+6. Reference concrete file paths and specific spec scenarios in the tasks.
+7. If the selected mode includes thoth-mem, persist the full checklist with:
+
+   ```text
+   thoth_mem_mem_save(
+     title: "sdd/{change-name}/tasks",
+     topic_key: "sdd/{change-name}/tasks",
+     type: "architecture",
+     project: "{project}",
+     scope: "project",
+     content: "{full tasks markdown}"
+   )
+   ```
+
+8. After generating `tasks.md`, the orchestrator should offer the user an
+   optional oracle plan review with the bundled `plan-reviewer` skill before
+   execution begins.
+9. If the user wants plan review, run the `[OKAY]` / `[REJECT]` loop until the
+   review returns `[OKAY]`. On each `[REJECT]`, fix only blocking issues,
+   limit each rejection to max 3 issues, then re-run the review.
+
+## Output Format
+
+Return:
+
+- `Change`
+- `Artifact`: `openspec/changes/{change-name}/tasks.md`
+- `Topic Key`: `sdd/{change-name}/tasks`
+- `Phase Summary`: task counts per phase
+- `Execution Order`: one short paragraph
+- `Next Step`: `sdd-apply`
+
+## Rules
+
+- Tasks must be small, actionable, and verifiable.
+- Order tasks by dependency.
+- Include testing and verification work explicitly.
+- Do not create vague tasks such as “implement feature”.
+- Retrieve all dependencies through the mode-aware protocol in
+  `~/.config/opencode/skills/_shared/persistence-contract.md`.
+- Never reference engram.

package/src/skills/sdd-verify/SKILL.md

@@ -0,0 +1,102 @@
+---
+name: sdd-verify
+description: Verify implementation against specs and persist a compliance report.
+---
+
+# SDD Verify Skill
+
+Act as the quality gate for a change by turning specs and test evidence into a
+verification report.
+
+## Shared Conventions
+
+- Shared references:
+- `~/.config/opencode/skills/_shared/openspec-convention.md`
+- `~/.config/opencode/skills/_shared/persistence-contract.md`
+- `~/.config/opencode/skills/_shared/thoth-mem-convention.md`
+
+## Persistence Mode
+
+The orchestrator passes the artifact store mode (`thoth-mem`, `openspec`, or
+`hybrid`). Follow
+`~/.config/opencode/skills/_shared/persistence-contract.md` for read/write
+rules per mode.
+
+- `thoth-mem`: persist to thoth-mem only — do NOT create or modify
+  `openspec/` files.
+- `openspec`: write files only — do NOT call thoth-mem save tools.
+- `hybrid`: persist to both (default).
+
+## When to Use
+
+- Implementation work is complete enough to validate
+- A prior verification report must be refreshed after more code changes
+
+## Prerequisites
+
+- `change-name`
+- Spec artifact
+- Design artifact
+- Tasks artifact
+- Ability to run the relevant checks or tests
+
+## Workflow
+
+1. Read the shared conventions.
+2. Recover `spec`, `design`, and `tasks` with the retrieval protocol in
+   `~/.config/opencode/skills/_shared/persistence-contract.md`.
+3. Optionally recover `apply-progress` with the same mode-aware rules if it
+   exists and helps explain task coverage.
+4. Read the changed code and run the required verification commands.
+5. If the selected mode includes OpenSpec, create
+   `openspec/changes/{change-name}/verify-report.md` with at least:
+
+   In `thoth-mem` mode, produce the same report content without creating the
+   file:
+
+   ```md
+   # Verification Report: {Change Title}
+
+   ## Completeness
+   ## Build and Test Evidence
+   ## Spec Compliance Matrix
+   ## Design Coherence
+   ## Issues Found
+   ## Verdict
+   ```
+
+6. Build a compliance matrix that maps each Given/When/Then scenario to the test
+   or execution evidence that proved it.
+7. If the selected mode includes thoth-mem, persist the report with:
+
+   ```text
+   thoth_mem_mem_save(
+     title: "sdd/{change-name}/verify-report",
+     topic_key: "sdd/{change-name}/verify-report",
+     type: "architecture",
+     project: "{project}",
+     scope: "project",
+     content: "{full verify report markdown}"
+   )
+   ```
+
+## Output Format
+
+Return:
+
+- `Change`
+- `Artifact`: `openspec/changes/{change-name}/verify-report.md`
+- `Topic Key`: `sdd/{change-name}/verify-report`
+- `Verdict`: pass, pass with warnings, or fail
+- `Compliance Summary`: compliant vs total scenarios
+- `Critical Issues`: bullets or `None`
+
+## Rules
+
+- Verification requires real evidence, not only static inspection.
+- Every spec scenario must appear in the compliance matrix.
+- Distinguish blockers from warnings clearly.
+- Do not fix issues inside this phase; report them.
+- Recover full artifacts with the protocol in
+  `~/.config/opencode/skills/_shared/persistence-contract.md`.
+- Never reference engram.