oh-my-githubcopilot 1.4.1 → 1.8.0-alpha.021bf87

package/skills/session/SKILL.md

@@ -0,0 +1,220 @@
+---
+name: session
+description: Worktree and tmux session management. Use for "new session", "worktree", "tmux", and "session management".
+trigger: "session:, /session, /omp:session"
+autoinvoke: false
+---
+# Skill: Session
+
+## Metadata
+
+| Field | Value |
+|-------|-------|
+| **ID** | `session` |
+| **Keywords** | `session:`, `/session` |
+| **Tier** | Developer Tool |
+| **Source** | `src/skills/session.mts` |
+
+## Description
+
+Manage development sessions with git worktrees and tmux. Create, attach, detach, list, and end sessions with isolated worktrees for parallel development.
+
+## Differentiation from psm
+
+| Aspect | session | psm |
+|--------|---------|-----|
+| **Scope** | Git worktrees + tmux sessions for development isolation | OMP Plugin State Manager — inspect and update plugin runtime state |
+| **Manages** | Branches, worktrees, tmux windows/panes, session lifecycle | OMP internal state, session metadata, plugin config values |
+| **Use when** | You need to create/switch/end a development context | You need to inspect or modify OMP's running plugin state |
+
+## Interface
+
+```typescript
+interface SkillInput {
+  trigger: string;
+  args: string[];
+}
+
+interface SkillOutput {
+  status: "ok" | "error";
+  message: string;
+}
+
+export async function activate(input: SkillInput): Promise<SkillOutput>
+export function deactivate(): void
+```
+
+## Implementation
+
+Spawns `bin/omp.mjs session [args]`. No persistent resources are maintained.
+
+## When to Use
+
+- Creating new branches
+- Managing multiple tasks
+- Isolating work
+- Session recovery
+- Parallel development
+
+## Session Types
+
+### Development Session
+- Feature work
+- Bug fixes
+- Single focused task
+
+### Exploration Session
+- Research
+- Prototyping
+- Proof of concept
+
+### Review Session
+- Code review
+- Pair programming
+- Pair review
+
+## Worktree Management
+
+### Create Worktree
+```bash
+git worktree add {path} {branch}
+```
+
+### List Worktrees
+```bash
+git worktree list
+```
+
+### Remove Worktree
+```bash
+git worktree remove {path}
+```
+
+### Worktree for Feature
+```
+{project}-feature-{name}
+```
+
+## Tmux Session Management
+
+### Session Structure
+```
+session:{project}
+  └── window:feature-{name}
+      └── pane: editor
+      └── pane: terminal
+      └── pane: tests
+```
+
+### Commands
+```bash
+# Create session
+tmux new-session -s {name} -d
+
+# Attach
+tmux attach -t {name}
+
+# List
+tmux list-sessions
+
+# Kill
+tmux kill-session -t {name}
+```
+
+## Session Workflow
+
+### Start New Feature
+1. Create worktree
+2. Start tmux session
+3. Set up windows/panes
+4. Track session info
+5. Begin work
+
+### Switch Context
+1. Detach current session
+2. Attach target session
+3. Resume work
+
+### End Session
+1. Commit changes
+2. Push if needed
+3. Clean up tmux
+4. Optionally remove worktree
+5. Log session summary
+
+## Commands
+
+### Start Session
+```
+/omp:session start {name}
+```
+
+### Attach Session
+```
+/omp:session attach {name}
+```
+
+### Detach Session
+```
+/omp:session detach
+```
+
+### List Sessions
+```
+/omp:session list
+```
+
+### End Session
+```
+/omp:session end {name}
+```
+
+### Create Worktree
+```
+/omp:session worktree create {branch} {path}
+```
+
+## State
+
+Session state is stored in `.omp/sessions/`. Each session has a JSON record with worktree path, branch, tmux session name, and timestamps.
+
+## Output Format
+
+```
+## Session: {name}
+
+### Type
+{type}
+
+### Worktree
+**Path:** {path}
+**Branch:** {branch}
+**Status:** {clean|dirty}
+
+### Tmux
+**Session:** {tmux-session}
+**Windows:** {n}
+**Created:** {date}
+**Last active:** {date}
+
+### Windows
+| Window | Panes | Current |
+|--------|-------|---------|
+| {name} | {n} | {yes/no} |
+
+### Recent Sessions
+| Name | Type | Last Active | Status |
+|------|------|-------------|--------|
+| {name} | {type} | {date} | {active/ended} |
+
+### Session Notes
+{notes}
+```
+
+## Constraints
+
+- Clean up completed sessions
+- Don't forget worktree paths
+- Keep session names unique
+- Document session purpose
+- Backup before major changes

