oh-my-opencode-lite 0.1.1 → 0.1.3

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

@@ -36,14 +36,20 @@ rules per mode.
 ## Prerequisites
 
 - `change-name`
+- `pipeline-type` (`accelerated` or `full`)
 - Assigned task numbers or phase range
-- Spec, design, and task artifacts
+- Task artifact
+- Spec and design artifacts (full pipeline only)
+- Proposal artifact (accelerated pipeline — used as the acceptance reference)
 
 ## Workflow
 
 1. Read the shared conventions.
-2. Recover `spec`, `design`, and `tasks` with the retrieval protocol in
-   `~/.config/opencode/skills/_shared/persistence-contract.md`.
+2. Recover artifacts with the retrieval protocol in
+   `~/.config/opencode/skills/_shared/persistence-contract.md`:
+   - **Always**: recover `tasks`
+   - **Full pipeline**: recover `spec` and `design`
+   - **Accelerated pipeline**: recover `proposal` (used as the acceptance reference)
 3. Read the affected code before editing anything.
 4. Execute only the assigned checklist items.
 5. In modes that include thoth-mem, persist an implementation progress report
@@ -65,32 +71,24 @@ rules per mode.
 
 ## Response Format
 
-Return a structured result to the orchestrator:
+Return a structured result to the orchestrator using the Task Result envelope:
 
 **Status**: completed | failed | partial
 **Task**: {task reference}
-**What was done**: {list of concrete changes}
-**Files changed**: {paths with descriptions}
-**Verification**: {check results}
-**Issues**: {any problems encountered}
-**Failure/Skip reason**: {if applicable}
+
+**What was done**: concrete list of changes
+**Files changed**: paths with descriptions
+**Verification**: check results (passed/failed)
+**Issues**: problems encountered with severity
+**Failure/Skip reason**: if applicable
 
 Progress tracking (checkbox state updates) is managed by the orchestrator
 via the `executing-plans` skill. Do not update task checkboxes yourself.
 
-## Output Format
-
-Return:
-
-- `Change`
-- `Completed Tasks`: assigned items completed or partially completed
-- `Files Changed`: concise table or bullets
-- `Progress Topic Key`: `sdd/{change-name}/apply-progress` when applicable
-- `Remaining Work`: next known pending work or blockers
-
 ## Rules
 
-- Read specs before implementing; they are the acceptance contract.
+- Read the acceptance contract before implementing: specs in full pipeline,
+  proposal in accelerated pipeline.
 - Follow the design unless you explicitly report a justified deviation.
 - Update only the tasks assigned in the current batch.
 - Persist the progress artifact whenever the selected mode includes thoth-mem.
@@ -98,4 +96,3 @@ Return:
   `~/.config/opencode/skills/_shared/persistence-contract.md`.
 - Return structured execution evidence to the orchestrator so it can manage task
   state correctly.
-- Never reference engram.

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

@@ -35,22 +35,27 @@ rules per mode.
 ## Prerequisites
 
 - `change-name`
-- Spec artifact
-- Design artifact
+- `pipeline-type` (`accelerated` or `full`)
 - Tasks artifact
 - Verify report artifact
+- Spec artifact (full pipeline only)
+- Design artifact (full pipeline only)
+- Proposal artifact (always — used for audit trail)
 
 ## Workflow
 
 1. Read the shared conventions.
-2. Recover `spec`, `design`, `tasks`, and `verify-report` through the
-   retrieval protocol in
-   `~/.config/opencode/skills/_shared/persistence-contract.md`.
+2. Recover artifacts through the retrieval protocol in
+   `~/.config/opencode/skills/_shared/persistence-contract.md`:
+   - **Always**: recover `proposal`, `tasks`, and `verify-report`
+   - **Full pipeline only**: recover `spec` and `design`
 3. Refuse to archive if the verification report still contains unresolved
    critical failures.
-4. If the selected mode includes OpenSpec, merge every change spec from
+4. If the selected mode includes OpenSpec and the pipeline is full, merge
+   every change spec from
    `openspec/changes/{change-name}/specs/{domain}/spec.md` into
-   `openspec/specs/{domain}/spec.md`.
+   `openspec/specs/{domain}/spec.md`. In accelerated pipeline, skip the
+   spec merge (no delta specs exist).
 5. If the selected mode includes OpenSpec, move the completed change directory
    to `openspec/changes/archive/YYYY-MM-DD-{change-name}/`.
 6. Create an audit trail report summarizing merged domains, archive location,
@@ -84,11 +89,11 @@ Return:
 ## Rules
 
 - Archive only after verification is acceptable.
