@jterrats/open-orchestra 1.0.4 → 1.0.5

package/docs/secret-scanning-gitleaks.md

@@ -0,0 +1,53 @@
+# Secret Scanning With Gitleaks
+
+Open Orchestra uses Gitleaks as the primary repository secret-scanning gate.
+The lightweight Node scanner remains as a local fallback when the `gitleaks`
+binary is not installed.
+
+## Local Use
+
+```bash
+npm run secret-scan
+```
+
+When `gitleaks` is available on `PATH`, the command runs:
+
+```bash
+gitleaks dir . --config .gitleaks.toml --redact --no-banner
+```
+
+When the binary is unavailable, the fallback scanner checks common private key,
+cloud key, token, password, and API key patterns so offline development still
+has a minimum guardrail.
+
+## CI
+
+The CI quality job installs the pinned Gitleaks binary and runs it before the
+precommit gate. The precommit gate then calls `npm run secret-scan`, which uses
+the same Gitleaks configuration in CI because the binary is already installed.
+
+## Configuration
+
+Rules live in `.gitleaks.toml` and extend the default Gitleaks ruleset.
+Allowlists are limited to generated/dependency paths and explicit placeholder
+values such as `<secret>` or GitHub Actions `${{ secrets.NAME }}` references.
+
+Do not allowlist real secrets. Rotate and purge the secret instead.
+
+## Operational SaaS Boundary
+
+Repository scanning is not enough for a SaaS/runtime deployment. Runtime inputs
+also need secret and prompt-injection guardrails before agents or providers can
+read them:
+
+- prompts
+- lessons learned
+- evidence
+- logs
+- uploaded artifacts
+- model outputs
+- GitHub issue bodies and comments
+- tenant integrations
+
+Operational scans must redact or quarantine findings, record provenance, and
+apply tenant-specific retention and regulatory policies.

package/docs/site-manifest.json

@@ -112,6 +112,9 @@
     "links": [
       { "title": "Adoption guide", "source": "docs/adoption-guide.md", "heading": "Open Orchestra 1.0.0 Adoption Guide" },
       { "title": "Core command surface", "source": "docs/core-command-surface.md", "heading": "Core Command Surface" },
+      { "title": "Duplicate-code enforcement", "source": "docs/duplicate-code-enforcement.md", "heading": "Duplicate-Code Enforcement" },
+      { "title": "Sonar quality gates", "source": "docs/sonar-quality-gates.md", "heading": "Sonar Quality Gates" },
+      { "title": "Sonar architecture model", "source": "docs/sonar-architecture-model.md", "heading": "Sonar Architecture Model" },
       { "title": "Runtime adapters", "source": "docs/runtime-adapters.md", "heading": "Runtime Adapters" },
       { "title": "Site content workflow", "source": "docs/site-content-workflow.md", "heading": "Public Site Content Workflow" }
     ]
