npm - @torus-engineering/tas-kit - Versions diffs - 1.7.0 → 1.9.0 - Mend

@torus-engineering/tas-kit 1.7.0 → 1.9.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (73) hide show

package/.claude/commands/tas-adr.md +33 -29
package/.claude/commands/tas-apitest-plan.md +173 -0
package/.claude/commands/tas-apitest.md +143 -0
package/.claude/commands/tas-bug.md +113 -109
package/.claude/commands/tas-design.md +37 -33
package/.claude/commands/tas-dev.md +128 -115
package/.claude/commands/tas-e2e-mobile.md +155 -0
package/.claude/commands/tas-e2e-web.md +163 -0
package/.claude/commands/tas-e2e.md +102 -0
package/.claude/commands/tas-epic.md +35 -31
package/.claude/commands/tas-feature.md +47 -43
package/.claude/commands/tas-fix.md +51 -47
package/.claude/commands/tas-functest-mobile.md +144 -0
package/.claude/commands/tas-functest-web.md +192 -0
package/.claude/commands/tas-functest.md +76 -0
package/.claude/commands/tas-plan.md +200 -184
package/.claude/commands/tas-prd.md +37 -33
package/.claude/commands/tas-review.md +111 -104
package/.claude/commands/tas-sad.md +43 -39
package/.claude/commands/tas-security.md +81 -80
package/.claude/commands/tas-story.md +91 -87
package/.claude/commands/tas-verify.md +51 -41
package/.claude/rules/common/post-review-agent.md +49 -39
package/.claude/rules/common/testing.md +24 -0
package/.claude/rules/common/token-logging.md +27 -0
package/.claude/rules/csharp/api-testing.md +171 -0
package/.claude/rules/csharp/patterns.md +10 -0
package/.claude/rules/python/patterns.md +10 -0
package/.claude/rules/typescript/patterns.md +10 -0
package/.claude/rules/web/performance.md +9 -0
package/.claude/skills/api-design/SKILL.md +3 -1
package/.claude/skills/{backend-patterns → js-backend-patterns}/SKILL.md +2 -1
package/.claude/skills/tas-implementation-complete/SKILL.md +99 -97
package/.claude/skills/tas-tdd/SKILL.md +123 -82
package/.claude/skills/token-logger/SKILL.md +19 -0
package/.tas/templates/API-Test-Spec.md +400 -0
package/.tas/templates/E2E-Execution-Report.md +198 -0
package/.tas/templates/E2E-Mobile-Spec.md +130 -0
package/.tas/templates/E2E-Report.md +174 -0
package/.tas/templates/E2E-Scenario.md +180 -0
package/.tas/templates/E2E-Web-Spec.md +164 -0
package/.tas/templates/Feature.md +55 -55
package/.tas/templates/Func-Test-Script.md +254 -0
package/.tas/templates/Func-Test-Spec.md +187 -0
package/.tas/templates/SAD.md +274 -274
package/.tas/templates/Story.md +90 -88
package/bin/cli.js +56 -56
package/lib/deleted-files.json +36 -0
package/lib/install.js +213 -176
package/package.json +34 -34
package/.claude/agents/README.md +0 -83
package/.claude/agents/ado-agent.md +0 -39
package/.claude/agents/code-architect.md +0 -62
package/.claude/agents/code-simplifier.md +0 -53
package/.claude/agents/comment-analyzer.md +0 -59
package/.claude/agents/conversation-analyzer.md +0 -57
package/.claude/agents/docs-lookup.md +0 -55
package/.claude/agents/harness-optimizer.md +0 -62
package/.claude/agents/loop-operator.md +0 -56
package/.claude/agents/performance-optimizer.md +0 -78
package/.claude/agents/pr-test-analyzer.md +0 -68
package/.claude/agents/pytorch-build-resolver.md +0 -76
package/.claude/agents/refactor-cleaner.md +0 -70
package/.claude/agents/seo-specialist.md +0 -75
package/.claude/agents/silent-failure-hunter.md +0 -69
package/.claude/agents/type-design-analyzer.md +0 -75
package/.claude/rules/common/agents.md +0 -65
package/.claude/rules/common/coding-style.md +0 -90
package/.claude/rules/common/development-workflow.md +0 -44
package/.claude/rules/common/git-workflow.md +0 -24
package/.claude/rules/common/performance.md +0 -55
package/.claude/skills/agent-harness-construction/SKILL.md +0 -77
package/.claude/skills/agent-introspection-debugging/SKILL.md +0 -157