-- Merge delta specs before moving the change folder.
+- In full pipeline, merge delta specs before moving the change folder.
+  In accelerated pipeline, skip the spec merge (no delta specs exist).
 - Preserve canonical spec structure and untouched requirements.
 - Persist the final audit trail through thoth-mem when the selected mode
   includes it.
 - Use the retrieval protocol in
   `~/.config/opencode/skills/_shared/persistence-contract.md` for every
   dependency.
-- Never reference engram.

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

@@ -101,4 +101,3 @@ Return:
 - Keep implementation details aligned with the spec and repository patterns.
 - Retrieve full dependencies with the protocol in
   `~/.config/opencode/skills/_shared/persistence-contract.md`.
-- Never reference engram.

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

@@ -0,0 +1,157 @@
+---
+name: sdd-init
+description: Bootstrap OpenSpec structure and SDD context for a project.
+metadata:
+  author: gentleman-programming
+  version: "1.0"
+---
+
+# SDD Init Skill
+
+Initialize SDD for a project by detecting local conventions, creating the
+minimal OpenSpec structure when needed, and persisting startup context.
+
+## 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 initialization context to thoth-mem only — do NOT create
+  or modify `openspec/` files.
+- `openspec`: create or update OpenSpec structure only — do NOT call thoth-mem
+  save tools.
+- `hybrid`: do both (default).
+
+## When to Use
+
+- SDD is needed but `openspec/` is not initialized
+- A new project needs initial OpenSpec conventions
+- The team wants detected stack/context captured before `sdd-propose`
+
+## Prerequisites
+
+- Project root path
+- Project name
+- Selected persistence mode (default: `hybrid`)
+
+## Workflow
+
+1. Read the shared conventions before initializing.
+2. Detect project stack and conventions from repository files:
+   - Stack indicators: `package.json`, `go.mod`, `pyproject.toml`,
+     `requirements.txt`, `Cargo.toml`, `pom.xml`, `build.gradle`,
+     `composer.json`.
+   - Testing indicators: `vitest.config.*`, `jest.config.*`,
+     `playwright.config.*`, `pytest.ini`, `tox.ini`, `go test` conventions,
+     `Cargo.toml` test crates.
+   - Style indicators: `biome.json`, `.eslintrc*`, `eslint.config.*`,
+     `.prettierrc*`, `ruff.toml`, `.golangci.*`, `rustfmt.toml`.
+   - CI indicators: `.github/workflows/*`, `.gitlab-ci.yml`,
+     `azure-pipelines.yml`, `.circleci/config.yml`.
+   - Architecture hints: common layout markers such as `apps/`, `packages/`,
+     `services/`, `src/`, `cmd/`, `internal/`.
+3. Build concise config context (max 10 lines) using detected values. Use
+   `unknown` for missing signals.
+4. If the selected mode includes OpenSpec (`openspec` or `hybrid`), check
+   whether these already exist:
+   - `openspec/config.yaml`
+   - `openspec/specs/`
+   - `openspec/changes/`
+5. If all required OpenSpec paths already exist, report what exists and ask the
+   orchestrator whether `config.yaml` should be updated. Do not overwrite by
+   default.
+6. If any required OpenSpec path is missing and mode includes OpenSpec, create
+   only the minimum structure:
+
+   ```text
+   openspec/
+   ├── config.yaml
+   ├── specs/
+   └── changes/
+       └── archive/
+   ```
+
+7. Generate `openspec/config.yaml` dynamically with this shape:
+
+   ```yaml
+   schema: spec-driven
+
+   context: |
+     Tech stack: {detected}
+     Architecture: {detected}
+     Testing: {detected}
+     Style: {detected}
+
+   rules:
+     proposal:
+       - Include rollback plan for risky changes
+       - Identify affected modules/packages
+     specs:
+       - Use Given/When/Then format for scenarios
+       - Use RFC 2119 keywords (MUST, SHALL, SHOULD, MAY)
+     design:
+       - Include sequence diagrams for complex flows
+       - Document architecture decisions with rationale
+     tasks:
+       - Group tasks by phase (infrastructure, implementation, testing)
+       - Use hierarchical numbering (1.1, 1.2, etc.)
+       - Keep tasks small enough to complete in one session
+     apply:
+       - Follow existing code patterns and conventions
+       tdd: false
+       test_command: ''
+     verify:
+       test_command: ''
+       build_command: ''
+       coverage_threshold: 0
+     archive:
+       - Warn before merging destructive deltas
+   ```
+
+8. Never create placeholder SDD artifacts (`proposal.md`, `design.md`,
+   `tasks.md`, or spec files) during initialization.
+9. If the selected mode includes thoth-mem (`thoth-mem` or `hybrid`), persist
+   the detected context and initialization status with:
+
+   ```text
+   thoth_mem_mem_save(
+     title: "sdd-init/{project-name}",
+     topic_key: "sdd-init/{project-name}",
+     type: "config",
+     project: "{project-name}",
+     scope: "project",
+     content: "What: ...\nWhy: ...\nWhere: ...\nLearned: ..."
+   )
+   ```
+
+10. In `hybrid` mode, initialization is complete only when both OpenSpec setup
+    and thoth-mem persistence succeed.
+
+## Output Format
+
+Return:
+
+- `Project`
+- `Mode`
+- `Detected Context`: stack, architecture, testing, style, CI
+- `OpenSpec Status`: initialized, already initialized, or skipped by mode
+- `Created Paths`: list of directories/files created (if any)
+- `Topic Key`: `sdd-init/{project-name}` when mode includes thoth-mem
+- `Next Step`: usually `sdd-propose`
+
+## Rules
+
+- Be idempotent: if OpenSpec already exists, report and ask before updates.
+- In `thoth-mem` mode, never create `openspec/` directories or files.
+- Keep `config.yaml` context concise (max 10 lines).
+- Detect and include CI, test, and style conventions in the context summary.
+- Never create placeholder spec/change files during init.

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