@@ -119,6 +122,8 @@
   "releaseDocs": {
     "links": [
       { "title": "Release test matrix", "source": "docs/release-test-matrix.md", "heading": "1.0.0 Release Test Matrix" },
+      { "title": "Sonar quality gates", "source": "docs/sonar-quality-gates.md", "heading": "Sonar Quality Gates" },
+      { "title": "Sonar architecture model", "source": "docs/sonar-architecture-model.md", "heading": "Sonar Architecture Model" },
       { "title": "QA evidence", "source": "docs/site-content-workflow.md", "heading": "QA Evidence" },
       { "title": "Package naming", "source": "docs/package-naming.md", "heading": "Package Naming Decision" },
       { "title": "Upgrade dogfooding", "source": "README.md", "heading": "Quick Start" }

package/docs/sonar-architecture-model.md

@@ -0,0 +1,178 @@
+# Sonar Architecture Model
+
+This document defines the intended module boundaries that Sonar architecture
+analysis should eventually enforce for Open Orchestra. Until Sonar-specific
+directives are configured, this is the portable source of truth for architecture
+review, code review, and workflow gate evidence.
+
+## Domains
+
+### CLI and Command Surface
+
+Files:
+
+- `bin/`
+- `src/*-commands.ts`
+- `src/commands.ts`
+
+Responsibilities:
+
+- parse command input;
+- call domain services;
+- format CLI output;
+- avoid business logic beyond validation and dispatch.
+
+Expected dependencies:
+
+- may depend on domain services, workflow services, config loaders, and typed
+  output helpers;
+- must not own persistence rules, workflow state transitions, provider routing,
+  or web UI behavior.
+
+### Workflow and Delivery Domain
+
+Files:
+
+- `src/workflow*.ts`
+- `src/task*.ts`
+- `src/release*.ts`
+- `src/review*.ts`
+- `src/evidence*.ts`
+- `src/qa*.ts`
+
+Responsibilities:
+
+- task lifecycle;
+- workflow phases and gates;
+- handoffs, reviews, evidence, acceptance coverage, release readiness.
+
+Expected dependencies:
+
+- may depend on persistence helpers, domain types, policy checks, and prompt
+  registry services;
+- should expose narrow service APIs for command and web entry points.
+
+### Runtime, Model, Budget, and Telemetry
+
+Files:
+
+- `src/model*.ts`
+- `src/runtime*.ts`
+- `src/budget*.ts`
+- `src/telemetry*.ts`
+
+Responsibilities:
+
+- provider routing;
+- model provenance;
+- cost, token, runtime, and budget controls;
+- telemetry consent, export, and submission audit.
+
+Expected dependencies:
+
+- may depend on workflow identifiers and policy/config types;
+- must not depend on UI code or generated site assets.
+
+### Profiles, Roles, Skills, and Guidance
+
+Files:
+
+- `src/profiles/`
+- `src/roles/`
+- `src/skills*.ts`
+- `src/generators/`
+- `src/prompt*.ts`
+- `skills/`
+- `rules/`
+
+Responsibilities:
+
+- role metadata;
+- runtime capability selection;
+- skill rendering;
+- generated guidance and prompt registry validation.
+
+Expected dependencies:
+
+- may depend on shared domain types and generation utilities;
+- must keep role/capability data centralized instead of hardcoding lists across
+  commands or UI surfaces.
+
+### Web API and Web Console
+
+Files:
+
+- `src/web-api*.ts`
+- `src/web-console-client.js`
+- `web-console/src/`
+
+Responsibilities:
+
+- expose local read/write APIs;
+- render task, workflow, evidence, recovery, provider, and settings views;
+- keep user-facing flows responsive, accessible, and evidence-oriented.
+
+Expected dependencies:
+
+- web API may depend on domain services;
+- React/client code should not import Node-only modules or mutate workflow files
+  directly.
+
+### Site and Documentation Publishing
+
+Files:
+
+- `site/`
+- `scripts/generate-site-content.js`
+- `docs/site-manifest.json`
+- public documentation under `docs/`
+
+Responsibilities:
+
+- generate and publish public documentation content;
+- render docs-driven site pages;
+- keep public docs separate from internal workflow evidence.
+
+Expected dependencies:
+
+- may read approved docs manifests and public content;
+- must not depend on local workflow state, secrets, or private evidence.
+
+### Extensions
+
+Files:
+
+- `extensions/`
+
+Responsibilities:
+
+- editor integration;
+- command invocation adapters;
+- local service bridge behavior.
+
+Expected dependencies:
+
+- may call public CLI/API contracts;
+- should not duplicate workflow business rules already owned by `src/`.
+
+## Boundary Rules
+
+- Commands stay logic-light and delegate to services.
+- Domain services do not import from web console, site, or extension code.
+- Generated assets and docs do not become runtime sources of truth.
+- Capability, role, provider, command, and workflow phase lists use centralized
+  domain helpers instead of repeated hardcoded arrays.
+- Security-sensitive code paths keep auth, secrets, file paths, shell execution,
+  network calls, and provider credentials behind explicit services and tests.
+- Architecture changes that cross these boundaries need an Orchestra decision or
+  ADR-style note before implementation.
+
+## Sonar Directive Adoption
+
+When Sonar directive files are introduced, they should encode the domains above
+as enforceable layers or dependency rules. The implementation task must include:
+
+- the directive format supported by the connected Sonar edition;
+- a failing/passing validation example;
+- a Sonar run showing directives consumed by the architecture sensor;
+- a review that maps any initial violations to GitHub issues or accepted risks.

package/docs/sonar-quality-gates.md

@@ -0,0 +1,178 @@
+# Sonar Quality Gates
+
+Open Orchestra uses Sonar as a repository and SaaS project-quality signal. It
+does not replace secret scanning or runtime policy enforcement.
+
+## Repo Audit
+
+The repository includes `sonar-project.properties` and a dedicated GitHub
+Actions workflow at `.github/workflows/sonar.yml`.
+
+Required GitHub secret:
+
+- `SONAR_TOKEN`: token for SonarQube Cloud or SonarQube Server.
+
+Optional GitHub secret:
+
+- `SONAR_HOST_URL`: required only for self-hosted SonarQube Server. Leave unset
+  for SonarQube Cloud.
+
+The workflow skips analysis when `SONAR_TOKEN` is not configured. This keeps
+forks and offline development usable while making Sonar a CI quality gate for
+configured environments.
+
+The workflow supports remote quality gate enforcement when the repository
+variable `SONAR_QUALITY_GATE_WAIT=true` is configured. In that mode the scanner
+runs with `sonar.qualitygate.wait=true` and `sonar.qualitygate.timeout=300`. A
+failed quality gate fails the GitHub Actions job instead of reporting only a
+successful scanner upload.
+
+The token used for this mode must be able to read the Sonar project and quality
+gate status. If the scanner can upload analysis but the wait step fails with
+`Project not found`, update the `SONAR_TOKEN` permissions or keep
+`SONAR_QUALITY_GATE_WAIT` unset until the token can read the project.
+
+Recommended minimum quality gate for new code:
+
+- 0 new blocker or critical issues.
+- 0 new vulnerabilities.
+- Security hotspots reviewed before release.
+- Duplicated lines on new code below 3%.
+- Maintainability rating A on new code.
+- Reliability rating A on new code.
+- Coverage reported from `coverage/lcov.info` for source files on every Sonar
+  run.
+
+## Coverage Publishing
+
+The Sonar workflow runs `npm run test:coverage` before analysis. That command
+builds the TypeScript sources, runs the Node test suite through `c8`, and writes
+LCOV to `coverage/lcov.info`.
+
+`sonar.javascript.lcov.reportPaths=coverage/lcov.info` publishes the LCOV file
+to Sonar. The report is generated from source maps, so coverage entries map back
+to `src/*.ts` files instead of generated `dist/*.js` files.
+
+Coverage is intentionally split by surface:
+
+- Core TypeScript modules: included in LCOV.
+- CLI entry points under `bin/`: included in LCOV when exercised by tests.
+- VS Code extension runtime files under `extensions/`: included in LCOV when
+  exercised by tests.
+- Site and web console: excluded from LCOV until browser coverage is wired in;
+  they require Playwright screenshots, traces, videos, or E2E reports as release
+  evidence.
+- Tests and E2E files: excluded from coverage accounting.
+- Scripts: excluded from product coverage, but validated through CI commands
+  and targeted script tests where they enforce delivery gates.
+
+`coverage/` is ignored locally and should not be committed.
+
+## New Code Baseline
+
+The project uses `main` as the new-code reference branch through
+`sonar.newCode.referenceBranch=main`. This aligns Sonar's changed-lines and
+new-code behavior with the repository default branch and avoids falling back to a
+legacy `master` reference.
+
+The Sonar workflow also creates local `master` compatibility refs that point to
+`origin/main` inside the temporary GitHub Actions checkout. This does not create
+or push a real `master` branch; it only gives Sonar's SCM changed-lines analysis
+a legacy fallback ref when the remote Sonar project still asks for `master`.
+
+## Architecture Analysis
+
+The intended architecture model is documented in
+[`sonar-architecture-model.md`](sonar-architecture-model.md). Sonar's scanner can
+discover JavaScript and TypeScript dependency graphs today, but Open Orchestra
+does not yet commit Sonar-specific architecture directive files because the
+portable architecture source of truth is still the repository documentation,
+rules, and Orchestra review gates.
+
+Until Sonar directives are adopted, architecture violations are enforced through:
+
+- repo standards in `AGENTS.md` and `rules/*.mdc`;
+- architecture gate decisions and ADR-style records;
+- code review against domain boundaries;
+- tests that protect command contracts, workflow behavior, and generated
+  guidance.
+
+When Sonar directive support is configured for this project, it should use the
+same domains from `sonar-architecture-model.md`; the two models must not diverge.
+
+## Dependency Analysis
+
+## Tool Boundaries
+
+Use the tools together instead of treating one as a replacement for another:
+
+- Sonar: bugs, code smells, maintainability, duplication, coverage, and security
+  hotspots.
+- Sonar dependency analysis/SCA: enabled when the connected Sonar plan supports
+  it. Dependency manifests such as `package-lock.json` must remain visible to
+  the scanner.
+- Gitleaks: secrets in code, history, issues, prompts, lessons, evidence, logs,
+  artifacts, and model output.
+- `npm audit`: local and CI dependency vulnerability control for this package.
+- jscpd: local duplicate-code detection and fast copy-paste feedback.
+- `collection-standards`: semantic duplication of domain lists, command
+  matrices, role/status lists, providers, fixtures, selectors, and validators.
+
+If a Sonar run still reports `Dependency analysis skipped`, treat that as an
+environment or plan-level SCA limitation, not as proof that dependency risk is
+covered. Release evidence must then include `npm audit` and secret scanning
+results, plus Dependabot or equivalent repository alerts when available.
+
+When Sonar reports duplicated code that represents a repeated domain collection,
+the remediation should load `collection-standards` and extract a typed source of
+truth rather than only reshaping the copied block.
+
+## SaaS Findings Architecture
+
+Future SaaS integration should import or correlate Sonar findings as project
+quality evidence without moving tenant source code through Open Orchestra unless
+the tenant explicitly enables that mode.
+
+Minimum SaaS controls:
+
+- Bind each Sonar project to one tenant and one Open Orchestra project.
+- Store Sonar tokens per tenant/project with least privilege and rotation
+  metadata.
+- Keep tenant findings isolated by tenant id, project id, provider, branch, and
+  scan id.
+- Persist finding provenance: detector, rule id, severity, component, branch,
+  commit, quality gate status, imported timestamp, actor, and review state.
+- Convert findings into Orchestra evidence, reviews, or GitHub issues with
+  explicit owner and severity mapping.
+- Apply retention policies per tenant and regulation profile.
+- Never expose another tenant's findings, source paths, or scan metadata.
+- Do not use Sonar as a prompt/log/secret scanner; route those surfaces through
+  Gitleaks/redaction/quarantine policy before they reach agents or providers.
+- Use `.gitleaks.toml` and `npm run secret-scan` for repository scanning.
+  Runtime/SaaS secret scanning needs additional tenant-aware redaction,
+  quarantine, provenance, and retention controls.
+
+Suggested SaaS flow:
+
+1. Tenant connects Sonar project with scoped token.
+2. Open Orchestra stores provider binding and quality gate expectations.
+3. CI or webhook publishes scan metadata to the SaaS.
+4. SaaS imports quality gate status and selected findings.
+5. Findings are deduplicated against existing Orchestra evidence/issues.
+6. Security, Tech Lead, QA, or Release Manager reviews findings based on
+   severity and release impact.
+7. Approved mappings become task evidence, review blockers, or GitHub issues.
+
+## Release Readiness
+
+For this repository, Sonar should be treated as:
+
+- Required when `SONAR_TOKEN` is configured in CI.
+- Blocking at the remote quality gate level when `SONAR_QUALITY_GATE_WAIT=true`
+  and the token has read permission for the Sonar project.
+- Advisory for local/offline development.
+- Blocker for release when the configured quality gate fails on new code.
+
+For SaaS tenants, whether Sonar is required or advisory is a tenant policy
+decision. Regulated tenants may require quality gate pass evidence before
+release approval.

package/docs/task-split-assessment.md

@@ -0,0 +1,34 @@
+# Task Split Assessment
+
+Open Orchestra treats oversized work as an advisory delivery risk before
+implementation starts. The goal is not to block small tasks; it is to make PO/BA
+and Architect reviews explicit when one backlog item is trying to carry multiple
+stories or too much technical coupling.
+
+## Ownership
+
+- Product Owner / BA review functional oversize: multiple journeys, unrelated
+  outcomes, too many acceptance criteria, hidden support/release scope, or UX
+  discovery that expands the story.
+- Architect reviews technical complexity: too many modules, boundaries,
+  integrations, data changes, runtime changes, UI changes, infra changes, or
+  release surfaces in one task.
+
+## Expected Output
+
+When split risk is found, the reviewer records a recommendation with:
+
+- rationale
+- proposed child stories or technical slices
+- dependency order
+- risks
+- owner roles
+
+Routine small fixes stay as one task when they do not exceed the advisory
+thresholds.
+
+## CLI Surface
+
+`orchestra workflow phase-plan --task <id> --json` includes
+`splitAssessment`. The field is advisory and can be attached to a review,
+clarification, decision, or follow-up task.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jterrats/open-orchestra",
-  "version": "1.0.4",
+  "version": "1.0.5",
   "type": "module",
   "workspaces": [
     "extensions/vscode-open-orchestra",
@@ -14,12 +14,14 @@
     "build": "tsc && npm run build:web",
     "typecheck": "tsc --noEmit",
     "test": "npm run build && node --test test/**/*.js extensions/**/*.test.cjs",
+    "test:coverage": "npm run build && c8 --reporter=lcov --reports-dir coverage --exclude \"test/**\" --exclude \"e2e/**\" --exclude \"extensions/**/test/**\" --exclude \"dist/assets/**\" --exclude \"dist/web-console/**\" node --test test/**/*.js extensions/**/*.test.cjs",
     "test:e2e": "npm run build && npm run site:build && playwright test",
     "test:e2e:init": "node --test e2e/init-onboarding.test.js",
     "lint": "eslint . && prettier --check \"{bin,e2e,scripts,test,src}/**/*.js\" \"{site,web-console}/src/**/*.{css,js,jsx}\" \"{site,web-console}/*.{html,js,json}\" \"extensions/**/*.{cjs,json,md}\" \"src/**/*.ts\" \"*.{js,json}\"",
     "format": "prettier --write \"{bin,e2e,scripts,test,src}/**/*.js\" \"{site,web-console}/src/**/*.{css,js,jsx}\" \"{site,web-console}/*.{html,js,json}\" \"extensions/**/*.{cjs,json,md}\" \"src/**/*.ts\" \"*.{js,json}\"",
     "secret-scan": "node scripts/secret-scan.js",
     "security:audit": "node scripts/security-audit.js",
+    "duplicates": "jscpd --config .jscpd.json",
     "validate:workflow": "node scripts/validate-workflow.js",
     "release:matrix": "node scripts/release-test-matrix.js",
     "performance:bench": "npm run build && node scripts/performance-benchmark.js",
@@ -40,9 +42,11 @@
     "@eslint/js": "^10.0.1",
     "@playwright/test": "^1.59.1",
     "@types/node": "^25.6.0",
+    "c8": "^11.0.0",
     "chart.js": "^4.5.1",
     "esbuild": "^0.28.0",
     "eslint": "^10.2.1",
+    "jscpd": "^4.2.3",
     "prettier": "^3.8.3",
     "typescript": "^6.0.3",
     "typescript-eslint": "^8.59.0"

package/skills/oclif-plugin-development/SKILL.md

@@ -0,0 +1,118 @@
+# Oclif Plugin Development
+
+Use this skill when a task designs, implements, tests, packages, or reviews an
+Open Orchestra plugin based on oclif, TypeScript, React, Vite, hooks, manifests,
+or CLI command extensions.
+
+## When To Load
+
+- Trigger: `oclif`
+- Trigger: `plugin`
+- Trigger: `cli plugin`
+- Trigger: `command plugin`
+- Trigger: `hook`
+- Trigger: `manifest`
+- Trigger: `package exports`
+- Trigger: `npm plugin`
+- Trigger: `React/Vite plugin UI`
+- Trigger: `TypeScript plugin package`
+
+## Architecture
+
+- Treat plugin specialization as an on-demand skill, not as a permanent role
+  profile. Developer, Architect, QA, Security, DevOps, UX, or Tech Lead can use
+  this skill when the task requires plugin work.
+- Keep command classes or command modules nearly logicless: parse flags/args,
+  call one service/use-case, format output, and map expected errors to
+  user-safe messages.
+- Put business rules, workflow policy, persistence, batching, retries, plugin
+  discovery, and registry mutations in domain services or use-cases.
+- Define public plugin contracts before implementation: plugin id, supported
+  host version, commands, hooks, capabilities, permissions, configuration,
+  outputs, evidence expectations, and compatibility constraints.
+- Prefer typed registries and manifest-derived metadata over hardcoded command
+  or hook lists. Load `collection-standards` when plugin work repeats commands,
+  hooks, providers, roles, statuses, selectors, fixtures, or validators.
+
+## Oclif CLI Standards
+
+- Use TypeScript and typed flags/args.
+- Keep stdout, stderr, exit code, and JSON output stable and testable.
+- Provide JSON output for machine consumers when a command returns structured
+  data.
+- Keep help, examples, aliases, deprecations, and hidden/internal command status
+  explicit.
+- Treat hooks as integration points with clear ordering, idempotency, timeout,
+  failure, and observability behavior.
+- Do not hide network calls, filesystem writes, shell execution, or destructive
+  actions inside command parsing.
+
+## Package Standards
+
+- Prefer ESM-first package structure unless compatibility requires otherwise.
+- Define `exports`, `types`, files included in the package, and supported Node
+  versions.
+- Keep package metadata, command metadata, plugin manifest data, and docs
+  derived from one source where possible.
+- Validate install/link/package smoke behavior before release.
+- Use semantic versioning and document host compatibility or migration needs.
+
+## Plugin Capability Manifest
+
+A plugin capability contract should declare:
+
+- plugin id and display name;
+- commands and command surfaces;
+- hooks and lifecycle events;
+- capabilities and activation triggers;
+- required permissions;
+- configuration schema and defaults;
+- UI contributions, if any;
+- evidence types expected for QA/release;
+- compatibility with host Open Orchestra version;
+- security constraints and tenant/regulatory limitations;
+- ownership, support, and deprecation policy.
+
+## React/Vite UI Contributions
+
+- Use React + TypeScript conventions for UI plugin surfaces.
+- Use Vite for local dev/build when the host package supports it.
+- Separate presentation, state, API access, and domain logic.
+- Keep UI mobile-first, accessible, and covered with loading, empty, error,
+  success, and recovery states.
+- Add Playwright evidence for user-visible plugin UI flows.
+
+## QA Evidence
+
+Plugin QA should prove:
+
+- command exit code, stdout, stderr, and JSON contract;
+- flags/args validation and help output;
+- generated files or workflow events;
+- hook invocation, ordering, idempotency, and failure behavior;
+- install/link/package smoke;
+- compatibility with the declared host version;
+- Playwright screenshots/traces when UI is involved;
+- API side effects or external integration outcomes when the plugin triggers
+  them.
+
+## Security
+
+- Use `spawn`/`execFile` with args arrays for shell execution. Never interpolate
+  shell strings.
+- Validate file paths and reject traversal.
+- Validate URLs before network calls.
+- Do not hardcode secrets or write credentials to plugin manifests.
+- Define least-privilege plugin permissions and review them before release.
+- Treat third-party plugins and plugin-provided config as untrusted input.
+- Run secret scanning, dependency audit, static analysis, duplicate-code checks,
+  and package provenance checks before release.
+
+## Handoff Checklist
+
+- Plugin contract or manifest updated.
+- Command/hook behavior covered by tests.
+- Security-sensitive surfaces reviewed.
+- Evidence attached for CLI/API/UI behavior.
+- Package/install smoke completed or explicitly deferred.
+- Compatibility and release notes updated when user-facing behavior changes.

package/skills/oclif-plugin-development/manifest.json

@@ -0,0 +1,58 @@
+{
+  "id": "oclif-plugin-development",
+  "name": "Oclif Plugin Development",
+  "summary": "Build Open Orchestra plugins with oclif, TypeScript, command contracts, hooks, manifests, QA evidence, and secure package boundaries.",
+  "triggers": [
+    "oclif",
+    "plugin",
+    "plugins",
+    "cli plugin",
+    "command plugin",
+    "hook",
+    "hooks",
+    "manifest",
+    "plugin manifest",
+    "package exports",
+    "npm plugin",
+    "cli extension",
+    "react plugin ui",
+    "vite plugin ui",
+    "typescript plugin package"
+  ],
+  "roles": [
+    "developer",
+    "tech_lead",
+    "architect",
+    "qa",
+    "sdet",
+    "security",
+    "devops",
+    "platform_engineer",
+    "frontend_specialist"
+  ],
+  "capabilities": [
+    "plugin-development",
+    "cli-command-contracts",
+    "typescript-package-architecture",
+    "plugin-security",
+    "plugin-qa-evidence"
+  ],
+  "riskAreas": [
+    "maintainability",
+    "security",
+    "release",
+    "devops",
+    "integration",
+    "ux"
+  ],
+  "sourceGroups": [
+    "codebase",
+    "architecture",
+    "quality-security",
+    "devops-runtime",
+    "product-backlog"
+  ],
+  "evidence": ["command", "file", "report", "screenshot", "trace"],
+  "loadBudget": "normal",
+  "entry": "skills/oclif-plugin-development/SKILL.md"
+}