@skillshub-labs/cli 0.1.17 → 0.1.19

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 (28) hide show
  1. package/README.md +28 -12
  2. package/bin/skills-hub +193 -15
  3. package/data/official-presets/catalog.json +436 -0
  4. package/data/official-presets/policies/policy-azure-cloud.md +18 -0
  5. package/data/official-presets/policies/policy-cloudflare-edge.md +18 -0
  6. package/data/official-presets/policies/policy-fastapi-py.md +31 -0
  7. package/data/official-presets/policies/policy-fullstack-web.md +24 -0
  8. package/data/official-presets/policies/policy-go-service.md +31 -0
  9. package/data/official-presets/policies/policy-hf-ml.md +18 -0
  10. package/data/official-presets/policies/policy-langchain-apps.md +18 -0
  11. package/data/official-presets/policies/policy-literature-review.md +18 -0
  12. package/data/official-presets/policies/policy-monorepo-turbo.md +31 -0
  13. package/data/official-presets/policies/policy-nextjs-ts-strict.md +31 -0
  14. package/data/official-presets/policies/policy-node-api-ts.md +31 -0
  15. package/data/official-presets/policies/policy-python-api.md +18 -0
  16. package/data/official-presets/policies/policy-release-ci.md +18 -0
  17. package/data/official-presets/policies/policy-release-maintainer.md +31 -0
  18. package/data/official-presets/policies/policy-scientific-discovery.md +18 -0
  19. package/data/official-presets/policies/policy-scientific-python.md +31 -0
  20. package/data/official-presets/policies/policy-security-audit.md +18 -0
  21. package/data/official-presets/policies/policy-web-frontend.md +18 -0
  22. package/lib/core/kit-core.d.ts +14 -3
  23. package/lib/core/kit-core.mjs +327 -20
  24. package/lib/core/kit-types.ts +128 -3
  25. package/lib/services/kit-loadout-import.mjs +599 -0
  26. package/lib/services/kit-service.d.ts +90 -2
  27. package/lib/services/kit-service.mjs +665 -38
  28. package/package.json +9 -1
