@harness-forge/cli 0.1.0

package/dist/shared/seeded-knowledge.js

@@ -0,0 +1,49 @@
+export const SEEDED_LANGUAGE_IDS = ["typescript", "java", "dotnet", "lua", "powershell"];
+const ARCHIVE_DIRECTORY_NAMES = {
+    typescript: "typescript-knowledge-base",
+    java: "java-knowledge-base",
+    dotnet: "dotnet-knowledge-base",
+    lua: "lua-knowledge-base",
+    powershell: "powershell-knowledge-base"
+};
+export function isSeededLanguageId(value) {
+    return SEEDED_LANGUAGE_IDS.includes(value);
+}
+export function getSeededArchiveDirectory(language) {
+    return ARCHIVE_DIRECTORY_NAMES[language];
+}
+export function getSeededArchivePath(language, relativePath) {
+    return `language-knowledge-bases/${getSeededArchiveDirectory(language)}/${relativePath.replaceAll("\\", "/")}`;
+}
+export function classifySeededRelativePath(relativePath) {
+    const normalized = relativePath.replaceAll("\\", "/");
+    if (normalized === "README.md") {
+        return "root-doc";
+    }
+    if (normalized === "knowledge-base.json") {
+        return "metadata";
+    }
+    if (normalized === "docs/overview.md") {
+        return "overview";
+    }
+    if (normalized === "docs/review-checklist.md") {
+        return "review-checklist";
+    }
+    if (normalized === "docs/examples-guide.md") {
+        return "examples-guide";
+    }
+    if (normalized === "docs/frameworks.md") {
+        return "framework-notes";
+    }
+    if (normalized.startsWith("examples/")) {
+        return "example";
+    }
+    if (normalized.startsWith("rules/common/")) {
+        return "common-rule";
+    }
+    if (normalized.startsWith("legacy-seed/")) {
+        return "legacy-seed";
+    }
+    return "language-rule";
+}
+//# sourceMappingURL=seeded-knowledge.js.map

package/dist/shared/seeded-knowledge.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"seeded-knowledge.js","sourceRoot":"","sources":["../../src/shared/seeded-knowledge.ts"],"names":[],"mappings":"AAAA,MAAM,CAAC,MAAM,mBAAmB,GAAG,CAAC,YAAY,EAAE,MAAM,EAAE,QAAQ,EAAE,KAAK,EAAE,YAAY,CAAU,CAAC;AAIlG,MAAM,uBAAuB,GAAqC;IAChE,UAAU,EAAE,2BAA2B;IACvC,IAAI,EAAE,qBAAqB;IAC3B,MAAM,EAAE,uBAAuB;IAC/B,GAAG,EAAE,oBAAoB;IACzB,UAAU,EAAE,2BAA2B;CACxC,CAAC;AAcF,MAAM,UAAU,kBAAkB,CAAC,KAAa;IAC9C,OAAO,mBAAmB,CAAC,QAAQ,CAAC,KAAyB,CAAC,CAAC;AACjE,CAAC;AAED,MAAM,UAAU,yBAAyB,CAAC,QAA0B;IAClE,OAAO,uBAAuB,CAAC,QAAQ,CAAC,CAAC;AAC3C,CAAC;AAED,MAAM,UAAU,oBAAoB,CAAC,QAA0B,EAAE,YAAoB;IACnF,OAAO,4BAA4B,yBAAyB,CAAC,QAAQ,CAAC,IAAI,YAAY,CAAC,UAAU,CAAC,IAAI,EAAE,GAAG,CAAC,EAAE,CAAC;AACjH,CAAC;AAED,MAAM,UAAU,0BAA0B,CAAC,YAAoB;IAC7D,MAAM,UAAU,GAAG,YAAY,CAAC,UAAU,CAAC,IAAI,EAAE,GAAG,CAAC,CAAC;IAEtD,IAAI,UAAU,KAAK,WAAW,EAAE,CAAC;QAC/B,OAAO,UAAU,CAAC;IACpB,CAAC;IAED,IAAI,UAAU,KAAK,qBAAqB,EAAE,CAAC;QACzC,OAAO,UAAU,CAAC;IACpB,CAAC;IAED,IAAI,UAAU,KAAK,kBAAkB,EAAE,CAAC;QACtC,OAAO,UAAU,CAAC;IACpB,CAAC;IAED,IAAI,UAAU,KAAK,0BAA0B,EAAE,CAAC;QAC9C,OAAO,kBAAkB,CAAC;IAC5B,CAAC;IAED,IAAI,UAAU,KAAK,wBAAwB,EAAE,CAAC;QAC5C,OAAO,gBAAgB,CAAC;IAC1B,CAAC;IAED,IAAI,UAAU,KAAK,oBAAoB,EAAE,CAAC;QACxC,OAAO,iBAAiB,CAAC;IAC3B,CAAC;IAED,IAAI,UAAU,CAAC,UAAU,CAAC,WAAW,CAAC,EAAE,CAAC;QACvC,OAAO,SAAS,CAAC;IACnB,CAAC;IAED,IAAI,UAAU,CAAC,UAAU,CAAC,eAAe,CAAC,EAAE,CAAC;QAC3C,OAAO,aAAa,CAAC;IACvB,CAAC;IAED,IAAI,UAAU,CAAC,UAAU,CAAC,cAAc,CAAC,EAAE,CAAC;QAC1C,OAAO,aAAa,CAAC;IACvB,CAAC;IAED,OAAO,eAAe,CAAC;AACzB,CAAC"}