package/.claude/agents/seo-specialist.md DELETED Viewed

@@ -1,75 +0,0 @@
----
-name: seo-specialist
-description: Use when optimizing a React or Next.js web application for search engine visibility. Reviews meta tags, structured data, SSR/SSG strategy, Core Web Vitals impact, and URL structure. Returns actionable SEO findings tied to specific files.
-allowed-tools: Read, Grep, Glob, Bash
----
-# SEO Specialist Agent
-You are an SEO optimization agent for React and Next.js web applications. You audit the technical SEO implementation and return specific, actionable findings tied to file locations. You do not write content — only technical SEO.
-## Review areas
-### Meta tags and head management
-- `<title>` missing or identical across all pages (each page needs a unique, descriptive title)
-- `<meta name="description">` missing or too long (>160 chars) or too short (<70 chars)
-- `<meta property="og:*">` Open Graph tags missing (social sharing preview broken)
-- Canonical URL missing or pointing to wrong URL
-- `robots` meta tag blocking pages that should be indexed
-- **Next.js**: using `next/head` correctly vs App Router `metadata` export
-### Rendering strategy (Next.js)
-- Important pages using CSR (client-side render) that should use SSR/SSG
-- Dynamic pages with `generateStaticParams` missing (causes client-side rendering)
-- `revalidate` too long on pages with frequently changing content
-- `noindex` inadvertently set on high-value pages
-### Structured data (JSON-LD)
-- Missing structured data on product, article, FAQ, or breadcrumb pages
-- Structured data present but invalid (mismatched schema type)
-- Schema placed in wrong location (should be in `<head>` or as `<script type="application/ld+json">`)
-### Performance (Core Web Vitals impact on ranking)
-- Images missing `width`/`height` causing layout shift (CLS)
-- `next/image` not used where it should be (missing lazy loading, wrong format)
-- Large above-the-fold render-blocking resources
-- Missing `priority` prop on LCP image (`next/image`)
-- Fonts loaded without `font-display: swap`
-### URL structure
-- Dynamic routes with non-descriptive slugs (`/product/123` vs `/product/running-shoes-nike`)
-- Missing `sitemap.xml` or sitemap not updated
-- `robots.txt` missing or blocking important paths
-- URL parameters used for content that should be in the path
-### Accessibility (affects SEO)
-- Missing `alt` text on images
-- Heading hierarchy broken (`h3` used without preceding `h2`)
-- Links with non-descriptive text (`click here`, `read more`)
-## How to operate
-1. Identify the framework: Next.js App Router vs Pages Router vs plain React
-2. Check `next.config.js`/`next.config.ts` for redirects, rewrites, headers
-3. Grep for `<head>`, `metadata`, `<title>`, `<meta` usage
-4. Review key page files (homepage, listing pages, detail pages, landing pages)
-5. Check for `sitemap.ts`/`sitemap.xml` and `robots.ts`/`robots.txt`
-## Output format
-Group by priority:
-### Critical (directly harms indexability)
-- `app/products/[slug]/page.tsx` — No `metadata` export. Page has no title or description. Will appear as untitled in search results.
-### High (significant ranking impact)
-- `app/page.tsx:12` — LCP image missing `priority` prop. Slows Largest Contentful Paint.
-### Medium (best practice gaps)
-- `app/layout.tsx` — Open Graph `og:image` not set globally. Social previews will show no image.
-### Info (nice to have)
-- `app/products/page.tsx` — Consider adding `ItemList` structured data for product listing pages.
-### Summary
-X critical, Y high, Z medium issues. Pages analyzed: N.