@@ -0,0 +1,31 @@
1
+ # AGENTS.md
2
+
3
+ ## Project Overview
4
+
5
+ - This project uses Next.js, React, and TypeScript.
6
+ - Favor small, testable changes that preserve existing UI and data flow patterns.
7
+
8
+ ## Repository Layout
9
+
10
+ - Keep route, UI, and data access concerns separated.
11
+ - Prefer existing component and app-router conventions over introducing parallel structures.
12
+
13
+ ## Dev Commands
14
+
15
+ - Run the existing lint, typecheck, and test commands before finalizing changes.
16
+ - If a UI change affects rendering behavior, validate the relevant app or page flow manually as well.
17
+
18
+ ## Testing Instructions
19
+
20
+ - Cover changed behavior with deterministic tests when practical.
21
+ - If a change touches UI state or routing, check loading, empty, and error states.
22
+
23
+ ## Architecture Boundaries
24
+
25
+ - Keep business logic out of UI components when possible.
26
+ - Avoid introducing new abstractions unless the same pattern is clearly reused.
27
+
28
+ ## PR / Change Rules
29
+
30
+ - Explain user-visible behavior changes directly.
31
+ - Call out risky UI, routing, or state changes before merge.
@@ -0,0 +1,31 @@
1
+ # AGENTS.md
2
+
3
+ ## Project Overview
4
+
5
+ - This project uses Node.js and TypeScript for API or backend service development.
6
+ - Prefer explicit contracts, narrow changes, and clear error handling.
7
+
8
+ ## Repository Layout
9
+
10
+ - Keep transport, validation, domain logic, and persistence responsibilities separated.
11
+ - Reuse existing service and module boundaries instead of bypassing them.
12
+
13
+ ## Dev Commands
14
+
15
+ - Run lint, typecheck, and tests before finalizing changes.
16
+ - If schema or contract files are part of the repo, validate them alongside code changes.
17
+
18
+ ## Testing Instructions
19
+
20
+ - Add regression coverage for behavior changes or bug fixes.
21
+ - Exercise failure paths when input validation, auth, config, or persistence code changes.
22
+
23
+ ## Architecture Boundaries
24
+
25
+ - Do not mix request parsing, domain logic, and storage concerns in one handler.
26
+ - Keep migrations, config changes, and breaking contract changes explicit.
27
+
28
+ ## PR / Change Rules
29
+
30
+ - Summarize API-facing behavior changes clearly.
31
+ - Highlight contract risk, migration risk, and rollback considerations when relevant.
@@ -0,0 +1,18 @@
1
+ # AGENTS.md
2
+
3
+ ## Project Overview
4
+
5
+ - This project builds Python services or APIs.
6
+ - Prefer explicit validation, narrow interfaces, and predictable operational behavior.
7
+
8
+ ## Engineering Rules
9
+
10
+ - Keep route handlers thin.
11
+ - Push reusable logic into services or domain modules.
12
+ - Use typed models and validate external input at the edge.
13
+
14
+ ## Quality Bar
15
+
16
+ - Add regression coverage for changed behavior.
17
+ - Surface config, auth, and persistence risk explicitly.
18
+ - Treat migrations and public contract changes as high-signal changes.
@@ -0,0 +1,18 @@
1
+ # AGENTS.md
2
+
3
+ ## Project Overview
4
+
5
+ - This project supports release engineering, CI maintenance, and change-management workflows.
6
+ - Prefer correctness, traceability, and safe automation over speed.
7
+
8
+ ## Engineering Rules
9
+
10
+ - Keep release, documentation, and automation changes aligned.
11
+ - Treat flaky CI and broken checks as root-cause problems, not cosmetic issues.
12
+ - Preserve auditability for release notes, version bumps, and workflow edits.
13
+
14
+ ## Quality Bar
15
+
16
+ - State what was verified locally and what still depends on CI.
17
+ - Call out packaging, deployment, or rollback risk explicitly.
18
+ - Avoid silent workflow changes without explaining impact.
@@ -0,0 +1,31 @@
1
+ # AGENTS.md
2
+
3
+ ## Project Overview
4
+
5
+ - This workflow supports releases, change summaries, and maintainer tasks.
6
+ - Prefer correctness, traceability, and conservative changes over speed.
7
+
8
+ ## Repository Layout
9
+
10
+ - Keep release metadata, automation, and user-facing documentation aligned with the code change set.
11
+ - Reuse existing release and changelog conventions.
12
+
13
+ ## Dev Commands
14
+
15
+ - Run the project checks needed to confirm release readiness.
16
+ - Revalidate release-related config or automation when workflows change.
17
+
18
+ ## Testing Instructions
19
+
20
+ - Confirm the relevant build, packaging, or release validation path still works.
21
+ - Document any checks that could not be run locally.
22
+
23
+ ## Architecture Boundaries
24
+
25
+ - Treat release automation, packaging, and changelog generation as separate concerns.
26
+ - Keep manual release notes consistent with automated outputs.
27
+
28
+ ## PR / Change Rules
29
+
30
+ - Summarize release impact, packaging impact, and compatibility notes clearly.
31
+ - Highlight manual follow-up tasks when automation does not cover them.
@@ -0,0 +1,18 @@
1
+ # AGENTS.md
2
+
3
+ ## Project Overview
4
+
5
+ - This project supports scientific discovery, bioinformatics, or computational chemistry workflows.
6
+ - Prefer reproducible analysis, explicit data provenance, and conservative interpretation.
7
+
8
+ ## Engineering Rules
9
+
10
+ - Separate data access, processing, analysis, and reporting.
11
+ - Keep domain assumptions visible near the code or report that depends on them.
12
+ - Treat external scientific databases as versioned inputs.
13
+
14
+ ## Quality Bar
15
+
16
+ - Document changed datasets, parameters, or biological assumptions.
17
+ - Note reproducibility gaps when full reruns are too expensive.
18
+ - Avoid claiming experimental validity when only computational evidence exists.
@@ -0,0 +1,31 @@
1
+ # AGENTS.md
2
+
3
+ ## Project Overview
4
+
5
+ - This project supports scientific Python, literature review, or reproducible analysis workflows.
6
+ - Prefer traceable claims, reproducible steps, and explicit assumptions.
7
+
8
+ ## Repository Layout
9
+
10
+ - Keep source data, derived outputs, and narrative artifacts clearly separated.
11
+ - Avoid mixing exploratory notebooks, reusable code, and final reporting outputs without a clear reason.
12
+
13
+ ## Dev Commands
14
+
15
+ - Run the relevant checks or scripts needed to reproduce changed outputs.
16
+ - If notebooks or reports are touched, verify the dependent data and execution steps still line up.
17
+
18
+ ## Testing Instructions
19
+
20
+ - Prefer deterministic validation for transformed data and reusable analysis code.
21
+ - Document what was not re-run when full reproduction is too expensive.
22
+
23
+ ## Architecture Boundaries
24
+
25
+ - Keep data acquisition, processing, analysis, and reporting concerns explicit.
26
+ - Record assumptions around datasets, citations, and external scientific sources.
27
+
28
+ ## PR / Change Rules
29
+
30
+ - Explain how conclusions, figures, or cited evidence changed.
31
+ - Call out reproducibility gaps, missing inputs, or unverified claims directly.
@@ -0,0 +1,18 @@
1
+ # AGENTS.md
2
+
3
+ ## Project Overview
4
+
5
+ - This project focuses on security review, vulnerability detection, or secure design analysis.
6
+ - Prefer evidence-backed findings, clear impact statements, and conservative recommendations.
7
+
8
+ ## Audit Rules
9
+
10
+ - Prioritize exploitable issues, unsafe defaults, and supply-chain risk.
11
+ - Keep findings tied to concrete code paths, trust boundaries, or assets.
12
+ - Distinguish confirmed issues from hypotheses or follow-up questions.
13
+
14
+ ## Quality Bar
15
+
16
+ - Include reproduction guidance when practical.
17
+ - State severity, exploitability, and mitigation direction clearly.
18
+ - Avoid speculative findings without code or configuration evidence.
@@ -0,0 +1,18 @@
1
+ # AGENTS.md
2
+
3
+ ## Project Overview
4
+
5
+ - This project focuses on frontend delivery with React or Next.js.
6
+ - Optimize for UI clarity, performance, accessibility, and maintainable component boundaries.
7
+
8
+ ## Engineering Rules
9
+
10
+ - Use TypeScript strictly and avoid `any`.
11
+ - Prefer server rendering and code splitting where available.
12
+ - Reuse existing component patterns before inventing new ones.
13
+
14
+ ## Quality Bar
15
+
16
+ - Check loading, empty, and error states.
17
+ - Preserve keyboard accessibility and semantic HTML.
18
+ - Note performance-sensitive changes such as hydration, bundle weight, and image handling.
@@ -1,4 +1,10 @@
1
- import type { KitLoadoutRecord, KitPolicyRecord, KitRecord } from './kit-types'
1
+ import type {
2
+ ManagedKitSource,
3
+ KitLoadoutImportSource,
4
+ KitLoadoutRecord,
5
+ KitPolicyRecord,
6
+ KitRecord,
7
+ } from './kit-types'
2
8
 
