@colin4k1024/tsp 2.5.0 → 2.5.2

package/skills/mcp-connector-bridge/SKILL.md

@@ -0,0 +1,132 @@
+---
+name: mcp-connector-bridge
+description: "Active MCP connector polling that integrates external tools (issue trackers, error monitoring, CI) into the heartbeat loop for cross-system discovery."
+origin: ECC
+---
+
+# MCP Connector Bridge
+
+Active MCP connector polling that integrates external tools into the heartbeat loop.
+The difference between an agent that says "here is the fix" vs a loop that opens
+the PR, links the ticket, and pings the channel — by itself.
+
+## When to Activate
+
+- User configures `.claude/connectors.yaml` with active MCP servers
+- Heartbeat scheduler includes connector-based scans
+- User invokes `/heartbeat start` with connector scans configured
+- External event triggers a connector poll
+
+## Core Concept
+
+MCP connectors let the loop touch real tools: issue trackers, error monitoring,
+databases, CI systems, chat platforms. Without connectors, the loop is isolated
+to the local repo. With connectors, it can discover issues from anywhere.
+
+```
+Heartbeat tick
+  │
+  ├─ Local scans (test, lint, type-check)
+  │
+  └─ Connector scans (MCP servers)
+       ├─ GitHub: "List open issues assigned to me"
+       ├─ Sentry: "List unresolved errors in last 24h"
+       └─ Linear: "List my in-progress tasks stale >7d"
+```
+
+## Configuration
+
+Create `.claude/connectors.yaml`:
+
+```yaml
+connectors:
+  - name: "github-issues"
+    server: "github"
+    heartbeatScan: "List open issues assigned to me with label:bug"
+    triageOnNew: true
+    priority: "medium"
+
+  - name: "sentry-errors"
+    server: "sentry"
+    heartbeatScan: "List unresolved errors from last 24 hours"
+    triageOnNew: true
+    priority: "high"
+
+  - name: "linear-tasks"
+    server: "linear"
+    heartbeatScan: "List my in-progress tasks not updated in 7 days"
+    autoGoalOnStale: "7d"
+    priority: "low"
+
+  - name: "slack-mentions"
+    server: "slack"
+    heartbeatScan: "Check unread mentions in engineering channel"
+    triageOnNew: true
+    priority: "low"
+```
+
+## Connector Scan Fields
+
+| Field | Required | Description |
+|-------|----------|-------------|
+| `name` | Yes | Unique connector identifier |
+| `server` | Yes | MCP server name (must be configured in mcp-configs/) |
+| `heartbeatScan` | Yes | Prompt to send to the MCP server |
+| `triageOnNew` | No | Create triage items for new findings |
+| `autoGoalOnStale` | No | Auto-create goal if stale beyond duration |
+| `priority` | No | Default severity for triage items (high/medium/low) |
+| `enabled` | No | Disable without removing (default: true) |
+
+## Health Check
+
+Before polling, verify connector is reachable:
+
+1. Check MCP server is configured in project MCP settings
+2. Verify server responds to basic query
+3. If unreachable: skip this connector, log warning
+4. If reachable: execute heartbeatScan prompt
+
+Builds on existing `pre:mcp-health-check` hook.
+
+## Result Classification
+
+Connector scan results follow the same classification as local scans:
+
+| Finding | Action |
+|---------|--------|
+| New issue discovered | → Triage item (if `triageOnNew: true`) |
+| Stale task detected | → Auto-goal (if `autoGoalOnStale` configured) |
+| No new findings | → Skip silently |
+| Connection failed | → Log warning, skip |
+
+## Integration Points
+
+- **`/heartbeat`**: Connector scans run alongside local scans during each tick
+- **`/triage`**: New connector findings populate the triage inbox
+- **`/goal`**: Stale task connectors can auto-create goals
+- **`mcp-configs/`**: Connector references must match configured MCP servers
+- **MCP health hook**: Validates connectivity before scan
+
+## Hard Bans
+
+- Connectors MUST NOT write to external systems during discovery (read-only scans)
+- Failed connections MUST NOT block local heartbeat scans
+- Connector output MUST be size-limited (prevent token overflow from large responses)
+- Credentials MUST NOT be stored in connectors.yaml (use MCP server config)
+- Polling frequency MUST respect rate limits of external services
+
+## Example Flow
+
+```
+Heartbeat tick (every 30m):
+  Local scans: ✓ tests pass, ✓ lint clean
+  Connector scans:
+    github-issues: Found 2 new bugs → triage inbox
+    sentry-errors: No new errors → skip
+    linear-tasks: 1 task stale 10 days → auto-goal created
+
+Result:
+  2 triage items created from GitHub
+  1 goal created from Linear stale task
+  Total: 3 actions from this tick
+```