@@ -87,7 +87,7 @@ Return a short report with:
 - `Artifact`: `openspec/changes/{change-name}/proposal.md`
 - `Topic Key`: `sdd/{change-name}/proposal`
 - `Summary`: 2-4 bullets covering intent, scope, and major risks
-- `Next Step`: usually `sdd-spec` or `sdd-design`
+- `Next Step`: `sdd-spec` (full pipeline) or `sdd-tasks` (accelerated pipeline)
 
 ## Rules
 
@@ -95,5 +95,6 @@ Return a short report with:
 - Keep the proposal focused on why, scope, and success criteria.
 - Always include rollback guidance and explicit out-of-scope items.
 - Never reference engram.
-- Never rely on a `thoth_mem_mem_search` preview without calling
-  `thoth_mem_mem_get_observation` when the selected mode uses thoth-mem.
+- Never rely on `thoth_mem_mem_search` output alone when the mode uses
+  thoth-mem. Follow the 3-layer recall protocol: `search(mode: "compact")` →
+  `timeline` → `get_observation` to retrieve the full artifact body.

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

@@ -101,5 +101,4 @@ Return:
 - Keep domain boundaries explicit.
 - Use the retrieval protocol from
   `~/.config/opencode/skills/_shared/persistence-contract.md` for every SDD
-  dependency.
-- Never reference engram.
+  dependency.

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

@@ -28,21 +28,26 @@ rules per mode.
 
 ## When to Use
 
-- Proposal, spec, and design are ready for execution planning
-- A task plan must be refreshed after design or scope changes
+- **Full pipeline**: proposal, spec, and design are ready for execution planning
+- **Accelerated pipeline**: proposal is ready and spec/design are intentionally skipped
+- A task plan must be refreshed after scope changes
 
 ## Prerequisites
 
 - `change-name`
+- `pipeline-type` (`accelerated` or `full`)
 - Proposal artifact
-- Spec artifact
-- Design artifact
+- Spec artifact (full pipeline only)
+- Design artifact (full pipeline only)
 
 ## Workflow
 
 1. Read the shared conventions.
-2. Recover `proposal`, `spec`, and `design` via the retrieval protocol in
-   `~/.config/opencode/skills/_shared/persistence-contract.md`.
+2. Recover artifacts via the retrieval protocol in
+   `~/.config/opencode/skills/_shared/persistence-contract.md`:
+   - **Always**: recover `proposal`
+   - **Full pipeline only**: recover `spec` and `design`
+   - In accelerated pipeline, derive task structure directly from the proposal.
 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
@@ -113,4 +118,3 @@ Return:
 - 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

@@ -35,16 +35,21 @@ rules per mode.
 ## Prerequisites
 
 - `change-name`
-- Spec artifact
-- Design artifact
 - Tasks artifact
