@harness-forge/cli 0.1.0

package/knowledge-bases/seeded/typescript/legacy-seed/typescript/security.md

@@ -0,0 +1,28 @@
+---
+paths:
+  - "**/*.ts"
+  - "**/*.tsx"
+  - "**/*.js"
+  - "**/*.jsx"
+---
+# TypeScript/JavaScript Security
+
+> This file extends [common/security.md](../common/security.md) with TypeScript/JavaScript specific content.
+
+## Secret Management
+
+```typescript
+// NEVER: Hardcoded secrets
+const apiKey = "sk-proj-xxxxx"
+
+// ALWAYS: Environment variables
+const apiKey = process.env.OPENAI_API_KEY
+
+if (!apiKey) {
+  throw new Error('OPENAI_API_KEY not configured')
+}
+```
+
+## Agent Support
+
+- Use **security-reviewer** skill for comprehensive security audits

package/knowledge-bases/seeded/typescript/legacy-seed/typescript/testing.md

@@ -0,0 +1,18 @@
+---
+paths:
+  - "**/*.ts"
+  - "**/*.tsx"
+  - "**/*.js"
+  - "**/*.jsx"
+---
+# TypeScript/JavaScript Testing
+
+> This file extends [common/testing.md](../common/testing.md) with TypeScript/JavaScript specific content.
+
+## E2E Testing
+
+Use **Playwright** as the E2E testing framework for critical user flows.
+
+## Agent Support
+
+- **e2e-runner** - Playwright E2E testing specialist

package/knowledge-bases/seeded/typescript/rules/common/agents.md

@@ -0,0 +1,50 @@
+# Agent Orchestration
+
+## Available Agents
+
+Located in `~/.claude/agents/`:
+
+| Agent | Purpose | When to Use |
+|-------|---------|-------------|
+| planner | Implementation planning | Complex features, refactoring |
+| architect | System design | Architectural decisions |
+| tdd-guide | Test-driven development | New features, bug fixes |
+| code-reviewer | Code review | After writing code |
+| security-reviewer | Security analysis | Before commits |
+| build-error-resolver | Fix build errors | When build fails |
+| e2e-runner | E2E testing | Critical user flows |
+| refactor-cleaner | Dead code cleanup | Code maintenance |
+| doc-updater | Documentation | Updating docs |
+| rust-reviewer | Rust code review | Rust projects |
+
+## Immediate Agent Usage
+
+No user prompt needed:
+1. Complex feature requests - Use **planner** agent
+2. Code just written/modified - Use **code-reviewer** agent
+3. Bug fix or new feature - Use **tdd-guide** agent
+4. Architectural decision - Use **architect** agent
+
+## Parallel Task Execution
+
+ALWAYS use parallel Task execution for independent operations:
+
+```markdown
+# GOOD: Parallel execution
+Launch 3 agents in parallel:
+1. Agent 1: Security analysis of auth module
+2. Agent 2: Performance review of cache system
+3. Agent 3: Type checking of utilities
+
+# BAD: Sequential when unnecessary
+First agent 1, then agent 2, then agent 3
+```
+
+## Multi-Perspective Analysis
+
+For complex problems, use split role sub-agents:
+- Factual reviewer
+- Senior engineer
+- Security expert
+- Consistency reviewer
+- Redundancy checker

package/knowledge-bases/seeded/typescript/rules/common/coding-style.md

@@ -0,0 +1,48 @@
+# 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.
+
+## 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)
+
+## 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/knowledge-bases/seeded/typescript/rules/common/development-workflow.md

@@ -0,0 +1,38 @@
+# 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

package/knowledge-bases/seeded/typescript/rules/common/git-workflow.md

@@ -0,0 +1,24 @@
+# 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/knowledge-bases/seeded/typescript/rules/common/hooks.md

@@ -0,0 +1,30 @@
+# Hooks System
+
+## Hook Types
+
+- **PreToolUse**: Before tool execution (validation, parameter modification)
+- **PostToolUse**: After tool execution (auto-format, checks)
+- **Stop**: When session ends (final verification)
+
+## Auto-Accept Permissions
+
+Use with caution:
+- Enable for trusted, well-defined plans
+- Disable for exploratory work
+- Never use dangerously-skip-permissions flag
+- Configure `allowedTools` in `~/.claude.json` instead
+
+## TodoWrite Best Practices
+
+Use TodoWrite tool to:
+- Track progress on multi-step tasks
+- Verify understanding of instructions
+- Enable real-time steering
+- Show granular implementation steps
+
+Todo list reveals:
+- Out of order steps
+- Missing items
+- Extra unnecessary items
+- Wrong granularity
+- Misinterpreted requirements