package/docs/agents.md

@@ -0,0 +1,45 @@
+# Agents
+
+Harness Forge keeps runtime discovery visible while moving canonical installed
+AI content into the hidden `.hforge/` layer.
+
+## Primary surfaces
+
+- `AGENTS.md` for the thin repo-root guidance bridge
+- `.hforge/agent-manifest.json` for one machine-readable custom-agent contract
+- `agents/planner.md` for packaged planning expectations
+- `.agents/skills/` for discovery wrappers that route agent runtimes into the hidden installed canonical skills
+- `.agents/skills/*-engineering/` for language-aware activation that resolves into `.hforge/library/skills/` in installed workspaces
+- `.hforge/library/skills/` for the canonical installed skill library
+- `.hforge/library/rules/` and `.hforge/library/knowledge/` for hidden installed rule and knowledge surfaces
+- `.hforge/runtime/recursive/sessions/` for optional hard-task recursive
+  sessions that stay hidden alongside the rest of the AI layer
+- `docs/authoring/enhanced-skill-import.md` for curated research and validation provenance behind imported skill upgrades
+- `RESEARCH-SOURCES.md` and `VALIDATION.md` for optional pack-level provenance detail
+
+## When agents should use Harness Forge
+
+- when a repository needs target-aware Codex or Claude Code setup
+- when a task needs the seeded language-specific rules and examples
+- when a repository language matches one of the seeded engineering skills
+- when a framework-aware recommendation would be more reliable than guessing
+  from file extensions
+- when implementation should follow spec, plan, task, and validation loops
+- when templates or workflow docs reference the shipped validator bundle
+- when the application repo should stay clean and treat AI-only content as a hidden support layer
+- when a task is multi-hop, ambiguous, or architecture-heavy enough to justify
+  an explicit recursive session instead of growing the prompt
+
+## Discovery rule
+
+- use `.agents/skills/<skill>/SKILL.md` to discover the right flow quickly
+- in installed workspaces, load `.hforge/library/skills/<skill>/SKILL.md` for the actual execution contract
+- in this package source repo, authored canonical skill sources still live under `skills/<skill>/`
+- in installed workspaces, deeper references live under `.hforge/library/skills/<skill>/references/`
+- in installed workspaces, recursive runtime state lives under
+  `.hforge/runtime/recursive/sessions/<sessionId>/` and should be treated as
+  hidden operational state rather than product code
+- for custom agents that do not want to parse prose only, load
+  `.hforge/agent-manifest.json` first and treat every surface it marks
+  `treatAsProductCode: false` as AI-layer content rather than application code
+- use `docs/authoring/enhanced-skill-import.md`, `RESEARCH-SOURCES.md`, and `VALIDATION.md` only when provenance or import rationale matters