package/skills/setup/SKILL.md

@@ -1,3 +1,9 @@
+---
+name: setup
+description: OMP setup and onboarding wizard
+trigger: "setup:, /setup, /omp:setup"
+autoinvoke: false
+---
 # Skill: Setup
 
 ## Metadata

package/skills/skillify/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: skillify
+description: Turn a repeatable workflow from the current session into a reusable OMP skill draft
+triggers:
+  - /omp:skillify
+---
+
+# Skillify
+
+Use this skill when the current session uncovered a repeatable workflow that should become a reusable OMP skill.
+
+## Goal
+Capture a successful multi-step workflow as a concrete skill draft instead of rediscovering it later.
+
+## Workflow
+1. Identify the repeatable task the session accomplished.
+2. Extract:
+   - inputs
+   - ordered steps
+   - success criteria
+   - constraints / pitfalls
+   - best target location for the skill
+3. Decide whether the workflow belongs as:
+   - a repo built-in skill (in `skills/` directory of oh-my-githubcopilot)
+   - a project learned skill (in `.omp/skills/<skill-name>.md`)
+   - documentation only
+4. When drafting a learned skill file, output a complete skill file that starts with YAML frontmatter.
+   - Never emit plain markdown-only skill files.
+   - Minimum frontmatter:
+     ```yaml
+     ---
+     name: <skill-name>
+     description: <one-line description>
+     triggers:
+       - /omp:<skill-name>
+       - <keyword-trigger>
+     ---
+     ```
+   - Write learned/project skills to:
+     - `.omp/skills/<skill-name>.md`
+   - Write repo built-in skills to:
+     - `skills/<skill-name>/SKILL.md` in the oh-my-githubcopilot repo
+     - `src/skills/<skill-name>.mts` in the oh-my-githubcopilot repo
+5. Draft the rest of the skill file with clear triggers, steps, and success criteria.
+6. Point out anything still too fuzzy to encode safely.
+
+## State Paths
+
+OMP state uses the `.omp/` prefix:
+- `.omp/skills/` — project-local learned skills
+- `.omp/state/` — runtime state
+- `.omp/notepad.md` — working notepad
+
+## Rules
+- Only capture workflows that are actually repeatable.
+- Keep the skill practical and scoped.
+- Prefer explicit success criteria over vague prose.
+- If the workflow still has unresolved branching decisions, note them before drafting.
+- Use `omp:` prefix for all skill references, never `omc:` or `oma:`.
+- Do not output model parameters (haiku/sonnet/opus) in skill files.
+
+## Output
+- Proposed skill name
+- Target location (repo built-in or `.omp/skills/`)
+- Draft workflow structure
+- Open questions, if any

package/skills/spending/SKILL.md

@@ -1,3 +1,9 @@
+---
+name: spending
+description: Track and reset premium request usage
+trigger: "spending:, /spending, /omp:spending"
+autoinvoke: false
+---
 # Skill: Spending
 
 ## Metadata

package/skills/swarm/SKILL.md

@@ -1,3 +1,9 @@
+---
+name: swarm
+description: Parallel agent swarm for independent subtasks
+trigger: "swarm:, /swarm, /omp:swarm"
+autoinvoke: false
+---
 # Skill: Swarm
 
 ## Metadata

package/skills/swe-bench/SKILL.md