package/.claude/agents/silent-failure-hunter.md DELETED Viewed

@@ -1,69 +0,0 @@
----
-name: silent-failure-hunter
-description: Use when you suspect hidden bugs, swallowed exceptions, or unreliable behavior that doesn't produce obvious errors. Hunts for silent failures — empty catch blocks, missing null checks, fire-and-forget async calls, unvalidated assumptions — across .NET, Node.js, and Python codebases.
-allowed-tools: Read, Grep, Glob
----
-# Silent Failure Hunter Agent
-You are a static analysis agent specializing in bugs that don't throw — they silently corrupt state, swallow errors, or produce wrong results without crashing. You read code and report risky patterns. You do not fix, you do not refactor — you report with precise file:line references.
-## What you hunt
-### 1. Swallowed exceptions
-- Empty `catch {}` or `catch (e) {}` with no logging or rethrow
-- `catch` that only logs but continues execution as if nothing failed
-- `.NET`: `catch (Exception) { }`, `catch { }`
-- **Node.js**: unhandled promise rejections, `.catch(() => {})` with no action
-- **Python**: bare `except: pass`, `except Exception: pass`
-### 2. Silent async failures
-- Fire-and-forget: `_ = DoSomethingAsync()` without await
-- `async void` methods in .NET (exceptions disappear)
-- Unawaited `Promise` in JS/TS without `.catch()`
-- Background tasks with no error boundary
-### 3. Null/undefined blindspots
-- Return values from external calls used directly without null check
-- `.FirstOrDefault()` in .NET used without null guard
-- Optional chaining missing on deeply nested object access in JS/TS
-- Python dict `.get()` result used as if always non-None
-### 4. Incorrect error propagation
-- HTTP calls that don't check status codes before parsing response
-- Functions that return `bool` / `null` on error instead of throwing (caller ignores it)
-- Partial failures in loops that silently skip items
-### 5. Unvalidated assumptions
-- Config values read without existence check
-- Array index access without bounds check
-- Type assertions / casts without guard (`as Type` in C#/TS without null check after)
-## How to operate
-1. Receive a file path, directory, or feature area to scan
-2. Use Glob to find relevant source files (exclude `node_modules/`, `bin/`, `obj/`, `.git/`)
-3. Use Grep to find patterns matching the categories above
-4. Read surrounding context (5-10 lines) to confirm it's a real risk — not a false positive
-5. Report only confirmed risks with clear evidence
-## Output format
-Group findings by category. For each finding:
----
-**[Category]**
-- `path/to/file.cs:42` — [what the code does] → [what can go wrong]
-  ```
-  // relevant code snippet (3-5 lines max)
-  ```
----
-**Summary**: X findings across Y files.
-- High risk (silent data corruption / data loss): N
-- Medium risk (silent failure, recoverable): N
-- Low risk (missing guard, unlikely path): N
-Do NOT report style issues. Do NOT report things that are caught elsewhere (e.g., a swallowed exception inside a method that is itself wrapped in a try/catch at the call site — read the caller first).
-Flag if a pattern is systemic (same anti-pattern in 5+ places) — that warrants a convention update, not just individual fixes.

package/.claude/agents/type-design-analyzer.md DELETED Viewed

@@ -1,75 +0,0 @@
----
-name: type-design-analyzer
-description: Use when TypeScript type definitions are complex, unclear, or causing type errors. Analyzes type design for correctness, expressiveness, and maintainability — finds overuse of `any`, missing discriminated unions, weak generics, and type assertions hiding real problems.
-allowed-tools: Read, Grep, Glob, Bash
----
-# Type Design Analyzer Agent
-You are a TypeScript type system specialist. You analyze type definitions, interfaces, generics, and utility type usage to find type safety gaps and suggest better type designs. You report findings and suggest better types — you do not rewrite implementations.
-## What you analyze
-### Type safety gaps
-- `any` used where a specific type is known or inferable
-- `as SomeType` assertions that bypass type checking (the type assertion says "trust me" — often wrong)
-- `!` non-null assertion on values that could genuinely be null
-- `// @ts-ignore` or `// @ts-expect-error` without explanation
-### Weak type design
-- `object`, `{}`, or `Record<string, any>` for structured data that should have a defined shape
-- `string` or `number` where a string literal union or enum is more precise
-  - Example: `status: string` → `status: 'pending' | 'active' | 'cancelled'`
-- Optional fields (`?`) used when the field is always present in practice
-- Union types with more than 5 members that should be a discriminated union
-### Discriminated unions
-When you see `type A = { kind: 'foo', ... } | { kind: 'bar', ... }` — check:
-- Is the discriminant field (`kind`, `type`, `__typename`) always present?
-- Are all branches of a `switch`/`if` on the discriminant handled?
-- Would TypeScript narrow correctly in switch cases?
-### Generic type design
-- Generics constrained too loosely (`<T>` where `<T extends SomeBase>` is appropriate)
-- Generics not needed (function works only for one type anyway)
-- Complex nested generics that could be named with a type alias for readability
-### Utility types
-- Manual re-implementation of built-in utility types (`Partial`, `Required`, `Pick`, `Omit`, `ReturnType`, etc.)
-- `Readonly<T>` missing on types that should be immutable
-- `Awaited<T>` missing when working with Promise return types
-## How to operate
-1. Receive a file path or directory to analyze
-2. Read type definitions, interfaces, and usage patterns
-3. Run `tsc --noEmit` if accessible to check for type errors
-4. Identify issues from the categories above
-5. For each issue: show the current type, explain the problem, suggest the better type
-## Output format
----
-**File**: `path/to/types.ts`
-### Type safety gaps
-- `line 23`: `as UserResponse` — assertion bypasses null check. `response.data` can be undefined when API returns 404. Use proper null check instead.
-### Weak type design
-- `line 45`: `status: string` → should be `status: 'draft' | 'published' | 'archived'`. Makes invalid states unrepresentable.
-### Missing discriminated union
-- `line 12-18`: `ApiResult<T> = { data: T } | { error: string }` — add discriminant `type: 'success' | 'error'` to enable exhaustive narrowing.
-### Suggested types
-```typescript
-// Before
-type ApiResult<T> = { data: T } | { error: string }
-// After
-type ApiResult<T> =
-  | { type: 'success'; data: T }
-  | { type: 'error'; error: string }
-```
-**Summary**: X type safety gaps, Y design improvements. Overall type coverage: [Strong / Adequate / Weak].

package/.claude/rules/common/agents.md DELETED Viewed

@@ -1,65 +0,0 @@
-# Agent Orchestration
-## Parallel Execution Pattern (TAS Commands)
-TAS commands launch agents **đồng thời** — không chờ nhau. Chờ **TẤT CẢ** xong mới tổng hợp.
-### Parallel Agent Sets theo Command
-| Command | Agents chạy song song | Điều kiện |
-|---------|----------------------|-----------|
-| `/tas-plan` (Bước 2) | code-explorer + [architect] | architect khi ảnh hưởng architecture |
-| `/tas-dev` (Bước 3) | [build-resolver] | Chỉ khi tests vẫn fail sau 1 lần tự fix |
-| `/tas-dev` (Bước 4) | code-reviewer + security-reviewer + [lang-reviewer] | lang theo stack |
-| `/tas-bug` (fix step) | [build-resolver] | Chỉ khi build fail hoặc test lỗi compile |
-| `/tas-verify` (Bước 4.5) | e2e-runner | Khi Feature có E2E test cases |
-| `/tas-review` | code-reviewer + security-reviewer + [lang-reviewer] + [aws-reviewer] | lang theo stack; aws nếu có AWS |
-| `/tas-security` | security-reviewer + [database-reviewer] + [aws-reviewer] | db nếu SQL; aws nếu AWS |
-| `tas-implementation-complete` | code-reviewer + security-reviewer + [lang-reviewer] | Auto-invoke khi user nói "done/xong" |
-### Cách viết agent prompt trong commands
-Mỗi agent trong parallel set cần prompt đủ 4 yếu tố:
-```
-**Agent N — `<agent-name>`** (<điều kiện chạy>):
-> [1] Scope — review/analyze cái gì (file path, git diff, directory)
-> [2] Read — rule files nào phải đọc trước khi phân tích
-> [3] Focus — tập trung vào những gì cụ thể
-> [4] Format — Critical / High / Medium / Low với file:line
-```
-**Ví dụ chuẩn:**
-```
-**Agent 1 — `security-reviewer`** (luôn chạy):
-> Security audit [scope]. Đọc `.claude/rules/common/security.md`.
-> Tập trung: OWASP Top 10, injection, hardcoded secrets, auth/authz.
-> Format: Critical / High / Medium / Low với file:line và remediation.
-```
-### Gate Rule sau khi tổng hợp
-```
-Có Critical/High → Block, list findings, yêu cầu fix trước khi tiếp tục
-Chỉ có Medium/Low → List gợi ý, hỏi user có muốn fix không, sau đó tiếp tục
-```
-## Rule Files — Khi Nào Agent Cần Đọc
-Agents **không tự động nhận** rule files. Commands và skills phải **chủ động** chỉ định trong agent prompt.
-| Rule File | Agent nên đọc | Ngữ cảnh |
-|-----------|---------------|----------|
-| `common/security.md` | `security-reviewer` | Mọi security audit |
-| `common/code-review.md` | `code-reviewer` | Mọi code review |
-| `common/testing.md` | `tdd-guide`, lang-reviewers | Review test coverage |
-| `common/patterns.md` | `architect` | Đánh giá architectural choice |
-| `common/development-workflow.md` | `architect`, `planner` | Plan/design phase |
-| `[stack]/coding-style.md` | lang-reviewer | Language-specific review |
-| `[stack]/patterns.md` | lang-reviewer | Language-specific patterns |
-| `[stack]/security.md` | `security-reviewer` | Stack-specific security risks |
-| `[stack]/testing.md` | lang-reviewer | Stack-specific test patterns |
-| `web/design-quality.md` | Frontend reviewer | Review UI code |
-| `web/performance.md` | Frontend reviewer | Review performance |
-> Danh sách đầy đủ tất cả agents: xem `.claude/agents/README.md`

package/.claude/rules/common/coding-style.md DELETED Viewed

@@ -1,90 +0,0 @@
-# Coding Style
-## Immutability (CRITICAL)
-ALWAYS create new objects, NEVER mutate existing ones:
-```
-// Pseudocode
-WRONG:  modify(original, field, value) → changes original in-place
-CORRECT: update(original, field, value) → returns new copy with change
-```
-Rationale: Immutable data prevents hidden side effects, makes debugging easier, and enables safe concurrency.
-## Core Principles
-### KISS (Keep It Simple)
-- Prefer the simplest solution that actually works
-- Avoid premature optimization
-- Optimize for clarity over cleverness
-### DRY (Don't Repeat Yourself)
-- Extract repeated logic into shared functions or utilities
-- Avoid copy-paste implementation drift
-- Introduce abstractions when repetition is real, not speculative
-### YAGNI (You Aren't Gonna Need It)
-- Do not build features or abstractions before they are needed
-- Avoid speculative generality
-- Start simple, then refactor when the pressure is real
-## File Organization
-MANY SMALL FILES > FEW LARGE FILES:
-- High cohesion, low coupling
-- 200-400 lines typical, 800 max
-- Extract utilities from large modules
-- Organize by feature/domain, not by type
-## Error Handling
-ALWAYS handle errors comprehensively:
-- Handle errors explicitly at every level
-- Provide user-friendly error messages in UI-facing code
-- Log detailed error context on the server side
-- Never silently swallow errors
-## Input Validation
-ALWAYS validate at system boundaries:
-- Validate all user input before processing
-- Use schema-based validation where available
-- Fail fast with clear error messages
-- Never trust external data (API responses, user input, file content)
-## Naming Conventions
-- Variables and functions: `camelCase` with descriptive names
-- Booleans: prefer `is`, `has`, `should`, or `can` prefixes
-- Interfaces, types, and components: `PascalCase`
-- Constants: `UPPER_SNAKE_CASE`
-- Custom hooks: `camelCase` with a `use` prefix
-## Code Smells to Avoid
-### Deep Nesting
-Prefer early returns over nested conditionals once the logic starts stacking.
-### Magic Numbers
-Use named constants for meaningful thresholds, delays, and limits.
-### Long Functions
-Split large functions into focused pieces with clear responsibilities.
-## Code Quality Checklist
-Before marking work complete:
-- [ ] Code is readable and well-named
-- [ ] Functions are small (<50 lines)
-- [ ] Files are focused (<800 lines)
-- [ ] No deep nesting (>4 levels)
-- [ ] Proper error handling
-- [ ] No hardcoded values (use constants or config)
-- [ ] No mutation (immutable patterns used)

package/.claude/rules/common/development-workflow.md DELETED Viewed

@@ -1,44 +0,0 @@
-# Development Workflow
-> This file extends [common/git-workflow.md](./git-workflow.md) with the full feature development process that happens before git operations.
-The Feature Implementation Workflow describes the development pipeline: research, planning, TDD, code review, and then committing to git.
-## Feature Implementation Workflow
-0. **Research & Reuse** _(mandatory before any new implementation)_
-   - **GitHub code search first:** Run `gh search repos` and `gh search code` to find existing implementations, templates, and patterns before writing anything new.
-   - **Library docs second:** Use Context7 or primary vendor docs to confirm API behavior, package usage, and version-specific details before implementing.
-   - **Exa only when the first two are insufficient:** Use Exa for broader web research or discovery after GitHub search and primary docs.
-   - **Check package registries:** Search npm, PyPI, crates.io, and other registries before writing utility code. Prefer battle-tested libraries over hand-rolled solutions.
-   - **Search for adaptable implementations:** Look for open-source projects that solve 80%+ of the problem and can be forked, ported, or wrapped.
-   - Prefer adopting or porting a proven approach over writing net-new code when it meets the requirement.
-1. **Plan First**
-   - Use **planner** agent to create implementation plan
-   - Generate planning docs before coding: PRD, architecture, system_design, tech_doc, task_list
-   - Identify dependencies and risks
-   - Break down into phases
-2. **TDD Approach**
-   - Use **tdd-guide** agent
-   - Write tests first (RED)
-   - Implement to pass tests (GREEN)
-   - Refactor (IMPROVE)
-   - Verify 80%+ coverage
-3. **Code Review**
-   - Use **code-reviewer** agent immediately after writing code
-   - Address CRITICAL and HIGH issues
-   - Fix MEDIUM issues when possible
-4. **Commit & Push**
-   - Detailed commit messages
-   - Follow conventional commits format
-   - See [git-workflow.md](./git-workflow.md) for commit message format and PR process
-5. **Pre-Review Checks**
-   - Verify all automated checks (CI/CD) are passing
-   - Resolve any merge conflicts
-   - Ensure branch is up to date with target branch
-   - Only request review after these checks pass

package/.claude/rules/common/git-workflow.md DELETED Viewed

@@ -1,24 +0,0 @@
-# Git Workflow
-## Commit Message Format
-```
-<type>: <description>
-<optional body>
-```
-Types: feat, fix, refactor, docs, test, chore, perf, ci
-Note: Attribution disabled globally via ~/.claude/settings.json.
-## Pull Request Workflow
-When creating PRs:
-1. Analyze full commit history (not just latest commit)
-2. Use `git diff [base-branch]...HEAD` to see all changes
-3. Draft comprehensive PR summary
-4. Include test plan with TODOs
-5. Push with `-u` flag if new branch
-> For the full development process (planning, TDD, code review) before git operations,
-> see [development-workflow.md](./development-workflow.md).

package/.claude/rules/common/performance.md DELETED Viewed

@@ -1,55 +0,0 @@
-# Performance Optimization
-## Model Selection Strategy
-**Haiku 4.5** (90% of Sonnet capability, 3x cost savings):
-- Lightweight agents with frequent invocation
-- Pair programming and code generation
-- Worker agents in multi-agent systems
-**Sonnet 4.6** (Best coding model):
-- Main development work
-- Orchestrating multi-agent workflows
-- Complex coding tasks
-**Opus 4.5** (Deepest reasoning):
-- Complex architectural decisions
-- Maximum reasoning requirements
-- Research and analysis tasks
-## Context Window Management
-Avoid last 20% of context window for:
-- Large-scale refactoring
-- Feature implementation spanning multiple files
-- Debugging complex interactions
-Lower context sensitivity tasks:
-- Single-file edits
-- Independent utility creation
-- Documentation updates
-- Simple bug fixes
-## Extended Thinking + Plan Mode
-Extended thinking is enabled by default, reserving up to 31,999 tokens for internal reasoning.
-Control extended thinking via:
-- **Toggle**: Option+T (macOS) / Alt+T (Windows/Linux)
-- **Config**: Set `alwaysThinkingEnabled` in `~/.claude/settings.json`
-- **Budget cap**: `export MAX_THINKING_TOKENS=10000`
-- **Verbose mode**: Ctrl+O to see thinking output
-For complex tasks requiring deep reasoning:
-1. Ensure extended thinking is enabled (on by default)
-2. Enable **Plan Mode** for structured approach
-3. Use multiple critique rounds for thorough analysis
-4. Use split role sub-agents for diverse perspectives
-## Build Troubleshooting
-If build fails:
-1. Use **build-error-resolver** agent
-2. Analyze error messages
-3. Fix incrementally
-4. Verify after each fix

package/.claude/skills/agent-harness-construction/SKILL.md DELETED Viewed

@@ -1,77 +0,0 @@
----
-name: agent-harness-construction
-description: |
-  Auto-invoke when designing or optimizing agent tool definitions, action spaces,
-  or observation formats. Also when an agent is looping on tools without progress,
-  failing to converge, or producing poor-quality completions due to harness design.
-origin: ECC
-allowed-tools: Read, Grep, Glob
----
-# Agent Harness Construction
-Use this skill when you are improving how an agent plans, calls tools, recovers from errors, and converges on completion.
-## Core Model
-Agent output quality is constrained by:
-1. Action space quality
-2. Observation quality
-3. Recovery quality
-4. Context budget quality
-## Action Space Design
-1. Use stable, explicit tool names.
-2. Keep inputs schema-first and narrow.
-3. Return deterministic output shapes.
-4. Avoid catch-all tools unless isolation is impossible.
-## Granularity Rules
-- Use micro-tools for high-risk operations (deploy, migration, permissions).
-- Use medium tools for common edit/read/search loops.
-- Use macro-tools only when round-trip overhead is the dominant cost.
-## Observation Design
-Every tool response should include:
-- `status`: success|warning|error
-- `summary`: one-line result
-- `next_actions`: actionable follow-ups
-- `artifacts`: file paths / IDs
-## Error Recovery Contract
-For every error path, include:
-- root cause hint
-- safe retry instruction
-- explicit stop condition
-## Context Budgeting
-1. Keep system prompt minimal and invariant.
-2. Move large guidance into skills loaded on demand.
-3. Prefer references to files over inlining long documents.
-4. Compact at phase boundaries, not arbitrary token thresholds.
-## Architecture Pattern Guidance
-- ReAct: best for exploratory tasks with uncertain path.
-- Function-calling: best for structured deterministic flows.
-- Hybrid (recommended): ReAct planning + typed tool execution.
-## Benchmarking
-Track:
-- completion rate
-- retries per task
-- pass@1 and pass@3
-- cost per successful task
-## Anti-Patterns
-- Too many tools with overlapping semantics.
-- Opaque tool output with no recovery hints.
-- Error-only output without next steps.
-- Context overloading with irrelevant references.