@lvlup-sw/exarchos 2.5.0 → 2.6.1

package/skills/shared/prompts/report-format.md

@@ -1,54 +0,0 @@
-# Standard Report Format
-
-## Task Completion Report
-
-When reporting task completion, use this format:
-
-```markdown
-## Task Complete: [Task ID]
-
-### Files Modified
-- `path/to/file.ts` - [Brief change description]
-- `path/to/test.ts` - [Tests added]
-
-### Tests
-- **Added:** [Count] new tests
-- **Status:** PASS / FAIL
-- **Coverage:** [X]% (if available)
-
-### TDD Verification
-- [x] Test failed first (RED confirmed)
-- [x] Test passes after implementation (GREEN confirmed)
-- [x] No extra code beyond requirements
-
-### Issues (if any)
-- [Issue description and resolution]
-
-### Status
-**COMPLETE** / **BLOCKED** (reason)
-```
-
-## Review Report
-
-When reporting review results:
-
-```markdown
-## Review: [Type] - [Task ID]
-
-### Verdict
-**PASS** / **FAIL** / **NEEDS_FIXES**
-
-### Findings
-
-#### HIGH Priority
-1. [Issue] - File: `path:line` - Fix: [Required action]
-
-#### MEDIUM Priority
-1. [Issue] - File: `path:line` - Suggestion: [Recommended action]
-
-#### LOW Priority
-1. [Observation] - File: `path:line`
-
-### Summary
-[1-2 sentence summary of review results]
-```

package/skills/shared/prompts/tdd-requirements.md

@@ -1,39 +0,0 @@
-# TDD Requirements
-
-## The Iron Law
-
-> **NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST**
-
-## Process
-
-1. **RED**: Write a failing test
-   - Test must fail for the expected reason
-   - Run tests to confirm failure
-   - Verify the failure message matches expectations
-
-2. **GREEN**: Write minimum code to pass
-   - Only implement what's needed to pass the test
-   - No extra features or "nice to have" code
-   - Run tests to confirm passing
-
-3. **REFACTOR**: Clean up (optional)
-   - Improve code quality while keeping tests green
-   - Apply SOLID principles where beneficial
-   - Run tests after each refactor
-
-## Test Naming
-
-Follow: `MethodName_Scenario_ExpectedOutcome`
-
-Examples:
-- `CreateUser_ValidInput_ReturnsUserId`
-- `CreateUser_EmptyEmail_ThrowsValidationError`
-- `GetUser_NonExistentId_ReturnsNull`
-
-## Verification
-
-Before marking complete:
-- [ ] Test failed first (witnessed the RED)
-- [ ] Test passes after implementation (confirmed GREEN)
-- [ ] No extra code beyond test requirements
-- [ ] All related tests still pass

package/skills/shared/references/coding-standards.md