@@ -1,3 +1,9 @@
+---
+name: swe-bench
+description: SWE-bench evaluation harness runner
+trigger: "swe-bench:, /swe-bench, /omp:swe-bench"
+autoinvoke: false
+---
 # Skill: SWE-Bench
 
 ## Metadata

package/skills/tdd/SKILL.md

@@ -0,0 +1,246 @@
+---
+name: tdd
+description: Test-Driven Development with Red-Green-Refactor cycle, vertical slices, and tracer bullets
+triggers:
+  - /omp:tdd
+  - tdd:
+---
+
+# TDD — Test-Driven Development
+
+Use this skill when implementing any feature or bugfix using the Red-Green-Refactor cycle. Write the failing test first, write minimal code to pass it, then refactor.
+
+## <Do_Not_Use_When>
+
+- **Exploratory prototyping** — When you are still discovering the problem space and requirements are unclear, writing tests first creates a moving target and wastes cycles. Explore first, then TDD once the interface stabilizes.
+- **One-off automation scripts** — Scripts with no expected reuse, no downstream consumers, and no need for regression coverage. A quick one-liner in a REPL is faster and cleaner.
+- **Trivial boilerplate** — Generating getters/setters, scaffolding files, or copy-paste patterns that carry no behavioral logic.
+- **UI/visual refinements** — Tweaking colors, spacing, or copy where the "right behavior" is subjective and visual inspection beats assertions.
+- **Learning a new API** — When experimenting with unfamiliar SDKs or frameworks, write scratch code to build intuition first. Add tests once the API shape is stable.
+- **Performance optimization passes** — Before measuring, you do not know what is slow. Tests written for correctness can conflict with benchmarks. Keep them separate.
+
+---
+
+## Red-Green-Refactor Cycle
+
+The core TDD loop has exactly three phases. Never skip or reorder them.
+
+### RED: Write a focused failing test
+Write a test that describes the behavior you want. Run it — it must fail. A test that passes before any implementation is written is not a test, it is a false signal.
+
+### GREEN: Write minimal code to pass
+Write the smallest amount of production code that makes the test pass. Do not write code for future requirements. Do not generalize. Make the test green and stop.
+
+### REFACTOR: Clean up with tests green
+With the test green, clean up the implementation — remove duplication, improve naming, extract deep modules. Run tests after every edit. If they go red, revert immediately.
+
+Repeat this cycle for each behavioral slice.
+
+---
+
+## <Tool_Usage>
+
+| Tool | When to Use |
+|------|-------------|
+| `Bash` (test runner) | Run `npm test`, `pytest`, `go test`, or equivalent to get fast per-file feedback during RED-GREEN cycles. |
+| `Write` / `Edit` | Write failing test first (RED), then write minimal production code (GREEN), then clean up (REFACTOR). |
+| `mcp__plugin_oh-my-claudecode_t__lsp_diagnostics` | Catch type errors and missing imports immediately after edits. |
+| `mcp__plugin_oh-my-claudecode_t__lsp_diagnostics_directory` | Run full project diagnostics before marking a cycle done. |
+| `Grep` | Find existing tests for the same module before writing a new one — avoid duplication. |
+| `Glob` | Locate test files matching the module under development. |
+
+**Typical cycle:**
+1. Write a failing test (RED) — `Write` to the test file.
+2. Run the test runner via `Bash` to confirm the failure.
+3. Write minimal code to pass (GREEN) — `Edit` the production file.
+4. Run diagnostics — `mcp__plugin_oh-my-claudecode_t__lsp_diagnostics` on both files.
+5. Refactor (REFACTOR) — `Edit` production code, confirm tests stay green.
+6. Repeat.
+
+---
+
+## <Why_This_Exists>
+
+TDD provides a tight feedback loop that keeps implementation anchored to behavior. Without it, code grows inward — implementation details proliferate, coupling increases, and tests (when written at all) fight the code instead of guiding it.
+
+The OMP-specific variant emphasizes **vertical slices via tracer bullets** rather than horizontal layering. Horizontal TDD (write all tests for Layer A, then all for Layer B) produces integration gaps: every layer compiles in isolation but the system fails end-to-end. Vertical TDD traces one complete path from user input to data storage before moving to the next slice, delivering working software incrementally.
+
+Deep modules are preferred because they minimize the interface surface you must test, making each test more powerful and easier to reason about. A large, well-hidden implementation behind a small interface is easier to verify, easier to refactor, and cheaper to change.
+
+---
+
+## <Examples>
+
+### RED: Write a focused failing test
+
+A test for a user-authentication module:
+
+```typescript
+// auth.test.ts
+import { authenticate } from './auth';
+
+describe('authenticate', () => {
+  it('returns a session token when credentials are valid', async () => {
+    const token = await authenticate({ username: 'alice', password: 'secret123' });
+    expect(token).toMatch(/^[a-z0-9]{32}$/);
+  });
+
+  it('throws AuthError when password is incorrect', async () => {
+    await expect(
+      authenticate({ username: 'alice', password: 'wrong' })
+    ).rejects.toThrow('Invalid credentials');
+  });
+});
+```
+
+Notice: tests describe **what** the function returns and **when** it throws — not **how** it works internally.
+
+---
+
+### GREEN: Write minimal code
+
+```typescript
+// auth.ts
+import crypto from 'crypto';
+
+export class AuthError extends Error {
+  constructor(message: string) {
+    super(message);
+    this.name = 'AuthError';
+  }
+}
+
+const VALID_CREDENTIALS = { alice: 'secret123' };
+
+export async function authenticate({
+  username,
+  password,
+}: {
+  username: string;
+  password: string;
+}): Promise<string> {
+  const expected = VALID_CREDENTIALS[username];
+  if (!expected || expected !== password) {
+    throw new AuthError('Invalid credentials');
+  }
+  return crypto.randomBytes(16).toString('hex');
+}
+```
+
+This is the **minimum** code to make both tests pass. It is not the final architecture — it is the seed. The test survives refactoring because it tests behavior, not implementation.
+
+---
+
+### REFACTOR: Hide complexity behind a deep module
+
+The first green pass exposes that the credentials check and token generation are interleaved. Refactor to a deep module:
+
+```typescript
+// credentials.ts  (deep module — small interface, large hidden implementation)
+const STORE = new Map<string, string>(); // currently in-memory; swap to DB later
+
+export async function checkCredentials(username: string, password: string): Promise<boolean> {
+  const stored = STORE.get(username);
+  return stored !== undefined && stored === password;
+}
+
+export async function addCredential(username: string, password: string): Promise<void> {
+  // future: hash before storing
+  STORE.set(username, password);
+}
+```
+
+The `authenticate` function becomes a thin, shallow orchestrator that delegates to deep modules. Tests for `authenticate` do not change — they only test the public interface.
+
+---
+
+### Vertical Slice: User signup end-to-end
+
+**Slice 1 — Register and retrieve a user**
+
+```typescript
+// user.test.ts
+it('stores a user and retrieves them by id', async () => {
+  const id = await registerUser({ username: 'bob', password: 'pw' });
+  const user = await getUser(id);
+  expect(user.username).toBe('bob');
+});
+```
+
+Write minimal code: in-memory store, `registerUser` writes to it, `getUser` reads back.
+
+**Slice 2 — Reject duplicate usernames**
+
+```typescript
+it('throws DuplicateError when username is already taken', async () => {
+  await registerUser({ username: 'bob', password: 'pw' });
+  await expect(
+    registerUser({ username: 'bob', password: 'pw2' })
+  ).rejects.toThrow('Duplicate username');
+});
+```
+
+Add the check to the existing `registerUser` — no new classes, no abstraction layers yet.
+
+**Slice 3 — Persist to database**
+
+Swap the in-memory store for a real DB adapter. Tests pass unchanged because the interface is the same.
+
+Horizontal TDD would have written all in-memory tests, then all DB tests, then all business-logic tests — producing a large integration gap before any slice works end-to-end. Vertical TDD delivered a working registration flow after Slice 1.
+
+---
+
+## <Escalation_And_Stop_Conditions>
+
+### Escalate when:
+
+- **Test is flaky or environment-dependent** — A test that passes locally but fails in CI is noise, not signal. Escalate to omp architect to design a stable test fixture strategy.
+- **The interface is unstable** — If the "right" public API is unclear after 3 cycles, stop. The problem definition is incomplete. Escalate to omp analyst to refine requirements.
+- **A refactor breaks many tests** — Tests that fail because implementation details changed indicate the tests are testing internals. This is a signal to re-examine what the public interface should be. Escalate before continuing.
+- **You are writing tests that replicate production logic** — If your test re-implements the function under test to verify it, you are testing the wrong thing. Escalate to omp verifier for a second opinion.
+
+### Stop when:
+
+- All tests in the current slice pass and `lsp_diagnostics_directory` reports zero errors.
+- The per-cycle checklist (below) is satisfied.
+- The vertical slice connects all layers — input, business logic, and storage — in a working path.
+- Next steps require business decisions (e.g., which user flow to slice next) — those belong to omp analyst or the user.
+
+---
+
+## <Per-Cycle_Checklist>
+
+Run through these before marking a TDD cycle complete:
+
+- [ ] **Is this test focused on a PUBLIC interface, not internals?**
+  Test `authenticate(params)` — not `authenticate._tokenCache` or any private state.
+
+- [ ] **Does the test describe BEHAVIOR, not implementation?**
+  "returns a session token when credentials are valid" is behavior.
+  "calls `crypto.randomBytes`" is implementation — avoid it.
+
+- [ ] **Will this test SURVIVE refactoring?**
+  If you refactor `credentials.ts` internals, does this test still pass?
+  If not, the test is coupled to internals — rewrite it.
+
+- [ ] **Is the code I wrote the MINIMAL amount to pass?**
+  No early optimization. No generalized abstractions. No extra parameters.
+  Write what makes the test pass, nothing more.
+
+- [ ] **Is this slice vertical — does it span from input to storage?**
+  If you only added a DB call without connecting it to the public API, the slice is incomplete.
+
+---
+
+## <Final_Checklist>
+
+Before declaring a TDD skill session complete:
+
+- [ ] All new test files exist and are committed to the repo alongside production files.
+- [ ] `npm test` (or equivalent) runs green with zero failures.
+- [ ] `lsp_diagnostics_directory` reports zero errors across the modified package.
+- [ ] No `TODO`, `HACK`, `debugger`, or `console.log` statements remain in production or test code.
+- [ ] Tracer-bullet slices are connected: at least one complete vertical path (input → logic → storage) is working and tested end-to-end.
+- [ ] Tests are named for the behavior they verify, not the method they call.
+- [ ] Deep modules are used for complex internals; orchestrators stay thin.
+- [ ] Any new skill-worthy pattern (3+ repetitions of the same logic) is noted and escalated to omp analyst for skill extraction.

package/skills/team/SKILL.md

@@ -1,3 +1,9 @@
+---
+name: team
+description: Coordinated N-agent team with staged pipeline
+trigger: "team:, /team, /omp:team"
+autoinvoke: false
+---
 # Skill: Team
 
 ## Metadata

package/skills/trace/SKILL.md

@@ -1,3 +1,9 @@
+---
+name: trace
+description: Execution tracing and debugging
+trigger: "trace:, /trace, /omp:trace"
+autoinvoke: false
+---
 # Skill: Trace
 
 ## Metadata

package/skills/ultrawork/SKILL.md

@@ -1,3 +1,9 @@
+---
+name: ultrawork
+description: Parallel multi-agent high-throughput implementation
+trigger: "ulw:, ultrawork:, /ulw, /ultrawork, /omp:ulw, /omp:ultrawork"
+autoinvoke: false
+---
 # Skill: Ultrawork
 
 ## Metadata

package/skills/wiki/SKILL.md

@@ -1,3 +1,9 @@
+---
+name: wiki
+description: Project wiki operations and management
+trigger: "wiki:, /wiki, /omp:wiki"
+autoinvoke: false
+---
 # Skill: Wiki
 
 ## Metadata