package/skills/repo-scan/SKILL.md

@@ -1,22 +1,22 @@
----
-name: repo-scan
-description: Cross-stack source code asset audit — classifies every file, detects embedded third-party libraries, and delivers actionable four-level verdicts per module with interactive HTML reports.
-origin: community
----
-
-# repo-scan
-
-> Every ecosystem has its own dependency manager, but no tool looks across C++, Android, iOS, and Web to tell you: how much code is actually yours, what's third-party, and what's dead weight.
-
-## When to Use
-
-- Taking over a large legacy codebase and need a structural overview
-- Before major refactoring — identify what's core, what's duplicate, what's dead
-- Auditing third-party dependencies embedded directly in source (not declared in package managers)
-- Preparing architecture decision records for monorepo reorganization
-
-## Installation
-
+---
+name: repo-scan
+description: Cross-stack source code asset audit — classifies every file, detects embedded third-party libraries, and delivers actionable four-level verdicts per module with interactive HTML reports.
+origin: community
+---
+
+# repo-scan
+
+> Every ecosystem has its own dependency manager, but no tool looks across C++, Android, iOS, and Web to tell you: how much code is actually yours, what's third-party, and what's dead weight.
+
+## When to Use
+
+- Taking over a large legacy codebase and need a structural overview
+- Before major refactoring — identify what's core, what's duplicate, what's dead
+- Auditing third-party dependencies embedded directly in source (not declared in package managers)
+- Preparing architecture decision records for monorepo reorganization
+
+## Installation
+
 ```bash
 # Fetch only the pinned commit for reproducibility
 mkdir -p ~/.claude/skills/repo-scan
@@ -27,52 +27,52 @@ git fetch --depth 1 origin 2742664
 git checkout --detach FETCH_HEAD
 cp -r . ~/.claude/skills/repo-scan
 ```
