Big News: Socket raises $60M Series C at a $1B valuation to secure software supply chains for AI-driven development.Announcement →
Sign In

kyos-cli

Package Overview
Dependencies
Maintainers
1
Versions
29
Alerts
File Explorer

Advanced tools

License
Socket logo

Install Socket

Detect and block malicious and high-risk dependencies

Install

kyos-cli - npm Package Compare versions

Comparing version
1.0.4
 to
1.1.0
+5
-5
catalog/claude-base/claude/commands/architecture.md

@@ -1,2 +0,2 @@

# /kyos:architecture
# /architecture

@@ -67,5 +67,5 @@ > Pin down the technical shape of the repo so later planning is built on decisions instead of vibes.

```text
/kyos:architecture
/kyos:architecture choose a backend and deployment model for a small SaaS
/kyos:architecture split this repo into app, worker, and shared data responsibilities
/architecture
/architecture choose a backend and deployment model for a small SaaS
/architecture split this repo into app, worker, and shared data responsibilities
```

@@ -82,3 +82,3 @@

If new stack areas appear that the repo is not equipped for, point to `/kyos:hire`.
If new stack areas appear that the repo is not equipped for, point to `/hire`.

@@ -85,0 +85,0 @@ ## Where to save the result (so it can be committed)

+5
-5
catalog/claude-base/claude/commands/hire.md

@@ -1,2 +0,2 @@

# /kyos:hire
# /hire

@@ -55,5 +55,5 @@ > Stock the repo with the support it is missing before the next feature run trips over the same obvious gaps.

```text
/kyos:hire
/kyos:hire prepare this repo for oauth, redis, and github actions
/kyos:hire we are introducing background jobs and object storage next
/hire
/hire prepare this repo for oauth, redis, and github actions
/hire we are introducing background jobs and object storage next
```

@@ -73,2 +73,2 @@

Once the repo support layer is in better shape, continue with `/kyos:spec`, `/kyos:tech`, or `/kyos:implement`.
Once the repo support layer is in better shape, continue with `/spec`, `/tech`, or `/implement`.
+9
-9
catalog/claude-base/claude/commands/implement.md

@@ -1,2 +0,2 @@

# /kyos:implement
# /implement

@@ -46,5 +46,5 @@ > Move the feature forward in small verified slices, using the available specialists and repo context without losing the plan.

If the user provides a task file (typically the output of `/kyos:tasks`, e.g. `docs/execution/<spec-slug>/tasks.md`), treat it as the source of truth for progress.
If the user provides a task file (typically the output of `/tasks`, e.g. `docs/execution/<spec-slug>/tasks.md`), treat it as the source of truth for progress.
During `/kyos:implement`, Claude should:
During `/implement`, Claude should:

@@ -69,7 +69,7 @@ 1. Read the task file first and choose the next not-yet-done slice from it.

```text
/kyos:implement
/kyos:implement finish the current feature
/kyos:implement handle only the auth callback and session persistence slice
/kyos:implement use docs/execution/oauth-login/tasks.md and complete the next slice
/kyos:implement use docs/execution/oauth-login/tasks.md and run the next two independent slices in parallel
/implement
/implement finish the current feature
/implement handle only the auth callback and session persistence slice
/implement use docs/execution/oauth-login/tasks.md and complete the next slice
/implement use docs/execution/oauth-login/tasks.md and run the next two independent slices in parallel
```

@@ -90,2 +90,2 @@

Continue with [`/kyos:verify`](./verify.md) once the implementation slice is ready to be checked.
Continue with [`/verify`](./verify.md) once the implementation slice is ready to be checked.
+1
-1
catalog/claude-base/claude/commands/prevalidate.md

@@ -1,2 +0,2 @@

# /kyos:prevalidate
# /prevalidate

@@ -3,0 +3,0 @@ Run a quick, **read-only** safety + security prevalidation before doing any work in a repo (especially before running installers, tests, or scripts).

+3
-3
catalog/claude-base/claude/commands/README.md
# Kyos Commands (Managed)
This folder is the framework-managed source for the built-in `/kyos:*` workflow commands.
This folder is the framework-managed source for the built-in `/*` workflow commands.

@@ -12,7 +12,7 @@ In a bootstrapped repo:

`/kyos:spec -> /kyos:tech -> /kyos:tasks -> /kyos:implement -> /kyos:verify`
`/spec -> /tech -> /tasks -> /implement -> /verify`
If you’re new to the repo or about to run tooling/scripts, start with:
`/kyos:prevalidate`
`/prevalidate`
+14
-12
catalog/claude-base/claude/commands/spec.md

@@ -1,2 +0,2 @@

# /kyos:spec
# /spec