package/knowledge-bases/seeded/typescript/rules/common/patterns.md

@@ -0,0 +1,31 @@
+# Common Patterns
+
+## Skeleton Projects
+
+When implementing new functionality:
+1. Search for battle-tested skeleton projects
+2. Use parallel agents to evaluate options:
+   - Security assessment
+   - Extensibility analysis
+   - Relevance scoring
+   - Implementation planning
+3. Clone best match as foundation
+4. Iterate within proven structure
+
+## Design Patterns
+
+### Repository Pattern
+
+Encapsulate data access behind a consistent interface:
+- Define standard operations: findAll, findById, create, update, delete
+- Concrete implementations handle storage details (database, API, file, etc.)
+- Business logic depends on the abstract interface, not the storage mechanism
+- Enables easy swapping of data sources and simplifies testing with mocks
+
+### API Response Format
+
+Use a consistent envelope for all API responses:
+- Include a success/status indicator
+- Include the data payload (nullable on error)
+- Include an error message field (nullable on success)
+- Include metadata for paginated responses (total, page, limit)

package/knowledge-bases/seeded/typescript/rules/common/performance.md

@@ -0,0 +1,55 @@
+# 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/knowledge-bases/seeded/typescript/rules/common/security.md

@@ -0,0 +1,29 @@
+# Security Guidelines
+
+## Mandatory Security Checks
+
+Before ANY commit:
+- [ ] No hardcoded secrets (API keys, passwords, tokens)
+- [ ] All user inputs validated
+- [ ] SQL injection prevention (parameterized queries)
+- [ ] XSS prevention (sanitized HTML)
+- [ ] CSRF protection enabled
+- [ ] Authentication/authorization verified
+- [ ] Rate limiting on all endpoints
+- [ ] Error messages don't leak sensitive data
+
+## Secret Management
+
+- NEVER hardcode secrets in source code
+- ALWAYS use environment variables or a secret manager
+- Validate that required secrets are present at startup
+- Rotate any secrets that may have been exposed
+
+## Security Response Protocol
+
+If security issue found:
+1. STOP immediately
+2. Use **security-reviewer** agent
+3. Fix CRITICAL issues before continuing
+4. Rotate any exposed secrets
+5. Review entire codebase for similar issues

package/knowledge-bases/seeded/typescript/rules/common/testing.md

@@ -0,0 +1,29 @@
+# Testing Requirements
+
+## Minimum Test Coverage: 80%
+
+Test Types (ALL required):
+1. **Unit Tests** - Individual functions, utilities, components
+2. **Integration Tests** - API endpoints, database operations
+3. **E2E Tests** - Critical user flows (framework chosen per language)
+
+## Test-Driven Development
+
+MANDATORY workflow:
+1. Write test first (RED)
+2. Run test - it should FAIL
+3. Write minimal implementation (GREEN)
+4. Run test - it should PASS
+5. Refactor (IMPROVE)
+6. Verify coverage (80%+)
+
+## Troubleshooting Test Failures
+
+1. Use **tdd-guide** agent
+2. Check test isolation
+3. Verify mocks are correct
+4. Fix implementation, not tests (unless tests are wrong)
+
+## Agent Support
+
+- **tdd-guide** - Use PROACTIVELY for new features, enforces write-tests-first

package/knowledge-bases/seeded/typescript/rules/typescript/coding-style.md

@@ -0,0 +1,30 @@
+---
+paths:
+  - "**/*.ts"
+  - "**/*.tsx"
+  - "**/*.mts"
+  - "**/*.cts"
+extends: ../common/coding-style.md
+language: typescript
+layer: language
+---
+# TypeScript Coding Style
+
+> This file extends [common/coding-style.md](../common/coding-style.md) with TypeScript-specific guidance.
+
+## Types first
+
+- Exported functions and shared modules SHOULD expose explicit types.
+- Avoid `any`; use `unknown` and narrow safely.
+- Use `interface` for extensible object shapes and `type` for unions and mapped types.
+
+## Runtime truth
+
+- Static types are not runtime validation.
+- Validate all untrusted input at boundaries with schemas.
+
+## Project defaults
+
+- Prefer strict compiler options.
+- Keep browser-only and server-only code clearly separated.
+- Prefer pure functions and immutable updates where practical.