package/docs/authoring/engineering-assistant-port.md

@@ -0,0 +1,108 @@
+# Engineering Assistant Port Governance
+
+This document records how the March 2026 `engineering-assistant` archive was
+ported into Harness Forge.
+
+## Source pack
+
+- Pack name: `Engineering Assistant Skill Pack`
+- Inventory record: `manifests/catalog/engineering-assistant-import-inventory.json`
+- Imported scope:
+  - architecture and implementation orchestration guidance
+  - practical SOLID and pattern heuristics
+  - skill-composition rules for delegated specialist work
+  - project-memory expectations through `PROJECT_NOTES.md`
+  - structured change-discipline expectations through `CHANGELOG.md`
+  - OpenAI-oriented runtime metadata in `agents/openai.yaml`
+
+## Canonical outcome
+
+Harness Forge now owns one canonical engineering-assistant surface at
+`skills/engineering-assistant/SKILL.md`.
+
+The port keeps the imported pack's distinctive value:
+
+- architecture plus implementation collaboration in one skill
+- explicit trade-off framing with at least two viable options
+- named invariants and small, reversible execution slices
+- mandatory project-memory upkeep
+- mandatory change-discipline guidance for meaningful edits
+
+## Artifact decisions
+
+| Imported artifact | Outcome | Project-owned destination | Why |
+| --- | --- | --- | --- |
+| `engineering-assistant/SKILL.md` | embed | `skills/engineering-assistant/SKILL.md` | the imported responsibility is distinct and should be first-class in the library |
+| `engineering-assistant/references/*.md` | embed | `skills/engineering-assistant/references/` | the architecture, SOLID, and composition playbooks are direct runtime guidance |
+| `engineering-assistant/PROJECT_NOTES.md` | adapt | `skills/engineering-assistant/references/project-notes.md` | the structure matters, but the sample state should not ship as live package memory |
+| `engineering-assistant/CHANGELOG.md` | adapt | `skills/engineering-assistant/references/change-discipline.md` | the structure matters, but the sample entries should not ship as live package state |
+| `engineering-assistant/scripts/*.py` | adapt | this document plus later runtime-helper tasks | the behavior is valuable, but package-owned helpers should be shared and cross-agent aware |
+| `engineering-assistant/agents/openai.yaml` | translate | this document plus later runtime-wrapper tasks | metadata from one runtime becomes compatibility guidance, not a universal descriptor |
+
+## Imported metadata summary
+
+The source pack described itself as:
+
+- display name: `Engineering Assistant`
+- short description: architecture and implementation collaborator with strict
+  change logging and project notes
+- icon: `wrench`
+- accent color: `#2F6FED`
+
+Harness Forge preserves that intent in the canonical skill wording and uses the
+metadata values as provenance, not as a cross-runtime contract.
+
+## Project-memory translation
+
+The imported `PROJECT_NOTES.md` expected a maintained project snapshot,
+constraints list, stack summary, mini-ADRs, open questions, and glossary.
+
+The MVP port translates that into:
+
+- `skills/engineering-assistant/references/project-notes.md` as the canonical
+  structure and update guidance
+- helper-surface planning in the inventory so later runtime commands can update
+  those notes deterministically
+
+Until packaged helper commands land, operators should use the canonical
+reference manually instead of relying on the original Python helper.
+
+## Change-discipline translation
+
+The imported `CHANGELOG.md` and `scripts/change_log.py` enforced structured
+entries with:
+
+- monotonically increasing ids
+- UTC timestamps
+- typed change categories
+- one-line summaries
+- short detail bullets
+- touched-file lists
+
+The MVP port preserves those rules in
+`skills/engineering-assistant/references/change-discipline.md` and records the
+helper-script translation target in the inventory. Until package-owned commands
+land, operators should apply the same structure manually.
+
+## Runtime compatibility baseline
+
+The MVP slice intentionally stops short of claiming runtime-native parity and
+does not claim runtime-native parity for any target yet.
+
+- Codex: translated support through canonical skill and maintainer guidance
+- Claude Code: translated support through canonical skill and maintainer guidance
+- Cursor: guidance-only support during MVP
+- OpenCode: guidance-only support during MVP
+
+This keeps the package honest while later user stories add wrappers, target
+adapters, and reusable helper commands.
+
+## Acceptance rules for future updates
+
+- keep `manifests/catalog/engineering-assistant-import-inventory.json` aligned
+  with every imported artifact and follow-up translation
+- do not ship sample-pack notes or changelog entries as live package state
+- do not claim runtime-native metadata or hook parity until the translated
+  package-owned surfaces exist
+- prefer one canonical `skills/engineering-assistant/` surface over multiple
+  diverging copies