@@ -1,46 +0,0 @@
----
-paths: "**/*.ts", "**/*.tsx", "**/*.cs"
----
-
-# Coding Standards
-
-Apply these standards when reviewing or writing TypeScript or C# code.
-
-## SOLID Constraints
-
-| Principle | TypeScript | C# |
-|-----------|-----------|-----|
-| **S**RP | One primary component/class per file | One public type per file; filename matches type name |
-| **O**CP | Discriminated unions or strategy pattern, not type switches | No `switch` on types/enums for logic; use polymorphism |
-| **L**SP | Implement all interface methods fully | Subclasses must not throw `NotImplementedException` |
-| **I**SP | Small focused interfaces, composed as needed | Small role-specific interfaces (e.g., `IReadable`, `IWritable`) |
-| **D**IP | Depend on interfaces, inject implementations | All dependencies via constructor injection; never `new` concrete services |
-
-## Control Flow
-
-- **Guard clauses first**: Validate/narrow at function entry
-- **Early return**: Exit immediately when conditions fail
-- **No arrow code**: Flatten nested conditionals with early returns
-- **Extract complexity**: Complex conditions into named predicates/helpers
-
-## Error Handling
-
-| Pattern | TypeScript | C# |
-|---------|-----------|-----|
-| Recoverable errors | Result types (consider `neverthrow`) | `Result<T>` pattern |
-| Programmer errors | Custom error classes with discriminated unions | Exceptions + `ArgumentNullException.ThrowIfNull()` |
-| Silent catches | Never — always handle or rethrow | Never — always handle or rethrow |
-| Boundaries | Explicit error boundaries at API/UI layers | Explicit error boundaries at API/UI layers |
-
-## Code Organization (DRY)
-
-- Extract duplicated logic into utility functions/helpers
-- Use built-in collection methods (TS: `map`/`filter`/`reduce`; C#: LINQ)
-- Leverage standard utility types (TS: `Partial`, `Pick`, `Omit`; C#: generics, records)
-- Do not re-implement standard library functionality
-
----
-
-For TypeScript-specific standards, see `@skills/quality-review/references/typescript-standards.md`.
-
-For C#-specific standards, see `@skills/dotnet-standards/references/csharp-standards.md`.

package/skills/shared/references/mcp-tool-guidance.md

@@ -1,39 +0,0 @@
----
-name: mcp-tool-guidance
-description: "Prefer specialized MCP tools over generic CLI approaches."
----
-
-# MCP Tool Guidance
-
-Use specialized MCP tools over generic approaches:
-
-1. **Workflow state** — Exarchos MCP, never manual JSON
-2. **PR creation** — GitHub CLI (`gh pr create --base <base-branch> --title "..." --body "..."`)
-3. **State management** — `exarchos_workflow` set/get, never edit JSON directly
-
-> Additional tool guidance (Serena, GitHub MCP, Context7) is provided by optional companions. Install: `npx create-exarchos`
-
-## Describe Before You Guess
-
-The four Exarchos composite tools (`exarchos_workflow`, `exarchos_event`, `exarchos_orchestrate`, `exarchos_view`) each have a `describe` action that returns live schemas. **Use `describe` before guessing parameter shapes:**
-
-| Need to know… | Call |
-|----------------|------|
-| Event payload fields | `exarchos_event describe eventTypes=["team.spawned", ...]` |
-| Guard prerequisites for a phase transition | `exarchos_workflow describe playbook="<workflowType>"` |
-| Orchestrate action parameters | `exarchos_orchestrate describe actions=["task_complete", ...]` |
-| View action parameters | `exarchos_view describe actions=["synthesis_readiness", ...]` |
-
-This eliminates trial-and-error discovery. One `describe` call costs fewer tokens than a failed call + retry.
-
-## Quick Reference — `exarchos_workflow`
-
-Before calling, consult `@skills/workflow-state/references/mcp-tool-reference.md` for full action signatures, error handling, and anti-patterns.
-
-| Action | Key Parameters |
-|--------|---------------|
-| `get` | `featureId`, optional `query` (dot-path) or `fields` (string array for projection) |
-| `set` | `featureId`, `updates` (object), `phase` (string) — send both in one call for guarded transitions |
-| `init` | `featureId`, `workflowType` (`"feature"` / `"debug"` / `"refactor"`) |
-| `cleanup` | `featureId`, `mergeVerified: true`, `prUrl`, `mergedBranches` |
-| `cancel` | `featureId`, optional `dryRun: true` |

package/skills/shared/references/skill-path-resolution.md

@@ -1,10 +0,0 @@
----
-name: skill-path-resolution
-description: "Resolve @skills/<name>/SKILL.md paths to ~/.claude/skills/<name>/SKILL.md."
----
-
-# Skill Path Resolution
-
-`@skills/<name>/SKILL.md` resolves to `~/.claude/skills/<name>/SKILL.md`.
-
-When encountered: read the skill file, follow its instructions, use templates from its directory. If not found, report to user and fall back to inline instructions.

package/skills/shared/references/tdd.md

@@ -1,58 +0,0 @@
----
-paths: "**/*.ts", "**/*.tsx", "**/*.cs"
----
-
-# TDD Rules
-
-Enforce strict TDD when modifying TypeScript or C# files.
-
-## TDD Workflow
-
-### RED Phase
-1. Write a test that describes expected behavior
-2. Run tests — test MUST fail
-3. Verify it fails for the RIGHT reason (not a compilation error)
-
-### GREEN Phase
-1. Write the minimum code to make the test pass
-2. Run tests — test MUST pass
-3. No extra features or optimizations
-
-### REFACTOR Phase
-1. Clean up code while tests stay green
-2. Extract helpers, improve naming, apply SOLID
-3. Run tests after each change
-
-## Conventions
-
-| | TypeScript | C# |
-|--|-----------|-----|
-| Framework | Vitest | TUnit |
-| Test files | `foo.test.ts` (co-located) | `Foo.Tests.cs` (co-located) |
-| Naming | `Method_Scenario_Outcome` | `Method_Scenario_Outcome` |
-| Run | `npm run test:run` | `dotnet test` |
-| Pattern | Arrange / Act / Assert | Arrange / Act / Assert |
-| Mocking | `vi.mock()`, `vi.fn()` | NSubstitute (`Substitute.For<T>()`) |
-| PBT | `@fast-check/vitest` | FsCheck |
-
-For test code patterns and examples, see `@skills/delegation/references/testing-patterns.md`.
-For property-based testing templates, see `@skills/delegation/references/pbt-patterns.md`.
-
-Property tests are written alongside example tests in the RED phase. They complement, not replace, example tests.
-
-## Sociable vs Solitary Tests
-
-Default to **sociable tests** — tests that use real collaborator objects rather than mocks. This aligns with the Testing Trophy model where integration tests give the best confidence-per-effort ratio.
-
-**When to use real collaborators (default):**
-- Logic dependencies (pure computation, no side effects)
-- Value objects (immutable data carriers)
-- In-process collaborators that are fast and deterministic
-
-**When to mock (solitary tests):**
-- External services (HTTP APIs, third-party integrations)
-- Non-deterministic resources (system clock, random number generators)
-- Slow dependencies (databases, network calls, filesystem)
-- When simulating specific error conditions
-
-**Guideline:** If a test requires >3 mocked dependencies, consider whether the test is at the wrong layer. A unit test with heavy mocking may be better written as an integration test with real collaborators.

package/skills/shared/references/telemetry-awareness.md

@@ -1,9 +0,0 @@
----
-name: telemetry-awareness
-description: "Apply telemetryHints from session-start output to subsequent MCP tool calls."
----
-
-# Telemetry Awareness
-
-When `telemetryHints` appear in session-start output, apply the suggested
-optimizations to subsequent MCP tool calls for the remainder of the session.