package/knowledge-bases/seeded/typescript/rules/typescript/hooks.md

@@ -0,0 +1,25 @@
+---
+paths:
+  - "**/*.ts"
+  - "**/*.tsx"
+  - "package.json"
+extends: ../common/hooks.md
+language: typescript
+layer: language
+---
+# TypeScript Hooks
+
+> This file extends [common/hooks.md](../common/hooks.md) with TypeScript-specific hook suggestions.
+
+## Post-edit hooks
+
+- formatter (Prettier or project formatter)
+- eslint on affected files
+- `tsc --noEmit` or project typecheck
+- affected unit tests when behavior changes
+
+## Stop hooks
+
+- final typecheck
+- warn on `console.log` in production paths
+- dependency audit when lockfiles change

package/knowledge-bases/seeded/typescript/rules/typescript/patterns.md

@@ -0,0 +1,23 @@
+---
+paths:
+  - "**/*.ts"
+  - "**/*.tsx"
+extends: ../common/patterns.md
+language: typescript
+layer: language
+---
+# TypeScript Patterns
+
+> This file extends [common/patterns.md](../common/patterns.md) with TypeScript-specific patterns.
+
+## Recommended patterns
+
+- schema-driven API/input validation
+- typed repository or service boundaries
+- explicit DTO mapping between transport and domain
+- shared packages for contracts only when versioning and ownership are clear
+
+## Frontend note
+
+- Keep server-fetching logic, UI state, and domain formatting concerns separated.
+- Use custom hooks for reuse, not for hiding unrelated logic.

package/knowledge-bases/seeded/typescript/rules/typescript/security.md

@@ -0,0 +1,23 @@
+---
+paths:
+  - "**/*.ts"
+  - "**/*.tsx"
+extends: ../common/security.md
+language: typescript
+layer: language
+---
+# TypeScript Security
+
+> This file extends [common/security.md](../common/security.md) with TypeScript-specific security guidance.
+
+## Node and web defaults
+
+- Never trust request bodies, query strings, cookies, headers, or local storage values.
+- Use env validation at startup.
+- Sanitize or escape untrusted HTML.
+- Treat SSR/server actions as privileged code paths.
+
+## Secrets
+
+- No hardcoded secrets.
+- Redact tokens and credentials from logs, traces, and test snapshots.

package/knowledge-bases/seeded/typescript/rules/typescript/testing.md

@@ -0,0 +1,22 @@
+---
+paths:
+  - "**/*.ts"
+  - "**/*.tsx"
+extends: ../common/testing.md
+language: typescript
+layer: language
+---
+# TypeScript Testing
+
+> This file extends [common/testing.md](../common/testing.md) with TypeScript-specific testing guidance.
+
+## Defaults
+
+- Prefer Vitest or Jest for unit/integration tests depending on project standards.
+- Use Playwright for user-facing end-to-end flows.
+- Test runtime validation, auth, error translation, and serialization explicitly.
+
+## Monorepo note
+
+- Run affected tests when available.
+- Guard shared package changes with focused integration coverage.

package/knowledge-bases/structured/README.md

@@ -0,0 +1,3 @@
+# Structured language packs
+
+These packs extend Harness Forge beyond the seeded languages with curated docs, rules, examples, and skills.

package/knowledge-bases/structured/cpp/README.md

@@ -0,0 +1,3 @@
+# C++ structured pack
+
+This structured pack ships a curated overview, review checklist, framework notes, and a starter example for C++ work.

package/knowledge-bases/structured/cpp/docs/frameworks.md

@@ -0,0 +1,3 @@
+# C++ frameworks and tooling
+
+Commonly useful surfaces: CMake, Catch2, GoogleTest, fmt, clang-tidy.

package/knowledge-bases/structured/cpp/docs/overview.md

@@ -0,0 +1,12 @@
+# C++ overview
+
+## Best fit
+
+Use this pack when the repository is primarily C++ or when the task depends on .cpp, .cc, .hpp, CMakeLists.txt.
+
+## What ships
+
+- structured docs under `knowledge-bases/structured/cpp/docs/`
+- promoted rules under `rules/cpp/`
+- reusable skill under `skills/cpp-engineering/`
+- workflow template under `templates/workflows/implement-cpp-change.md`