package/docs/authoring/enhanced-skill-import.md

@@ -0,0 +1,89 @@
+# Enhanced Skill Import Governance
+
+This document records how the March 2026 enhanced-skills archive was absorbed
+into Harness Forge.
+
+## Source pack
+
+- Pack name: `Harness Forge Enhanced Skills Pack`
+- Inventory record: `manifests/catalog/enhanced-skill-import-inventory.json`
+- Imported focus areas:
+  - operational review depth for onboarding, ADRs, APIs, and migrations
+  - coordination guidance for worktrees and staged modernization
+  - deeper language guidance for TypeScript, .NET, Lua, and JavaScript
+
+## Embedding decisions
+
+| Area | Outcome | Why it matters |
+| --- | --- | --- |
+| overlapping canonical skills | merge into existing `skills/<skill>/` surfaces | Harness Forge keeps one active canonical skill per responsibility |
+| richer supporting references | merge into the owning `references/` pack | deeper heuristics ship without inventing duplicate skill identities |
+| imported wrappers | track destination now, align wrapper copy in the discovery phase | discovery drift stays explicit instead of being silently forgotten |
+| pack README, validation, and research notes | preserve as maintainer-facing provenance only | pack context remains reviewable without creating a second runtime package |
+
+## Discovery model
+
+- `.agents/skills/<skill>/SKILL.md` is the lightweight discovery layer for agent runtimes
+- installed workspaces treat `.hforge/library/skills/<skill>/SKILL.md` as the canonical execution contract
+- installed workspaces treat `.hforge/library/skills/<skill>/references/` as the deeper runtime-facing heuristics and templates
+- this package source repo still authors those same canonical skill surfaces under `skills/<skill>/` before install remaps them into `.hforge/`
+- `RESEARCH-SOURCES.md` and `VALIDATION.md` are project-owned pack-level provenance companions for additional maintainer detail
+- this document carries curated research and validation provenance so agents do
+  not need to depend on raw imported archive files
+
+## Canonical skill outcomes
+
+The imported archive upgraded these canonical skills directly:
+
+- `skills/repo-onboarding/`
+- `skills/architecture-decision-records/`
+- `skills/api-contract-review/`
+- `skills/db-migration-review/`
+- `skills/parallel-worktree-supervisor/`
+- `skills/repo-modernization/`
+- `skills/typescript-engineering/`
+- `skills/dotnet-engineering/`
+- `skills/lua-engineering/`
+- `skills/javascript-engineering/`
+
+Most of those were merges into existing responsibilities. `javascript-engineering`
+stays promoted as a distinct runtime-focused engineering skill rather than a
+TypeScript appendix.
+
+Published and local installed workspaces remap those canonical outcomes into
+`.hforge/library/skills/` while leaving `.agents/skills/` as the thin visible
+discovery layer.
+
+## Provenance summary
+
+The archive stated that it upgraded ten skills, added missing wrappers, and
+grounded its guidance in official docs and upstream repositories for:
+
+- ADR patterns and MADR discipline
+- OpenAPI, AsyncAPI, JSON Schema, Redocly, Spectral, and Buf
+- EF Core, Flyway, Liquibase, Atlas, Prisma, and online migration workflows
+- git worktree and stacked-diff review practices
+- modernization tooling such as Renovate, OpenRewrite, and upgrade assistants
+- .NET, TypeScript, JavaScript, Lua, Neovim, OpenResty, and related tooling
+
+The archive also reported pack-local validation success for:
+
+- `node scripts/ci/validate-skill-depth.mjs`
+- `node scripts/ci/validate-no-placeholders.mjs`
+
+It explicitly called out that full repo-wide smoke results in the export
+environment still depended on unrelated upstream issues outside the skills-only
+bundle. Harness Forge therefore keeps release truth in its own validators.
+
+## Acceptance rules for future imports
+
+- Record every imported skill, wrapper, reference pack, and provenance item in
+  the inventory before release.
+- Merge overlapping responsibilities into the existing canonical skill instead
+  of creating duplicates.
+- Promote a new skill only when it owns a distinct runtime responsibility that
+  should remain discoverable on its own.
+- Keep provenance human-readable and maintainer-facing, never mixed into
+  runtime `SKILL.md` entrypoints.
+- Treat wrapper alignment, package-surface updates, and validation updates as
+  required follow-up work, not optional cleanup.