-
-> Review the source before installing any agent skill.
-
-## Core Capabilities
-
-| Capability | Description |
-|---|---|
-| **Cross-stack scanning** | C/C++, Java/Android, iOS (OC/Swift), Web (TS/JS/Vue) in one pass |
-| **File classification** | Every file tagged as project code, third-party, or build artifact |
-| **Library detection** | 50+ known libraries (FFmpeg, Boost, OpenSSL…) with version extraction |
-| **Four-level verdicts** | Core Asset / Extract & Merge / Rebuild / Deprecate |
-| **HTML reports** | Interactive dark-theme pages with drill-down navigation |
-| **Monorepo support** | Hierarchical scanning with summary + sub-project reports |
-
-## Analysis Depth Levels
-
-| Level | Files Read | Use Case |
-|---|---|---|
-| `fast` | 1-2 per module | Quick inventory of huge directories |
-| `standard` | 2-5 per module | Default audit with full dependency + architecture checks |
-| `deep` | 5-10 per module | Adds thread safety, memory management, API consistency |
-| `full` | All files | Pre-merge comprehensive review |
-
-## How It Works
-
+
+> Review the source before installing any agent skill.
+
+## Core Capabilities
+
+| Capability | Description |
+|---|---|
+| **Cross-stack scanning** | C/C++, Java/Android, iOS (OC/Swift), Web (TS/JS/Vue) in one pass |
+| **File classification** | Every file tagged as project code, third-party, or build artifact |
+| **Library detection** | 50+ known libraries (FFmpeg, Boost, OpenSSL…) with version extraction |
+| **Four-level verdicts** | Core Asset / Extract & Merge / Rebuild / Deprecate |
+| **HTML reports** | Interactive dark-theme pages with drill-down navigation |
+| **Monorepo support** | Hierarchical scanning with summary + sub-project reports |
+
+## Analysis Depth Levels
+
+| Level | Files Read | Use Case |
+|---|---|---|
+| `fast` | 1-2 per module | Quick inventory of huge directories |
+| `standard` | 2-5 per module | Default audit with full dependency + architecture checks |
+| `deep` | 5-10 per module | Adds thread safety, memory management, API consistency |
+| `full` | All files | Pre-merge comprehensive review |
+
+## How It Works
+
 1. **Classify the repo surface**: enumerate files, then tag each as project code, embedded third-party code, or build artifact.
 2. **Detect embedded libraries**: inspect directory names, headers, license files, and version markers to identify bundled dependencies and likely versions.
 3. **Score each module**: group files by module or subsystem, then assign one of the four verdicts based on ownership, duplication, and maintenance cost.
 4. **Highlight structural risks**: call out dead-weight artifacts, duplicated wrappers, outdated vendored code, and modules that should be extracted, rebuilt, or deprecated.
 5. **Produce the report**: return a concise summary plus the interactive HTML output with per-module drill-down so the audit can be reviewed asynchronously.