@@ -13,3 +13,3 @@ > Capture a feature in user language before discussing tables, endpoints, or framework details.

- user-facing requirements
- acceptance criteria
- user-observable outcomes
- clearly marked unanswered questions

@@ -25,2 +25,3 @@

- any nearby product or design notes
- user persona or role (inferred from context; only prompted if none is discernible)

@@ -31,6 +32,7 @@ ## Workflow

2. Gather what is already known.
3. Write the behavior from the user's point of view.
4. Push on ambiguity with concrete follow-up questions.
5. Mark unresolved parts plainly instead of inventing certainty.
6. Translate the result into testable acceptance criteria.
3. Identify the user role from context; prompt once only if no actor is discernible.
4. Write the behavior from the user's point of view, opening with a user story: *As a [role], I want [capability], so that [outcome].*
5. Push on ambiguity with concrete follow-up questions.
6. Mark unresolved parts plainly instead of inventing certainty.
7. Translate the result into user-observable outcomes.

@@ -46,5 +48,5 @@ ## Guardrails

```text
/kyos:spec
/kyos:spec add GitHub OAuth sign-in
/kyos:spec let users upload CSV files and preview validation errors before import
/spec
/spec add GitHub OAuth sign-in
/spec let users upload CSV files and preview validation errors before import
```

@@ -58,3 +60,3 @@

2. Ask for any missing user-facing detail.
3. Draft a concise but specific functional spec.
3. Draft a concise but specific functional spec, opening with a user story (*As a [role], I want [capability], so that [outcome].*). Infer the role from context; ask only if it cannot be determined.
4. Mark unresolved questions explicitly.

@@ -70,3 +72,3 @@ 5. Save the result into a local planning note.

Continue with [`/kyos:tech`](./tech.md) to turn the feature behavior into an engineering approach.
Continue with [`/tech`](./tech.md) to turn the feature behavior into an engineering approach.

@@ -96,2 +98,2 @@ ## Related section format

If the spec is purely a temporary working artifact, it can be deleted after `/kyos:verify`—but default to committing it while work is in flight.
If the spec is purely a temporary working artifact, it can be deleted after `/verify`—but default to committing it while work is in flight.
+7
-7
catalog/claude-base/claude/commands/tasks.md

@@ -1,2 +0,2 @@

# /kyos:tasks
# /tasks

@@ -44,5 +44,5 @@ > Break the current technical plan into concrete, ordered work slices that can be executed and checked without losing the bigger picture.

```text
/kyos:tasks
/kyos:tasks split the OAuth feature into execution slices
/kyos:tasks turn the CSV import tech plan into ordered implementation work
/tasks
/tasks split the OAuth feature into execution slices
/tasks turn the CSV import tech plan into ordered implementation work
```

@@ -90,3 +90,3 @@

```text
/kyos:implement @docs/execution/<spec-slug>/tasks.md
/implement @docs/execution/<spec-slug>/tasks.md
```

@@ -98,3 +98,3 @@