package/docs/authoring/skills.md

@@ -0,0 +1,53 @@
+# Skill Authoring Contract
+
+Harness Forge skills must behave like reusable operating systems, not short
+prompt fragments.
+
+## Required sections
+
+- trigger conditions
+- first inspection order
+- workflow stages
+- output contract
+- validation path
+- failure modes
+- escalation rules
+
+## Authoring rules
+
+- start from promoted `rules/common/` and the most specific language or
+  framework rules available
+- keep the first inspection paths concrete so an agent can recover quickly in an
+  unfamiliar repository
+- make outputs deterministic enough to review later
+- include references when the skill depends on deeper heuristics or checklists
+- if a skill is safety-sensitive, call out explicit stop conditions
+
+## Imported skill packs
+
+- inventory single-skill ports such as `engineering-assistant` in
+  `manifests/catalog/engineering-assistant-import-inventory.json`
+- keep maintainer-facing provenance for single-skill ports in
+  `docs/authoring/engineering-assistant-port.md`
+- inventory every imported runtime surface in
+  `manifests/catalog/enhanced-skill-import-inventory.json`
+- merge overlapping responsibilities into the existing canonical skill instead
+  of creating duplicates
+- promote a new skill only when it owns a distinct runtime responsibility that
+  should remain discoverable on its own
+- keep pack provenance in maintainer-facing docs such as
+  `docs/authoring/enhanced-skill-import.md`, not in runtime entrypoints
+- update wrappers, package-surface coverage, and validation in the same feature
+  lineage so imports do not drift silently
+
+## Good operational artifact examples
+
+- onboarding summary with repo map, risks, and next actions
+- release report with pass or fail gates and blocking findings
+- security scan summary with attack surface, risk rating, and remediation queue
+
+## Anti-patterns
+
+- skills that only say "analyze the repo" without inspection order
+- skills that have no verification or escalation step
+- skills that cannot explain what output they produce

package/docs/benchmark-scenarios.md

@@ -0,0 +1,29 @@
+# Benchmark Scenarios
+
+Harness Forge uses representative fixture repositories to keep recommendation
+quality and support honesty grounded in observable behavior.
+
+## Current benchmark set
+
+- `typescript-web-app`: React + Vite style frontend
+- `python-service`: FastAPI-oriented backend
+- `java-service`: Spring-oriented service shape
+- `dotnet-api`: ASP.NET Core API
+- `go-cli`: Go command-line application
+- `monorepo`: mixed-language or multi-package workspace
+- `legacy-repo`: older repository with drift and uneven conventions
+- `security-service`: security-sensitive service shape
+
+## What benchmarks validate
+
+- language and framework detection
+- evidence-backed recommendation ranking
+- profile and skill recommendations
+- support-surface claims made in docs and manifests
+
+## Related surfaces
+
+- `tests/fixtures/benchmarks/`
+- `scripts/intelligence/`
+- `docs/catalog/framework-packs.md`
+- `manifests/catalog/framework-assets.json`