-
-## Examples
-
-On a 50,000-file C++ monorepo:
-- Found FFmpeg 2.x (2015 vintage) still in production
-- Discovered the same SDK wrapper duplicated 3 times
-- Identified 636 MB of committed Debug/ipch/obj build artifacts
-- Classified: 3 MB project code vs 596 MB third-party
-
-## Best Practices
-
-- Start with `standard` depth for first-time audits
-- Use `fast` for monorepos with 100+ modules to get a quick inventory
-- Run `deep` incrementally on modules flagged for refactoring
-- Review the cross-module analysis for duplicate detection across sub-projects
-
-## Links
-
-- [GitHub Repository](https://github.com/haibindev/repo-scan)
+
+## Examples
+
+On a 50,000-file C++ monorepo:
+- Found FFmpeg 2.x (2015 vintage) still in production
+- Discovered the same SDK wrapper duplicated 3 times
+- Identified 636 MB of committed Debug/ipch/obj build artifacts
+- Classified: 3 MB project code vs 596 MB third-party
+
+## Best Practices
+
+- Start with `standard` depth for first-time audits
+- Use `fast` for monorepos with 100+ modules to get a quick inventory
+- Run `deep` incrementally on modules flagged for refactoring
+- Review the cross-module analysis for duplicate detection across sub-projects
+
+## Links
+
+- [GitHub Repository](https://github.com/haibindev/repo-scan)

package/skills/rework-loop/SKILL.md

@@ -0,0 +1,131 @@
+---
+name: rework-loop
+description: "Structured rework with git blame attribution for failed goal iterations. Maps failures to responsible changes and routes targeted fix briefs."
+origin: ECC
+---
+
+# Rework Loop
+
+Structured rework with blame attribution for failed goal iterations.
+When the oracle says "fail," don't blindly retry — identify what broke,
+map it to the responsible change, and route a targeted fix.
+
+## When to Activate
+
+- Oracle returns `fail` verdict during a goal iteration
+- Code reviewer identifies rework-worthy issues
+- Build/test failures after a maker iteration
+- Manual invocation for targeted re-implementation
+
+## Core Concept: Blame-Attributed Rework
+
+Blind retry is the #1 waste in autonomous loops. A rework loop instead:
+
+1. **Parses** failure output to extract specific failing locations
+2. **Blames** via `git diff` / `git blame` to find the responsible change
+3. **Constrains** the rework to only the affected scope
+4. **Routes** to the right specialist (TS issues → typescript-reviewer, etc.)
+5. **Tracks** rework attempts per location to detect persistent trouble spots
+
+```
+Oracle: FAIL
+  │
+  ▼
+Parse failure → "tests/auth.test.ts:45 — token refresh assertion fails"
+  │
+  ▼
+Blame → "src/auth/refresh.ts:23 changed in this iteration"
+  │
+  ▼
+Rework brief → {file: "src/auth/refresh.ts", constraint: "only fix refresh logic"}
+  │
+  ▼
+Route → backend-engineer or typescript-reviewer
+  │
+  ▼
+Track → attempts[src/auth/refresh.ts] += 1
+```
+
+## Rework Brief Format
+
+The rework brief is a structured context packet for the next iteration:
+
+```markdown
+## REWORK BRIEF
+
+**Goal:** {original objective}
+**Iteration:** {N} (rework attempt {M} for this location)
+
+**Failing evidence:**
+- Test: tests/auth.test.ts:45 — "should refresh expired tokens"
+- Error: Expected token.expiresAt to be > now, got 2024-01-01
+
+**Root cause (blame):**
+- File: src/auth/refresh.ts:23
+- Change: Added early return before expiry check
+- Commit: (this iteration, uncommitted)
+
+**Constraint:**
+- ONLY modify src/auth/refresh.ts
+- DO NOT touch test files (they define correct behavior)
+- The refresh logic must handle: valid token, expired token, missing token
+
+**Suggested fix:**
+- Remove the early return at line 23
+- Ensure expiry check runs before refresh attempt
+```
+
+## Escalation Triggers
+
+Rework escalates to triage when:
+
+| Condition | Action |
+|-----------|--------|
+| 3+ rework attempts on same location | Escalate: "persistent trouble spot" |
+| Rework introduces new failures | Escalate: "regression cascade" |
+| Blame maps to multiple unrelated files | Escalate: "scope too broad for targeted rework" |
+| No clear blame (flaky test, env issue) | Escalate: "non-deterministic failure" |
+
+## Blame Attribution Algorithm
+
+1. **Parse failure output** for file paths and line numbers
+2. **Get changed files** via `git diff --name-only` (this iteration vs last good)
+3. **Intersect** failing files with changed files
+4. **For each intersection:**
+   - `git diff <file>` to extract specific hunks
+   - Map test failure line to source change via call stack or import chain
+5. **If no intersection:** failure is pre-existing or environmental → escalate
+
+## Rework Tracking
+
+Track attempts per file/function to detect patterns:
+
+```json
+{
+  "src/auth/refresh.ts": {
+    "attempts": 3,
+    "lastAttempt": "2024-01-15T10:30:00Z",
+    "outcomes": ["fail", "fail", "pass"],
+    "totalCost": 1.20
+  }
+}
+```
+
+When `attempts >= 3` without convergence: this is a persistent trouble spot.
+The loop should escalate rather than keep burning budget.
+
+## Integration Points
+
+- **`/goal`**: Rework replaces blind retry in the maker-oracle loop
+- **`completion-oracle.js`**: Oracle's `failReasons` feed into blame parsing
+- **`/triage`**: Escalated rework items go to triage inbox
+- **Specialist agents**: Rework briefs route to appropriate specialists
+- **Cost advisor**: Rework attempts count toward goal budget
+
+## Hard Bans
+
+- DO NOT retry without blame analysis (blind retry wastes budget)
+- DO NOT modify test files during rework (tests define correct behavior)
+- DO NOT expand scope beyond blamed files (scope creep = new bugs)
+- DO NOT rework indefinitely (3 attempts max per location)
+- DO NOT skip tracking (rework history enables pattern detection)