See [`/kyos:spec`](./spec.md#related-section-format) for the canonical **Related** section shape. Follow the same format: a `## Related` block at the bottom with markdown links to sibling artefacts that exist. When updating a sibling, insert only the missing link — do not duplicate.
See [`/spec`](./spec.md#related-section-format) for the canonical **Related** section shape. Follow the same format: a `## Related` block at the bottom with markdown links to sibling artefacts that exist. When updating a sibling, insert only the missing link — do not duplicate.

@@ -107,2 +107,2 @@ ## Where to save the result

Use the same `<spec-slug>` chosen in `/kyos:spec` (the folder created under `docs/execution/`).
Use the same `<spec-slug>` chosen in `/spec` (the folder created under `docs/execution/`).
+9
-9
catalog/claude-base/claude/commands/tech.md

@@ -1,2 +0,2 @@

# /kyos:tech
# /tech

@@ -13,3 +13,3 @@ > Turn feature behavior into a build plan: moving parts, interfaces, data flow, failure modes, and implementation boundaries.

- proposed interfaces, data structures, file boundaries, and operational considerations
- a note about new stack requirements that may need `/kyos:hire`
- a note about new stack requirements that may need `/hire`

@@ -40,5 +40,5 @@ ## Inputs

```text
/kyos:tech
/kyos:tech use GitHub OAuth with secure session cookies and Redis session storage
/kyos:tech plan CSV import with validation pipeline, staging table, and background processing
/tech
/tech use GitHub OAuth with secure session cookies and Redis session storage
/tech plan CSV import with validation pipeline, staging table, and background processing
```

@@ -54,3 +54,3 @@

4. Point out risk, migration, or operational concerns.
5. Suggest `/kyos:hire` if the design introduces uncovered capabilities.
5. Suggest `/hire` if the design introduces uncovered capabilities.
6. Include a **Related** section in tech.md with a link to `spec.md` (required) and to `tasks.md` if it already exists.

@@ -65,7 +65,7 @@ 7. After saving tech.md, open `spec.md` in the same execution folder and add or update a link to `tech.md` in its **Related** section (create the section if absent).

Continue with [`/kyos:tasks`](./tasks.md) to break the plan into ordered execution slices.
Continue with [`/tasks`](./tasks.md) to break the plan into ordered execution slices.
## Related section format
See [`/kyos:spec`](./spec.md#related-section-format) for the canonical **Related** section shape. Follow the same format: a `## Related` block at the bottom with markdown links to sibling artefacts that exist. When updating a sibling, insert only the missing link — do not duplicate.
See [`/spec`](./spec.md#related-section-format) for the canonical **Related** section shape. Follow the same format: a `## Related` block at the bottom with markdown links to sibling artefacts that exist. When updating a sibling, insert only the missing link — do not duplicate.

@@ -78,2 +78,2 @@ ## Where to save the result

Use the same `<spec-slug>` chosen in `/kyos:spec` (the folder created under `docs/execution/`).
Use the same `<spec-slug>` chosen in `/spec` (the folder created under `docs/execution/`).
+6
-6
catalog/claude-base/claude/commands/verify.md

@@ -1,2 +0,2 @@

# /kyos:verify
# /verify

@@ -44,5 +44,5 @@ > Check that implemented work matches the spec, still fits the plan, and leaves the repo in a trustworthy state.

```text
/kyos:verify
/kyos:verify check the OAuth implementation against the spec and tech plan
/kyos:verify review the completed CSV import slices for regressions and missing tests
/verify
/verify check the OAuth implementation against the spec and tech plan
/verify review the completed CSV import slices for regressions and missing tests
```

@@ -61,3 +61,3 @@

If verification fails, go back to [`/kyos:implement`](./implement.md).
If verification fails, go back to [`/implement`](./implement.md).

@@ -69,3 +69,3 @@ If verification passes:

- keep it only if the team wants a durable product or decision record
- then start the next feature cycle at [`/kyos:spec`](./spec.md)
- then start the next feature cycle at [`/spec`](./spec.md)
+1
-1
package.json
{
"name": "kyos-cli",
"version": "1.0.4",
"version": "1.1.0",
"description": "Bootstrap and safely evolve a shared Claude Code repo structure.",

@@ -5,0 +5,0 @@ "author": "Eugene",

+29
-0
src/core/config.js

@@ -53,2 +53,30 @@ const path = require("path");

const BASE_AGENT_HOOK = {
matcher: "Agent",
hooks: [
{
type: "command",
command:
"echo '{\"hookSpecificOutput\":{\"hookEventName\":\"PostToolUse\",\"additionalContext\":\"PROCESS RULE: A subagent just completed. If the user now reports a bug or issue with its output, re-spawn the SAME agent type via the Agent tool — do NOT call Edit or Write inline. Only fix inline if it is a single-line typo or wiring mistake faster to correct than to brief an agent (per .claude/rules/process.md).\"}}' ",
},
],
};
function ensureBaseHooks(cwd) {
const existing = readJsonIfExists(path.resolve(cwd, MCP_CONFIG_FILE)) || {};
const postToolUse = (existing.hooks && existing.hooks.PostToolUse) || [];
if (postToolUse.some((entry) => entry.matcher === "Agent")) {
return false;
}
const merged = {
...existing,
hooks: {
...(existing.hooks || {}),
PostToolUse: [...postToolUse, BASE_AGENT_HOOK],
},
};
writeRepoTextFile(cwd, MCP_CONFIG_FILE, stableStringify(merged));
return true;
}
function addInstalledCapability(config, type, name) {

@@ -69,2 +97,3 @@ const bucket = config.installed[type];

addInstalledCapability,
ensureBaseHooks,
getDefaultConfig,

@@ -71,0 +100,0 @@ loadMcpConfig,

+3
-0
src/core/workflows.js

@@ -16,2 +16,3 @@ const fs = require("fs");

addInstalledCapability,
ensureBaseHooks,
loadMcpConfig,

@@ -238,2 +239,3 @@ loadUserConfig,

applyLocalClaudeSeed({ cwd, plan: localSeedPlan });
ensureBaseHooks(cwd);
ensureGitignoreHasKyos({ cwd });

@@ -811,2 +813,3 @@ }

applyLocalClaudeSeed({ cwd, plan: localSeedPlan });
ensureBaseHooks(cwd);
const installedLines = replayInstalledCapabilities({ cwd, config });

@@ -813,0 +816,0 @@ ensureGitignoreHasKyos({ cwd });