akm-cli 0.9.0-beta.38 → 0.9.0-beta.39
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.
- package/CHANGELOG.md +13 -0
- package/dist/assets/stash-skeleton/facts/conventions/assets/agent.md +22 -0
- package/dist/assets/stash-skeleton/facts/conventions/assets/command.md +22 -0
- package/dist/assets/stash-skeleton/facts/conventions/assets/fact.md +24 -0
- package/dist/assets/stash-skeleton/facts/conventions/assets/knowledge.md +22 -0
- package/dist/assets/stash-skeleton/facts/conventions/assets/lesson.md +25 -0
- package/dist/assets/stash-skeleton/facts/conventions/assets/memory.md +21 -0
- package/dist/assets/stash-skeleton/facts/conventions/assets/script.md +21 -0
- package/dist/assets/stash-skeleton/facts/conventions/assets/skill.md +23 -0
- package/dist/assets/stash-skeleton/facts/conventions/assets/workflow.md +22 -0
- package/dist/commands/sources/init.js +7 -4
- package/dist/commands/sources/stash-skeleton.js +23 -8
- package/package.json +1 -1
package/CHANGELOG.md
CHANGED
|
@@ -25,6 +25,19 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
|
|
|
25
25
|
source of validator-rejecting rules). The general convention/meta resolver now
|
|
26
26
|
excludes `facts/conventions/assets/*` so per-type guidance never leaks
|
|
27
27
|
un-type-scoped into other authoring flows. (#646)
|
|
28
|
+
- **`akm init` now seeds default per-type SOFT convention templates.** Starter
|
|
29
|
+
`facts/conventions/assets/<type>.md` templates ship in the stash skeleton for
|
|
30
|
+
the authored types (`lesson, skill, command, agent, knowledge, memory,
|
|
31
|
+
workflow, script, fact`; `wiki`/`env`/`secret` excluded) so a stash owner has
|
|
32
|
+
an editable starting point. Each expands the matching built-in `TYPE_HINTS`
|
|
33
|
+
one-liner into soft starter guidance, carries `category: convention`
|
|
34
|
+
frontmatter, and states in-body that it is advice, not enforced — it carries
|
|
35
|
+
**no** validator-rejecting rules, so editing or deleting one cannot weaken the
|
|
36
|
+
gate (#645). The stash-skeleton copy is now recursive (preserving nested
|
|
37
|
+
subpaths), and `akm init` seeds **unconditionally** rather than only on first
|
|
38
|
+
create: re-running it on an existing stash backfills any missing skeleton,
|
|
39
|
+
convention, or `.meta/index.md` files. Seeding stays absent-only and never
|
|
40
|
+
overwrites a user-edited file. (#646)
|
|
28
41
|
|
|
29
42
|
## [0.9.0-beta.36] — 2026-06-22
|
|
30
43
|
|
|
@@ -0,0 +1,22 @@
|
|
|
1
|
+
---
|
|
2
|
+
category: convention
|
|
3
|
+
description: Starter SOFT authoring conventions for agent assets — edit to taste.
|
|
4
|
+
when_to_use: Surfaced to authoring agents when they write or revise an agent asset.
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
<!--
|
|
8
|
+
SOFT guidance only — advice, not a contract. Nothing here is enforced by the
|
|
9
|
+
proposal gate; the validator-rejecting HARD rules live in
|
|
10
|
+
src/core/authoring-rules.ts (#645) and remain the sole enforced source. Editing
|
|
11
|
+
or deleting this file cannot weaken the gate.
|
|
12
|
+
-->
|
|
13
|
+
|
|
14
|
+
# Agent authoring conventions
|
|
15
|
+
|
|
16
|
+
An agent is markdown whose frontmatter describes a reusable role.
|
|
17
|
+
|
|
18
|
+
- Frontmatter typically carries `name`, `description`, and optionally `tools` and
|
|
19
|
+
`model`. Write the `description` so a dispatcher knows exactly when to delegate.
|
|
20
|
+
- The body is the system prompt: establish the role, its scope, and its boundaries.
|
|
21
|
+
- Be explicit about what the agent should and should not do, and what it returns.
|
|
22
|
+
- Prefer a focused single-responsibility persona over a broad do-everything agent.
|
|
@@ -0,0 +1,22 @@
|
|
|
1
|
+
---
|
|
2
|
+
category: convention
|
|
3
|
+
description: Starter SOFT authoring conventions for command assets — edit to taste.
|
|
4
|
+
when_to_use: Surfaced to authoring agents when they write or revise a command asset.
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
<!--
|
|
8
|
+
SOFT guidance only — advice, not a contract. Nothing here is enforced by the
|
|
9
|
+
proposal gate; the validator-rejecting HARD rules live in
|
|
10
|
+
src/core/authoring-rules.ts (#645) and remain the sole enforced source. Editing
|
|
11
|
+
or deleting this file cannot weaken the gate.
|
|
12
|
+
-->
|
|
13
|
+
|
|
14
|
+
# Command authoring conventions
|
|
15
|
+
|
|
16
|
+
A command is a markdown prompt template the user invokes by name.
|
|
17
|
+
|
|
18
|
+
- Optional frontmatter carries `name` and `description`; the body *is* the prompt.
|
|
19
|
+
- Write the body as the instruction you want the model to follow when invoked.
|
|
20
|
+
- State the task, the expected inputs, and the shape of the desired output up front.
|
|
21
|
+
- Keep it tight and unambiguous — a command is run repeatedly, so vagueness compounds.
|
|
22
|
+
- Use clear placeholders for any arguments the caller will supply.
|
|
@@ -0,0 +1,24 @@
|
|
|
1
|
+
---
|
|
2
|
+
category: convention
|
|
3
|
+
description: Starter SOFT authoring conventions for fact assets — edit to taste.
|
|
4
|
+
when_to_use: Surfaced to authoring agents when they write or revise a fact asset.
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
<!--
|
|
8
|
+
SOFT guidance only — advice, not a contract. Nothing here is enforced by the
|
|
9
|
+
proposal gate; the validator-rejecting HARD rules live in
|
|
10
|
+
src/core/authoring-rules.ts (#645) and remain the sole enforced source. Editing
|
|
11
|
+
or deleting this file cannot weaken the gate.
|
|
12
|
+
-->
|
|
13
|
+
|
|
14
|
+
# Fact authoring conventions
|
|
15
|
+
|
|
16
|
+
A fact is durable stash-level context — personal, team, or project details,
|
|
17
|
+
coding conventions, or stash-meta.
|
|
18
|
+
|
|
19
|
+
- Frontmatter should include a `description` and a `category`
|
|
20
|
+
(personal | team | project | convention | meta).
|
|
21
|
+
- Set `pinned: true` only for the small always-injected core; most facts stay unpinned.
|
|
22
|
+
- Keep each fact short, high-signal, and self-contained — it is durable context,
|
|
23
|
+
not an episodic note.
|
|
24
|
+
- Write it as a standing declaration that stays true across sessions.
|
|
@@ -0,0 +1,22 @@
|
|
|
1
|
+
---
|
|
2
|
+
category: convention
|
|
3
|
+
description: Starter SOFT authoring conventions for knowledge assets — edit to taste.
|
|
4
|
+
when_to_use: Surfaced to authoring agents when they write or revise a knowledge asset.
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
<!--
|
|
8
|
+
SOFT guidance only — advice, not a contract. Nothing here is enforced by the
|
|
9
|
+
proposal gate; the validator-rejecting HARD rules live in
|
|
10
|
+
src/core/authoring-rules.ts (#645) and remain the sole enforced source. Editing
|
|
11
|
+
or deleting this file cannot weaken the gate.
|
|
12
|
+
-->
|
|
13
|
+
|
|
14
|
+
# Knowledge authoring conventions
|
|
15
|
+
|
|
16
|
+
A knowledge asset is a reference document meant to be read on demand.
|
|
17
|
+
|
|
18
|
+
- Open with a top-level `# Title` that names the subject plainly.
|
|
19
|
+
- Organise into concise, well-headed sections so a reader can jump to what they need.
|
|
20
|
+
- Favour accuracy and clarity over completeness; link or cross-reference rather than
|
|
21
|
+
duplicating other assets.
|
|
22
|
+
- Voice: explanatory and neutral, written to be re-read months later.
|
|
@@ -0,0 +1,25 @@
|
|
|
1
|
+
---
|
|
2
|
+
category: convention
|
|
3
|
+
description: Starter SOFT authoring conventions for lesson assets — edit to taste.
|
|
4
|
+
when_to_use: Surfaced to authoring agents when they write or revise a lesson asset.
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
<!--
|
|
8
|
+
SOFT guidance only — advice, not a contract. Nothing here is enforced by the
|
|
9
|
+
proposal gate; the validator-rejecting HARD rules live in
|
|
10
|
+
src/core/authoring-rules.ts (#645) and remain the sole enforced source. Editing
|
|
11
|
+
or deleting this file cannot weaken the gate. Tune the guidance below to match
|
|
12
|
+
how your stash likes lessons written.
|
|
13
|
+
-->
|
|
14
|
+
|
|
15
|
+
# Lesson authoring conventions
|
|
16
|
+
|
|
17
|
+
A lesson captures durable, hard-won judgement about *when* to reach for something
|
|
18
|
+
and *what goes wrong without it* — it is not a restatement of the source asset.
|
|
19
|
+
|
|
20
|
+
- Lead with the trigger: when should a reader reach for this lesson?
|
|
21
|
+
- Then the failure mode: what breaks, or what gets missed, without it?
|
|
22
|
+
- Then the insight: what did real use reveal that the asset itself does not say?
|
|
23
|
+
- Keep it to one to three short, concrete paragraphs. Prefer specifics over
|
|
24
|
+
general advice; a lesson earns its keep by being actionable in a real moment.
|
|
25
|
+
- Voice: direct and practical, written for a future agent mid-task.
|
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
---
|
|
2
|
+
category: convention
|
|
3
|
+
description: Starter SOFT authoring conventions for memory assets — edit to taste.
|
|
4
|
+
when_to_use: Surfaced to authoring agents when they write or revise a memory asset.
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
<!--
|
|
8
|
+
SOFT guidance only — advice, not a contract. Nothing here is enforced by the
|
|
9
|
+
proposal gate; the validator-rejecting HARD rules live in
|
|
10
|
+
src/core/authoring-rules.ts (#645) and remain the sole enforced source. Editing
|
|
11
|
+
or deleting this file cannot weaken the gate.
|
|
12
|
+
-->
|
|
13
|
+
|
|
14
|
+
# Memory authoring conventions
|
|
15
|
+
|
|
16
|
+
A memory is a short factual note the user wants persisted across sessions.
|
|
17
|
+
|
|
18
|
+
- Frontmatter usually includes a `description` that states the fact in one line.
|
|
19
|
+
- Keep the body brief and self-contained — one durable fact or decision per memory.
|
|
20
|
+
- Write it so it still reads clearly with no surrounding conversation for context.
|
|
21
|
+
- Prefer durable, reusable facts over episodic play-by-play of a single session.
|
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
---
|
|
2
|
+
category: convention
|
|
3
|
+
description: Starter SOFT authoring conventions for script assets — edit to taste.
|
|
4
|
+
when_to_use: Surfaced to authoring agents when they write or revise a script asset.
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
<!--
|
|
8
|
+
SOFT guidance only — advice, not a contract. Nothing here is enforced by the
|
|
9
|
+
proposal gate; the validator-rejecting HARD rules live in
|
|
10
|
+
src/core/authoring-rules.ts (#645) and remain the sole enforced source. Editing
|
|
11
|
+
or deleting this file cannot weaken the gate.
|
|
12
|
+
-->
|
|
13
|
+
|
|
14
|
+
# Script authoring conventions
|
|
15
|
+
|
|
16
|
+
A script is an executable text file stored as-is and run on demand.
|
|
17
|
+
|
|
18
|
+
- Start with a shebang appropriate to the interpreter (e.g. `#!/usr/bin/env bash`).
|
|
19
|
+
- Follow it with a short usage comment: what the script does and how to invoke it.
|
|
20
|
+
- Keep the script focused on one job; fail loudly and early on bad input.
|
|
21
|
+
- Prefer readable, well-commented logic over cleverness — these get re-run by others.
|
|
@@ -0,0 +1,23 @@
|
|
|
1
|
+
---
|
|
2
|
+
category: convention
|
|
3
|
+
description: Starter SOFT authoring conventions for skill assets — edit to taste.
|
|
4
|
+
when_to_use: Surfaced to authoring agents when they write or revise a skill asset.
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
<!--
|
|
8
|
+
SOFT guidance only — advice, not a contract. Nothing here is enforced by the
|
|
9
|
+
proposal gate; the validator-rejecting HARD rules live in
|
|
10
|
+
src/core/authoring-rules.ts (#645) and remain the sole enforced source. Editing
|
|
11
|
+
or deleting this file cannot weaken the gate.
|
|
12
|
+
-->
|
|
13
|
+
|
|
14
|
+
# Skill authoring conventions
|
|
15
|
+
|
|
16
|
+
A skill is a reusable, self-contained capability stored as `skills/<name>/SKILL.md`.
|
|
17
|
+
|
|
18
|
+
- Frontmatter usually carries `name`, `description`, and `when_to_use`. Write the
|
|
19
|
+
`description` so a dispatcher can decide *from it alone* whether to load the skill.
|
|
20
|
+
- Open the body with the goal in an imperative voice ("Generate…", "Review…").
|
|
21
|
+
- Structure as: purpose, when to use, then the procedure or guidance as ordered
|
|
22
|
+
steps or short sections. Favour scannable headings over long prose.
|
|
23
|
+
- Keep it focused on one capability; split unrelated concerns into separate skills.
|
|
@@ -0,0 +1,22 @@
|
|
|
1
|
+
---
|
|
2
|
+
category: convention
|
|
3
|
+
description: Starter SOFT authoring conventions for workflow assets — edit to taste.
|
|
4
|
+
when_to_use: Surfaced to authoring agents when they write or revise a workflow asset.
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
<!--
|
|
8
|
+
SOFT guidance only — advice, not a contract. Nothing here is enforced by the
|
|
9
|
+
proposal gate; the validator-rejecting HARD rules live in
|
|
10
|
+
src/core/authoring-rules.ts (#645) and remain the sole enforced source. Editing
|
|
11
|
+
or deleting this file cannot weaken the gate.
|
|
12
|
+
-->
|
|
13
|
+
|
|
14
|
+
# Workflow authoring conventions
|
|
15
|
+
|
|
16
|
+
A workflow describes a multi-step process an agent or human follows in order.
|
|
17
|
+
|
|
18
|
+
- Open with a top-level `# <Title>` naming the workflow's outcome.
|
|
19
|
+
- Lay out the steps as ordered `## Step N` sections, each with a clear action.
|
|
20
|
+
- For each step, state what to do, what it depends on, and how to know it is done.
|
|
21
|
+
- Keep steps atomic and resumable — a reader should be able to stop and pick up midway.
|
|
22
|
+
- Note any branch points or preconditions explicitly rather than burying them in prose.
|
|
@@ -75,10 +75,13 @@ export async function akmInit(options) {
|
|
|
75
75
|
}
|
|
76
76
|
// Ensure the default stash is a local git repo (no remote required)
|
|
77
77
|
ensureGitRepo(stashDir);
|
|
78
|
-
|
|
79
|
-
|
|
80
|
-
|
|
81
|
-
|
|
78
|
+
// Run seeding UNCONDITIONALLY (not just when the stash was newly created) so
|
|
79
|
+
// re-running `akm init` on an existing stash backfills any missing skeleton
|
|
80
|
+
// files — the README, the per-type SOFT convention templates under
|
|
81
|
+
// facts/conventions/assets/, and the `.meta/index.md` orientation doc. Both
|
|
82
|
+
// helpers are absent-only: they never overwrite a file a user has edited.
|
|
83
|
+
copyStashSkeleton(stashDir);
|
|
84
|
+
scaffoldStashMeta(stashDir);
|
|
82
85
|
// Persist stashDir in config.json
|
|
83
86
|
const configPath = getConfigPath();
|
|
84
87
|
const existing = loadUserConfig();
|
|
@@ -6,27 +6,42 @@ import path from "node:path";
|
|
|
6
6
|
import { getDirname } from "../../runtime.js";
|
|
7
7
|
const SKELETON_DIR = path.join(getDirname(import.meta.url), "../../assets/stash-skeleton");
|
|
8
8
|
/**
|
|
9
|
-
* Copy the default stash skeleton into a
|
|
9
|
+
* Copy the default stash skeleton into a stash directory.
|
|
10
10
|
*
|
|
11
|
-
*
|
|
12
|
-
*
|
|
13
|
-
*
|
|
14
|
-
*
|
|
11
|
+
* The skeleton tree under src/assets/stash-skeleton/ is mirrored **recursively**
|
|
12
|
+
* into the stash root, preserving relative subpaths (e.g.
|
|
13
|
+
* `facts/conventions/assets/skill.md` lands at the matching stash subpath).
|
|
14
|
+
* Each file is written only if the destination does not already exist — existing
|
|
15
|
+
* (possibly user-edited) files are never overwritten. Intermediate directories
|
|
16
|
+
* are created as needed.
|
|
17
|
+
*
|
|
18
|
+
* Idempotent and absent-only: running it again on an existing stash backfills
|
|
19
|
+
* any skeleton files that are missing without clobbering present ones. Non-fatal:
|
|
20
|
+
* if the skeleton directory is missing or a copy fails the caller continues.
|
|
15
21
|
*/
|
|
16
22
|
export function copyStashSkeleton(stashDir) {
|
|
23
|
+
copySkeletonDir(SKELETON_DIR, stashDir);
|
|
24
|
+
}
|
|
25
|
+
/** Recursively mirror `srcDir` into `destDir`, writing files only when absent. */
|
|
26
|
+
function copySkeletonDir(srcDir, destDir) {
|
|
17
27
|
let entries;
|
|
18
28
|
try {
|
|
19
|
-
entries = fs.readdirSync(
|
|
29
|
+
entries = fs.readdirSync(srcDir, { withFileTypes: true });
|
|
20
30
|
}
|
|
21
31
|
catch {
|
|
22
32
|
return;
|
|
23
33
|
}
|
|
24
34
|
for (const entry of entries) {
|
|
25
|
-
const src = path.join(
|
|
26
|
-
const dest = path.join(
|
|
35
|
+
const src = path.join(srcDir, entry.name);
|
|
36
|
+
const dest = path.join(destDir, entry.name);
|
|
37
|
+
if (entry.isDirectory()) {
|
|
38
|
+
copySkeletonDir(src, dest);
|
|
39
|
+
continue;
|
|
40
|
+
}
|
|
27
41
|
if (fs.existsSync(dest))
|
|
28
42
|
continue;
|
|
29
43
|
try {
|
|
44
|
+
fs.mkdirSync(path.dirname(dest), { recursive: true });
|
|
30
45
|
fs.copyFileSync(src, dest);
|
|
31
46
|
}
|
|
32
47
|
catch {
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "akm-cli",
|
|
3
|
-
"version": "0.9.0-beta.
|
|
3
|
+
"version": "0.9.0-beta.39",
|
|
4
4
|
"type": "module",
|
|
5
5
|
"description": "akm (Agent Knowledge Management) — A package manager for AI agent skills, commands, tools, and knowledge. Works with Claude Code, OpenCode, Cursor, and any AI coding assistant.",
|
|
6
6
|
"keywords": [
|