3
9
  export function ensureDb(): unknown
4
10
  export function getDbPath(): string
@@ -24,12 +30,14 @@ export function addKitLoadout(input: {
24
30
  name: string
25
31
  description?: string
26
32
  items: Array<{ skillPath: string; mode?: 'copy' | 'link'; sortOrder?: number }>
33
+ importSource?: KitLoadoutImportSource
27
34
  }): KitLoadoutRecord
28
35
  export function updateKitLoadout(input: {
29
36
  id: string
30
37
  name?: string
31
38
  description?: string
32
39
  items?: Array<{ skillPath: string; mode?: 'copy' | 'link'; sortOrder?: number }>
40
+ importSource?: KitLoadoutImportSource
33
41
  }): KitLoadoutRecord
34
42
  export function deleteKitLoadout(id: string): boolean
35
43
 
@@ -38,8 +46,9 @@ export function getKitById(id: string): KitRecord | null
38
46
  export function addKit(input: {
39
47
  name: string
40
48
  description?: string
41
- policyId: string
42
- loadoutId: string
49
+ policyId?: string
50
+ loadoutId?: string
51
+ managedSource?: ManagedKitSource
43
52
  }): KitRecord
44
53
  export function updateKit(input: {
45
54
  id: string
@@ -47,8 +56,10 @@ export function updateKit(input: {
47
56
  description?: string
48
57
  policyId?: string
49
58
  loadoutId?: string
59
+ managedSource?: ManagedKitSource | null
50
60
  }): KitRecord
51
61
  export function deleteKit(id: string): boolean
62
+ export function restoreManagedKitBaseline(id: string): KitRecord
52
63
  export function markKitApplied(input: {
53
64
  id: string
54
65
  projectPath: string