package/docs/catalog/framework-packs.md

@@ -0,0 +1,22 @@
+# Framework Packs
+
+Framework packs extend language packs with higher-signal repo detection and
+workflow cues.
+
+## First framework wave
+
+- `react`
+- `vite`
+- `express`
+- `fastapi`
+- `django`
+- `spring-boot`
+- `aspnet-core`
+- `gin`
+- `ktor`
+- `symfony`
+- `nextjs`
+- `laravel`
+
+Each framework pack points back to a base language pack and exposes detection
+signals in `manifests/catalog/framework-assets.json`.

package/docs/catalog/frameworks/aspnet-core.md

@@ -0,0 +1,18 @@
+# ASP.NET Core Framework Pack
+
+Use this pack when the repository exposes a .NET web app or API through ASP.NET Core.
+
+## Primary signals
+
+- `.csproj` uses `Microsoft.NET.Sdk.Web`
+- `Program.cs` uses `WebApplication.CreateBuilder`
+
+## Companion surfaces
+
+- `lang:dotnet`
+- service hardening and deployment validation
+
+## Validation cues
+
+- confirm middleware ordering, auth, and DI registrations remain correct
+- verify endpoint and startup behavior after transport or config changes

package/docs/catalog/frameworks/django.md

@@ -0,0 +1,18 @@
+# Django Framework Pack
+
+Use this pack when the repository is a Django service or web application.
+
+## Primary signals
+
+- `manage.py`
+- Django dependencies in Python package manifests
+
+## Companion surfaces
+
+- `lang:python`
+- migration and security-focused reviews
+
+## Validation cues
+
+- check settings, migrations, and ORM usage together
+- validate auth, forms, and admin changes with targeted tests

package/docs/catalog/frameworks/express.md

@@ -0,0 +1,18 @@
+# Express Framework Pack
+
+Use this pack when the repository exposes HTTP routes through Express.
+
+## Primary signals
+
+- `package.json` depends on `express`
+- route or server entrypoints exist under `src/`
+
+## Companion surfaces
+
+- `lang:typescript`
+- `skill:security-scan`
+
+## Validation cues
+
+- confirm request validation, auth boundaries, and error handling remain intact
+- verify route wiring and middleware ordering after changes

package/docs/catalog/frameworks/fastapi.md

@@ -0,0 +1,18 @@
+# FastAPI Framework Pack
+
+Use this pack when the repository is a Python API or service built with FastAPI.
+
+## Primary signals
+
+- `pyproject.toml` or `requirements.txt` references `fastapi`
+- app modules create `FastAPI(...)`
+
+## Companion surfaces
+
+- `lang:python`
+- API contract and release-readiness review paths
+
+## Validation cues
+
+- confirm response models, dependency injection, and async boundaries still hold
+- verify API tests and startup wiring after endpoint changes

package/docs/catalog/frameworks/gin.md

@@ -0,0 +1,18 @@
+# Gin Framework Pack
+
+Use this pack when the repository uses Gin for Go HTTP services.
+
+## Primary signals
+
+- `go.mod` includes `gin-gonic/gin`
+- server bootstrap calls `gin.Default()`
+
+## Companion surfaces
+
+- `lang:go`
+- request validation and release-readiness checks
+
+## Validation cues
+
+- confirm route registration, middleware order, and request binding behavior
+- run focused service tests or smoke commands after handler changes

package/docs/catalog/frameworks/ktor.md

@@ -0,0 +1,18 @@
+# Ktor Framework Pack
+
+Use this pack when the repository uses Ktor for Kotlin server work.
+
+## Primary signals
+
+- Gradle config references `io.ktor`
+- server bootstrap uses `embeddedServer(...)`
+
+## Companion surfaces
+
+- `lang:kotlin`
+- API and dependency management guidance
+
+## Validation cues
+
+- verify plugin installation, auth, and serialization behavior together
+- confirm testApplication coverage or equivalent smoke checks remain valid

package/docs/catalog/frameworks/laravel.md