+- `pipeline-type` (`accelerated` or `full`)
+- Spec artifact (full pipeline only)
+- Design artifact (full pipeline only)
+- Proposal artifact (accelerated pipeline — used as the verification reference)
 - 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`.
+2. Recover artifacts with the retrieval protocol in
+   `~/.config/opencode/skills/_shared/persistence-contract.md`:
+   - **Always**: recover `tasks`
+   - **Full pipeline**: recover `spec` and `design`
+   - **Accelerated pipeline**: recover `proposal` (used as the verification reference)
 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.
@@ -54,19 +59,22 @@ rules per mode.
    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.
+    ```md
+    # Verification Report: {Change Title}
+
+    ## Completeness
+    ## Build and Test Evidence
+    ## Compliance Matrix
+    <!-- Full pipeline: map Given/When/Then scenarios from spec -->
+    <!-- Accelerated pipeline: map success criteria from proposal -->
+    ## Design Coherence (full pipeline only)
+    ## Issues Found
+    ## Verdict
+    ```
+
+6. Build a compliance matrix: in full pipeline, map each Given/When/Then
+   scenario to evidence; in accelerated pipeline, map each proposal success
+   criterion to evidence.
 7. If the selected mode includes thoth-mem, persist the report with:
 
    ```text
@@ -94,9 +102,9 @@ Return:
 ## Rules
 
 - Verification requires real evidence, not only static inspection.
-- Every spec scenario must appear in the compliance matrix.
+- Every acceptance criterion must appear in the compliance matrix: spec
+  scenarios in full pipeline, proposal success criteria in accelerated pipeline.
 - 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.

package/src/skills/brainstorming/SKILL.md

@@ -1,120 +0,0 @@
----
-name: brainstorming
-description: Clarify ambiguous work, assess scope, and choose the right planning path before implementation.
-metadata:
-  author: oh-my-opencode-lite
-  version: '1.0'
----
-
-# Brainstorming Skill
-
-Use this skill to understand what should be built before implementation starts.
-The goal is clarity, scope calibration, and a user-approved handoff.
-
-## Shared Conventions
-
-- `~/.config/opencode/skills/_shared/thoth-mem-convention.md`
-- `~/.config/opencode/skills/_shared/persistence-contract.md`
-
-## HARD GATE
-
-- Do not implement during brainstorming.
-- Do not write code.
-- Do not patch files.
-- Do not create formal SDD artifacts until the user approves the route.
-
-## Workflow
-
-### Phase 1: Context Gathering
-
-1. Dispatch `@explorer` and `@librarian` in parallel for codebase and external
-   context.
-2. Collect only the minimum context needed to improve questions and reduce user
-   repetition.
-3. Prefer facts from the codebase and known references over asking the user for
-   information the environment can answer.
-
-### Phase 2: Interview
-
-1. Ask 1 question at a time.
-2. Ask at most 5 total questions.
-3. Prefer multiple-choice questions when practical.
-4. Stop early when clarity is already sufficient.
-5. Do not ask for details that the codebase, task artifacts, or gathered
-   context already answer.
-
-### Phase 3: Scope Assessment
-
-Evaluate these 7 scope signals:
-
-1. Multiple views, pages, or user flows
-2. New or modified API endpoints, queries, or data models
-3. Restructuring existing functionality
-4. Affects multiple layers such as frontend and backend, or UI and logic and
-   data
-5. Described in business or UX terms instead of specific code changes
-6. Scope is ambiguous or open-ended
-7. Would likely touch 3 or more files across different directories
-
-Signal mapping:
-
-- `0-1` = trivial
-- `2-4` = medium
-- `5+` = complex
-
-### Phase 4: Approach Proposal
-
-1. Present 2-3 viable options.
-2. For each option, give the main trade-offs.
-3. Mark one option as the recommendation.
-4. Ask the user to confirm the preferred approach before moving on.
-
-### Phase 5: User Approval
-
-Present:
-
-- Summary of understanding
-- Scope classification and why
-- Recommended approach
-- Proposed handoff path
-
-Then wait for explicit user approval.
-
-The user is the sole approver during brainstorming. Do not request oracle
-review here.
-
-### Phase 6: Handoff
-
-Recommend a route based on complexity, then wait for the user to confirm it:
-
-- Trivial (`1-2` files): direct implementation
-- Medium (`3-7` files): accelerated SDD (`propose -> tasks`)
-- Complex (`8+` files): full SDD (`propose -> spec -> design -> tasks`)
-
-Before any SDD generation starts, present the artifact store policy choice:
-
-```text
-How would you like to persist planning artifacts?
-1. thoth-mem — Memory only. Lightest token cost. No repo files.
-2. openspec — Repo files only. Visible and reviewable.
-3. hybrid — Both. Maximum durability, higher token cost.
-Default: hybrid
-```
-
-Do not silently choose the handoff route or artifact store mode. Recommend, ask,
-and wait.
-
-## Guardrails
-
-- Maximum 5 interview questions.
-- Ask only one question at a time.
-- Do not ask what codebase context can answer.
-- Do not skip explicit user approval.
-- Do not auto-select the handoff route.
-
-## Anti-Patterns
-
-- Question dumping
-- Option inflation
-- Premature implementation
-- Silent route selection