package/knowledge-bases/structured/cpp/docs/review-checklist.md

@@ -0,0 +1,6 @@
+# C++ review checklist
+
+- validate input and error handling paths
+- keep modules small and naming explicit
+- prefer deterministic tests over implicit behavior
+- document build or runtime assumptions

package/knowledge-bases/structured/cpp/examples/01-reference-scenario.md

@@ -0,0 +1,3 @@
+# Reference scenario
+
+Use this example as a template for implementing and validating a small C++ change with the promoted rules and workflow template.

package/knowledge-bases/structured/cpp/knowledge-base.json

@@ -0,0 +1,13 @@
+{
+  "id": "cpp-structured-pack",
+  "language": "cpp",
+  "maturity": "structured",
+  "docs": [
+    "docs/overview.md",
+    "docs/review-checklist.md",
+    "docs/frameworks.md"
+  ],
+  "examples": [
+    "examples/01-reference-scenario.md"
+  ]
+}

package/knowledge-bases/structured/go/README.md

@@ -0,0 +1,3 @@
+# Go structured pack
+
+This structured pack ships a curated overview, review checklist, framework notes, and a starter example for Go work.

package/knowledge-bases/structured/go/docs/frameworks.md

@@ -0,0 +1,3 @@
+# Go frameworks and tooling
+
+Commonly useful surfaces: stdlib, chi, gin, Cobra, testing.

package/knowledge-bases/structured/go/docs/overview.md

@@ -0,0 +1,12 @@
+# Go overview
+
+## Best fit
+
+Use this pack when the repository is primarily Go or when the task depends on .go, go.mod.
+
+## What ships
+
+- structured docs under `knowledge-bases/structured/go/docs/`
+- promoted rules under `rules/golang/`
+- reusable skill under `skills/go-engineering/`
+- workflow template under `templates/workflows/implement-go-change.md`

package/knowledge-bases/structured/go/docs/review-checklist.md

@@ -0,0 +1,6 @@
+# Go review checklist
+
+- validate input and error handling paths
+- keep modules small and naming explicit
+- prefer deterministic tests over implicit behavior
+- document build or runtime assumptions

package/knowledge-bases/structured/go/examples/01-reference-scenario.md

@@ -0,0 +1,3 @@
+# Reference scenario
+
+Use this example as a template for implementing and validating a small Go change with the promoted rules and workflow template.

package/knowledge-bases/structured/go/knowledge-base.json

@@ -0,0 +1,13 @@
+{
+  "id": "go-structured-pack",
+  "language": "go",
+  "maturity": "structured",
+  "docs": [
+    "docs/overview.md",
+    "docs/review-checklist.md",
+    "docs/frameworks.md"
+  ],
+  "examples": [
+    "examples/01-reference-scenario.md"
+  ]
+}

package/knowledge-bases/structured/kotlin/README.md

@@ -0,0 +1,3 @@
+# Kotlin structured pack
+
+This structured pack ships a curated overview, review checklist, framework notes, and a starter example for Kotlin work.

package/knowledge-bases/structured/kotlin/docs/frameworks.md

@@ -0,0 +1,3 @@
+# Kotlin frameworks and tooling
+
+Commonly useful surfaces: Spring Boot, Ktor, Kotlin Multiplatform, JUnit.

package/knowledge-bases/structured/kotlin/docs/overview.md

@@ -0,0 +1,12 @@
+# Kotlin overview
+
+## Best fit
+
+Use this pack when the repository is primarily Kotlin or when the task depends on .kt, .kts, gradle files.
+
+## What ships
+
+- structured docs under `knowledge-bases/structured/kotlin/docs/`
+- promoted rules under `rules/kotlin/`
+- reusable skill under `skills/kotlin-engineering/`
+- workflow template under `templates/workflows/implement-kotlin-change.md`

package/knowledge-bases/structured/kotlin/docs/review-checklist.md

@@ -0,0 +1,6 @@
+# Kotlin review checklist
+
+- validate input and error handling paths
+- keep modules small and naming explicit
+- prefer deterministic tests over implicit behavior
+- document build or runtime assumptions

package/knowledge-bases/structured/kotlin/examples/01-reference-scenario.md

@@ -0,0 +1,3 @@
+# Reference scenario
+
+Use this example as a template for implementing and validating a small Kotlin change with the promoted rules and workflow template.