@@ -0,0 +1,14 @@
+# Laravel Framework Pack
+
+Use this framework pack when the repository is a Laravel application and the PHP
+language pack is also relevant.
+
+## Primary signals
+
+- `composer.json` references `laravel/framework`
+- `artisan` is present
+
+## Validation cues
+
+- review migrations, service providers, and route changes together
+- run the repo's PHP test suite or targeted smoke steps after behavior changes

package/docs/catalog/frameworks/nextjs.md

@@ -0,0 +1,14 @@
+# Next.js Framework Pack
+
+Use this framework pack when the repository is a Next.js application and the
+TypeScript language pack is also relevant.
+
+## Primary signals
+
+- `package.json` depends on `next`
+- `next.config.*` is present
+
+## Validation cues
+
+- confirm route, layout, and runtime-boundary changes with app-specific checks
+- verify build or preview behavior when config or data loading changes

package/docs/catalog/frameworks/react.md

@@ -0,0 +1,18 @@
+# React Framework Pack
+
+Use this pack when the repository ships React components or a React application.
+
+## Primary signals
+
+- `package.json` depends on `react`
+- the repo contains `.tsx` component files
+
+## Companion surfaces
+
+- `lang:typescript`
+- component-oriented verification and UI workflow guidance
+
+## Validation cues
+
+- verify rendering and state changes with the repo's frontend test stack
+- confirm shared types and props remain stable across component boundaries

package/docs/catalog/frameworks/spring-boot.md

@@ -0,0 +1,18 @@
+# Spring Boot Framework Pack
+
+Use this pack when the repository uses Spring Boot for APIs, jobs, or backend services.
+
+## Primary signals
+
+- `pom.xml` or Gradle config references `spring-boot`
+- application bootstrap classes exist in `src/main/java`
+
+## Companion surfaces
+
+- `lang:java`
+- service validation and release-readiness checks
+
+## Validation cues
+
+- verify dependency injection, config profiles, and integration points together
+- confirm startup, controller, and data-layer behavior with tests or smoke checks

package/docs/catalog/frameworks/symfony.md

@@ -0,0 +1,18 @@
+# Symfony Framework Pack
+
+Use this pack when the repository is a Symfony PHP application or service.
+
+## Primary signals
+
+- `composer.json` references `symfony/*`
+- `bin/console` is present
+
+## Companion surfaces
+
+- `lang:php`
+- migration and release-readiness checks
+
+## Validation cues
+
+- check service configuration, routing, and env handling together
+- confirm console commands and request flows after framework changes

package/docs/catalog/frameworks/vite.md

@@ -0,0 +1,18 @@
+# Vite Framework Pack
+
+Use this pack when the repository uses Vite as the primary frontend build tool.
+
+## Primary signals
+
+- `vite.config.*`
+- `package.json` depends on `vite`
+
+## Companion surfaces
+
+- `lang:typescript`
+- React or vanilla frontend workflows depending on the repo shape
+
+## Validation cues
+
+- verify local build and dev-server assumptions before changing config
+- check path aliases and environment handling when build behavior changes

package/docs/catalog/language-packs.md

@@ -0,0 +1,39 @@
+# Language Pack Catalog
+
+Every first-class pack now has a matching rule surface, skill, workflow, and
+knowledge source.
+
+## Seeded packs
+
+- TypeScript
+- Java
+- .NET
+- Lua
+- PowerShell
+
+## Structured packs
+
+- Python
+- Go
+- Kotlin
+- Rust
+- C++
+- PHP
+- Perl
+- Swift
+- Shell
+
+## Depth expectations
+
+- docs explain when to install the pack and what it covers
+- rules provide layered guidance for coding style, patterns, testing, security,
+  and tooling
+- skills define activation, load order, execution contract, validation, and
+  escalation
+- `.agents/skills/` wrappers should route discovery into the canonical
+  `skills/` surface rather than acting as a second source of truth
+- workflows provide a language-aware implementation loop
+- examples or source knowledge remain traceable to the pack manifest
+
+Each pack participates in recommendation output through the repo-intelligence
+pipeline and can be inspected through `manifests/catalog/language-assets.json`.