@compilr-dev/sdk 0.25.1 → 0.27.0
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/dist/actions/registry.d.ts +1 -1
- package/dist/actions/registry.js +1 -1
- package/dist/index.d.ts +12 -8
- package/dist/index.js +7 -5
- package/dist/platform/tools/canvas-tools.js +11 -11
- package/dist/project-types/action-meta.d.ts +21 -7
- package/dist/project-types/action-meta.js +44 -213
- package/dist/project-types/index.d.ts +5 -3
- package/dist/project-types/index.js +3 -2
- package/dist/project-types/macro-meta.d.ts +39 -0
- package/dist/project-types/{skill-meta.js → macro-meta.js} +203 -12
- package/dist/project-types/macro-relevance.d.ts +47 -0
- package/dist/project-types/macro-relevance.js +58 -0
- package/dist/project-types/types.d.ts +23 -4
- package/dist/skills/book-macros.d.ts +10 -0
- package/dist/skills/{book-skills.js → book-macros.js} +6 -6
- package/dist/skills/business-macros.d.ts +11 -0
- package/dist/skills/{business-skills.js → business-macros.js} +7 -7
- package/dist/skills/canvas-exemplars.d.ts +2 -2
- package/dist/skills/canvas-exemplars.js +4 -4
- package/dist/skills/canvas-icons.d.ts +1 -1
- package/dist/skills/canvas-icons.js +2 -2
- package/dist/skills/canvas-macros.d.ts +11 -0
- package/dist/skills/{canvas-skills.js → canvas-macros.js} +6 -6
- package/dist/skills/content-macros.d.ts +10 -0
- package/dist/skills/{content-skills.js → content-macros.js} +6 -6
- package/dist/skills/course-macros.d.ts +9 -0
- package/dist/skills/{course-skills.js → course-macros.js} +5 -5
- package/dist/skills/index.d.ts +6 -2
- package/dist/skills/index.js +4 -2
- package/dist/skills/macro-invocation.d.ts +44 -0
- package/dist/skills/macro-invocation.js +63 -0
- package/dist/skills/macro-list.d.ts +54 -0
- package/dist/skills/macro-list.js +84 -0
- package/dist/skills/operations.js +4 -4
- package/dist/skills/platform-macros.d.ts +27 -0
- package/dist/skills/platform-macros.js +94 -0
- package/dist/skills/prompt-resolver.d.ts +8 -2
- package/dist/skills/prompt-resolver.js +14 -8
- package/dist/skills/research-macros.d.ts +10 -0
- package/dist/skills/{research-skills.js → research-macros.js} +6 -6
- package/dist/skills/resolver.d.ts +20 -9
- package/dist/skills/resolver.js +18 -21
- package/dist/skills/software-macros.d.ts +14 -0
- package/dist/skills/{software-skills.js → software-macros.js} +10 -10
- package/dist/skills/types.d.ts +2 -2
- package/dist/skills/types.js +4 -4
- package/dist/team/agent-templates.d.ts +0 -1
- package/dist/team/agent-templates.js +0 -2
- package/dist/team/custom-agents.d.ts +1 -2
- package/dist/team/custom-agents.js +1 -2
- package/dist/team/index.d.ts +5 -3
- package/dist/team/index.js +2 -1
- package/dist/team/{skill-requirements.d.ts → macro-requirements.d.ts} +20 -14
- package/dist/team/{skill-requirements.js → macro-requirements.js} +28 -22
- package/dist/team/macro-tool-gap.d.ts +42 -0
- package/dist/team/macro-tool-gap.js +69 -0
- package/dist/team/team-agent.d.ts +15 -2
- package/dist/team/team-agent.js +20 -10
- package/dist/team/types.d.ts +9 -4
- package/dist/team/workshop-data.d.ts +17 -5
- package/dist/team/workshop-data.js +13 -13
- package/package.json +1 -1
- package/dist/project-types/skill-meta.d.ts +0 -17
- package/dist/skills/book-skills.d.ts +0 -10
- package/dist/skills/business-skills.d.ts +0 -11
- package/dist/skills/canvas-skills.d.ts +0 -11
- package/dist/skills/content-skills.d.ts +0 -10
- package/dist/skills/course-skills.d.ts +0 -9
- package/dist/skills/platform-skills.d.ts +0 -20
- package/dist/skills/platform-skills.js +0 -87
- package/dist/skills/research-skills.d.ts +0 -10
- package/dist/skills/software-skills.d.ts +0 -14
|
@@ -0,0 +1,63 @@
|
|
|
1
|
+
/**
|
|
2
|
+
* What a host actually SENDS when a user invokes a macro.
|
|
3
|
+
*
|
|
4
|
+
* ⚠️ THE TWO HOSTS SENT DIFFERENT THINGS FOR THE SAME COMMAND. `/design` in the CLI wrapped the
|
|
5
|
+
* macro's prompt in ~20 lines of project context — do not scan the filesystem, the cwd is not the
|
|
6
|
+
* project, save work items with `workitem_add` and documents with `project_document_add` rather
|
|
7
|
+
* than writing files — while Desktop sent the prompt alone. Same name, same macro, materially
|
|
8
|
+
* different instructions, so the same request produced an agent that interviewed you and filled
|
|
9
|
+
* the backlog in one host and an agent that went looking for source files in the other.
|
|
10
|
+
*
|
|
11
|
+
* The prompt is shared data; what surrounds it was not. It is now.
|
|
12
|
+
*
|
|
13
|
+
* This composes the MESSAGE only. The tool-gap preamble (`macroToolGap`) stays a separate,
|
|
14
|
+
* host-applied prepend because it depends on which AGENT is being addressed, which is a thing
|
|
15
|
+
* only the host knows.
|
|
16
|
+
*
|
|
17
|
+
* Spec: project-docs/00-requirements/compilr-dev-sdk/macros-rename.md
|
|
18
|
+
*/
|
|
19
|
+
/**
|
|
20
|
+
* ⚠️ "A NEW PROJECT" IS ASSERTED, NOT DETECTED, AND THAT IS DELIBERATE. `/design` is the
|
|
21
|
+
* from-scratch macro — `/refine` is the one for a backlog that already exists — so invoking it
|
|
22
|
+
* states the intent. Deriving it instead (counting work items, say) would make the prompt depend
|
|
23
|
+
* on database state at send time, and be wrong the moment someone re-runs /design to redesign.
|
|
24
|
+
*/
|
|
25
|
+
function designContext(project) {
|
|
26
|
+
return `I want to design my project and create the backlog.
|
|
27
|
+
|
|
28
|
+
## PROJECT CONTEXT (IMPORTANT)
|
|
29
|
+
- Project Name: ${project.name} (ID: ${String(project.id)})
|
|
30
|
+
- This is a NEW project being designed from scratch
|
|
31
|
+
- Do NOT scan the filesystem - the current directory is NOT the project
|
|
32
|
+
- Do NOT use detect_project, glob, read_file, or ls tools
|
|
33
|
+
- Focus ONLY on gathering requirements via ask_user questions
|
|
34
|
+
|
|
35
|
+
## DOCUMENT STORAGE (CRITICAL)
|
|
36
|
+
Save all documents and backlog items using the database - do NOT write files directly.
|
|
37
|
+
- For backlog items: \`workitem_add({ type: "feature", title: "...", description: "...", priority: "high" })\`
|
|
38
|
+
- For documents: \`project_document_add({ doc_type: "prd", title: "...", content: "..." })\`
|
|
39
|
+
- The database is the source of truth for all project documents
|
|
40
|
+
- Do NOT use write_file or edit tools for documentation
|
|
41
|
+
`;
|
|
42
|
+
}
|
|
43
|
+
const DESIGN_CLOSER = 'Please start by using todo_write to track the design phases, then begin with Phase 1: Vision. ' +
|
|
44
|
+
'Use the ask_user tool to gather information efficiently.';
|
|
45
|
+
/**
|
|
46
|
+
* Compose the message for a macro invocation.
|
|
47
|
+
*
|
|
48
|
+
* A macro with no wrapper sends its prompt unchanged — that is the common case and stays the
|
|
49
|
+
* default, so adding a macro does not require touching this file.
|
|
50
|
+
*
|
|
51
|
+
* @param macroName the macro being invoked, e.g. `design`
|
|
52
|
+
* @param prompt the macro's resolved prompt text
|
|
53
|
+
* @param ctx what the host knows; an absent project omits the context block
|
|
54
|
+
*/
|
|
55
|
+
export function buildMacroInvocation(macroName, prompt, ctx = {}) {
|
|
56
|
+
if (macroName === 'design' && ctx.project) {
|
|
57
|
+
return {
|
|
58
|
+
message: `${designContext(ctx.project)}\n${prompt}\n\n${DESIGN_CLOSER}`,
|
|
59
|
+
displayMessage: 'Start the design process for my project.',
|
|
60
|
+
};
|
|
61
|
+
}
|
|
62
|
+
return { message: prompt, displayMessage: `/${macroName}` };
|
|
63
|
+
}
|
|
@@ -0,0 +1,54 @@
|
|
|
1
|
+
/**
|
|
2
|
+
* The list of macros a host presents — built once, here, for both hosts.
|
|
3
|
+
*
|
|
4
|
+
* ⚠️ THIS LIVED IN DESKTOP, AND THE CLI SIMPLY DID WITHOUT. Desktop decided what each entry was
|
|
5
|
+
* called, which category it belonged to and which ones came first; the terminal listed raw names
|
|
6
|
+
* in resolver order. That is not a presentation difference, it is the same question answered in
|
|
7
|
+
* one place and not asked in the other — so the two disagreed about the name of every macro.
|
|
8
|
+
*
|
|
9
|
+
* What legitimately differs per host is capability: a terminal cannot render a canvas. That is a
|
|
10
|
+
* parameter (`capabilities`), so neither host re-decides anything else.
|
|
11
|
+
*
|
|
12
|
+
* Spec: project-docs/00-requirements/compilr-dev-sdk/macro-metadata-consolidation.md
|
|
13
|
+
*/
|
|
14
|
+
import { type SkillSources } from './prompt-resolver.js';
|
|
15
|
+
import { type MacroCapabilities } from '../project-types/macro-relevance.js';
|
|
16
|
+
import type { MacroCategory, MacroMeta } from '../project-types/types.js';
|
|
17
|
+
/** One row in a slash menu, command palette or picker. */
|
|
18
|
+
export interface MacroListEntry {
|
|
19
|
+
id: string;
|
|
20
|
+
label: string;
|
|
21
|
+
description: string;
|
|
22
|
+
category: MacroCategory;
|
|
23
|
+
icon: string;
|
|
24
|
+
}
|
|
25
|
+
export interface BuildMacroListOptions {
|
|
26
|
+
/** Project directory, for project-scoped skills and bindings. */
|
|
27
|
+
projectPath?: string;
|
|
28
|
+
/** Project type id. Absent means no relevance ordering is applied. */
|
|
29
|
+
projectType?: string;
|
|
30
|
+
/** Extra prompt sources the host injects (factory, agents-coding). */
|
|
31
|
+
sources?: SkillSources;
|
|
32
|
+
/**
|
|
33
|
+
* Metadata for macros the SDK does not ship and therefore cannot describe.
|
|
34
|
+
*
|
|
35
|
+
* The SDK is the source of truth for ITS macros; a package that injects its own prompts is
|
|
36
|
+
* the source of truth for those. `factorySkills` is the case in point — factory depends on
|
|
37
|
+
* the SDK, not the reverse, so no registry here could ever cover it, and `factory-scaffold`
|
|
38
|
+
* rendered as a raw id. Supplying it through this channel keeps the hole visible and owned
|
|
39
|
+
* rather than hardcoded somewhere.
|
|
40
|
+
*
|
|
41
|
+
* Properly, each such package should export this alongside its prompts; until then the host
|
|
42
|
+
* that injects the source supplies it and asserts its own coverage.
|
|
43
|
+
*/
|
|
44
|
+
extraMeta?: Record<string, Omit<MacroMeta, 'id'>>;
|
|
45
|
+
/** What this host can render. */
|
|
46
|
+
capabilities?: MacroCapabilities;
|
|
47
|
+
}
|
|
48
|
+
/**
|
|
49
|
+
* Everything typeable after a slash, labelled, and ordered by relevance to the project type.
|
|
50
|
+
*
|
|
51
|
+
* Disabled entries are filtered out — an entry offered and then refused as "Unknown command" is
|
|
52
|
+
* worse than one never offered.
|
|
53
|
+
*/
|
|
54
|
+
export declare function buildMacroList(options?: BuildMacroListOptions): MacroListEntry[];
|
|
@@ -0,0 +1,84 @@
|
|
|
1
|
+
/**
|
|
2
|
+
* The list of macros a host presents — built once, here, for both hosts.
|
|
3
|
+
*
|
|
4
|
+
* ⚠️ THIS LIVED IN DESKTOP, AND THE CLI SIMPLY DID WITHOUT. Desktop decided what each entry was
|
|
5
|
+
* called, which category it belonged to and which ones came first; the terminal listed raw names
|
|
6
|
+
* in resolver order. That is not a presentation difference, it is the same question answered in
|
|
7
|
+
* one place and not asked in the other — so the two disagreed about the name of every macro.
|
|
8
|
+
*
|
|
9
|
+
* What legitimately differs per host is capability: a terminal cannot render a canvas. That is a
|
|
10
|
+
* parameter (`capabilities`), so neither host re-decides anything else.
|
|
11
|
+
*
|
|
12
|
+
* Spec: project-docs/00-requirements/compilr-dev-sdk/macro-metadata-consolidation.md
|
|
13
|
+
*/
|
|
14
|
+
import { getAllAvailableSkills } from './prompt-resolver.js';
|
|
15
|
+
import { MACRO_META_REGISTRY } from '../project-types/macro-meta.js';
|
|
16
|
+
import { getRelevantMacros } from '../project-types/macro-relevance.js';
|
|
17
|
+
import { platformMacros } from './platform-macros.js';
|
|
18
|
+
/** Derived from the tag, never a name list — a stale name list is how `canvas-styles` leaked. */
|
|
19
|
+
function isCanvasMacro(name) {
|
|
20
|
+
return platformMacros.some((m) => m.name === name && (m.tags ?? []).includes('canvas'));
|
|
21
|
+
}
|
|
22
|
+
/**
|
|
23
|
+
* Everything typeable after a slash, labelled, and ordered by relevance to the project type.
|
|
24
|
+
*
|
|
25
|
+
* Disabled entries are filtered out — an entry offered and then refused as "Unknown command" is
|
|
26
|
+
* worse than one never offered.
|
|
27
|
+
*/
|
|
28
|
+
export function buildMacroList(options = {}) {
|
|
29
|
+
const { projectPath, projectType, sources, capabilities, extraMeta } = options;
|
|
30
|
+
const entries = getAllAvailableSkills(projectPath, sources)
|
|
31
|
+
.filter((entry) => entry.enabled !== false)
|
|
32
|
+
// A host that cannot render a canvas must not be OFFERED one. Only ours are withheld: a
|
|
33
|
+
// user's own SKILL.md that happens to be called `canvas` is theirs and still works, which
|
|
34
|
+
// is the same line the CLI's resolver already draws.
|
|
35
|
+
.filter((entry) => !(capabilities?.canvas === false && entry.source === 'sdk' && isCanvasMacro(entry.name)))
|
|
36
|
+
.map((entry) => {
|
|
37
|
+
// A bound command is named for the binding, not for what it resolves to.
|
|
38
|
+
if (entry.source === 'binding') {
|
|
39
|
+
return {
|
|
40
|
+
id: entry.name,
|
|
41
|
+
label: `/${entry.name}`,
|
|
42
|
+
description: entry.description,
|
|
43
|
+
category: 'development',
|
|
44
|
+
icon: 'link',
|
|
45
|
+
};
|
|
46
|
+
}
|
|
47
|
+
// A user's or project's own SKILL.md. Its scope is part of how it reads, because two of
|
|
48
|
+
// them can share a name and the project's wins.
|
|
49
|
+
if (entry.scope) {
|
|
50
|
+
return {
|
|
51
|
+
id: entry.name,
|
|
52
|
+
label: `/${entry.name}`,
|
|
53
|
+
description: `[${entry.scope}] ${entry.description}`,
|
|
54
|
+
category: 'development',
|
|
55
|
+
icon: 'wand',
|
|
56
|
+
};
|
|
57
|
+
}
|
|
58
|
+
// Something we ship. The fallbacks below are a hole, not a feature — they are what made
|
|
59
|
+
// twenty macros render as `business-vision`, `market-analysis`, … and they are kept
|
|
60
|
+
// unreachable by tests/skills/macro-meta-coverage.test.ts.
|
|
61
|
+
const meta = (entry.name in MACRO_META_REGISTRY ? MACRO_META_REGISTRY[entry.name] : undefined) ??
|
|
62
|
+
extraMeta?.[entry.name];
|
|
63
|
+
return {
|
|
64
|
+
id: entry.name,
|
|
65
|
+
label: meta?.label ?? entry.name,
|
|
66
|
+
description: entry.description,
|
|
67
|
+
category: meta?.category ?? 'development',
|
|
68
|
+
icon: meta?.icon ?? 'Zap',
|
|
69
|
+
};
|
|
70
|
+
});
|
|
71
|
+
const relevant = getRelevantMacros(projectType, capabilities);
|
|
72
|
+
if (relevant.length === 0)
|
|
73
|
+
return entries;
|
|
74
|
+
// Promoted entries come back in RELEVANCE order — a business plan leads with its business
|
|
75
|
+
// macros — rather than in whatever order the resolver happened to return them. Everything
|
|
76
|
+
// else keeps its original order behind them.
|
|
77
|
+
const rank = new Map(relevant.map((id, i) => [id, i]));
|
|
78
|
+
const rankOf = (id) => rank.get(id) ?? Number.MAX_SAFE_INTEGER;
|
|
79
|
+
const promoted = entries
|
|
80
|
+
.filter((e) => rank.has(e.id))
|
|
81
|
+
.sort((a, b) => rankOf(a.id) - rankOf(b.id));
|
|
82
|
+
const rest = entries.filter((e) => !rank.has(e.id));
|
|
83
|
+
return [...promoted, ...rest];
|
|
84
|
+
}
|
|
@@ -7,8 +7,8 @@
|
|
|
7
7
|
* - Validation (quality checks beyond parseSkillMarkdown)
|
|
8
8
|
* - Binding resolution (config.json slash command remapping)
|
|
9
9
|
*/
|
|
10
|
-
import {
|
|
11
|
-
import {
|
|
10
|
+
import { RESERVED_MACRO_NAMES } from './types.js';
|
|
11
|
+
import { platformMacros } from './platform-macros.js';
|
|
12
12
|
/**
|
|
13
13
|
* Detect user/project skills that shadow SDK reserved names.
|
|
14
14
|
* Called at startup to warn users about collisions introduced by SDK updates.
|
|
@@ -18,7 +18,7 @@ import { platformSkills } from './platform-skills.js';
|
|
|
18
18
|
* already has a skill with that name.
|
|
19
19
|
*/
|
|
20
20
|
export function detectCollisions(userSkills) {
|
|
21
|
-
const reserved = new Set(
|
|
21
|
+
const reserved = new Set(RESERVED_MACRO_NAMES);
|
|
22
22
|
const collisions = [];
|
|
23
23
|
for (const skill of userSkills) {
|
|
24
24
|
if (reserved.has(skill.name)) {
|
|
@@ -54,7 +54,7 @@ export function formatCollisionWarnings(collisions) {
|
|
|
54
54
|
export function diffForkVsUpstream(forkPrompt, upstreamSkillName) {
|
|
55
55
|
// Find the upstream SDK skill
|
|
56
56
|
// Check all platform skills + builtins
|
|
57
|
-
const allSdk = [...
|
|
57
|
+
const allSdk = [...platformMacros];
|
|
58
58
|
const upstream = allSdk.find((s) => s.name === upstreamSkillName);
|
|
59
59
|
if (!upstream)
|
|
60
60
|
return null;
|
|
@@ -0,0 +1,27 @@
|
|
|
1
|
+
/**
|
|
2
|
+
* Platform Macros — Aggregate
|
|
3
|
+
*
|
|
4
|
+
* The prompts we ship. A macro is a named prompt the USER invokes (`/design`, `/prd`); it
|
|
5
|
+
* expands into a message. That is not what a SKILL is — a skill is a capability the MODEL
|
|
6
|
+
* chooses from a catalogue, installed as `SKILL.md` and loaded on demand. These 42 are macros
|
|
7
|
+
* and have always been; they were named "skills" before the two were told apart.
|
|
8
|
+
*
|
|
9
|
+
* They are still built with `defineSkill()` from @compilr-dev/agents, deliberately: that is the
|
|
10
|
+
* shared primitive for "a named prompt with a description", and installed skills extend the same
|
|
11
|
+
* shape. The primitive is not being renamed — the population is.
|
|
12
|
+
*
|
|
13
|
+
* Per-domain files: software-macros.ts, research-macros.ts, business-macros.ts, content-macros.ts,
|
|
14
|
+
* course-macros.ts, book-macros.ts, canvas-macros.ts (+ canvas-exemplars.ts, canvas-icons.ts).
|
|
15
|
+
*/
|
|
16
|
+
import type { Skill } from '@compilr-dev/agents';
|
|
17
|
+
export { designMacro, sketchMacro, prdMacro, refineMacro, refineItemMacro, architectureMacro, sessionNotesMacro, buildMacro, scaffoldMacro, } from './software-macros.js';
|
|
18
|
+
export { outlineMacro, literatureReviewMacro, draftSectionMacro, peerReviewMacro, researchScaffoldMacro, } from './research-macros.js';
|
|
19
|
+
export { businessVisionMacro, marketAnalysisMacro, competitorAnalysisMacro, financialModelMacro, pitchOutlineMacro, businessReviewMacro, } from './business-macros.js';
|
|
20
|
+
export { brandSetupMacro, contentStrategyMacro, contentCalendarMacro, createContentMacro, contentReviewMacro, } from './content-macros.js';
|
|
21
|
+
export { curriculumDesignMacro, lessonPlanMacro, assessmentDesignMacro, courseReviewMacro, } from './course-macros.js';
|
|
22
|
+
export { bookOutlineMacro, characterDesignMacro, plotThreadsMacro, sceneBreakdownMacro, bookReviewMacro, } from './book-macros.js';
|
|
23
|
+
export { canvasMacro, infographicMacro, carouselMacro, boardMacro, canvasStylesMacro, } from './canvas-macros.js';
|
|
24
|
+
export { canvasExemplarInfographicMacro, canvasExemplarAppScreenMacro, } from './canvas-exemplars.js';
|
|
25
|
+
export { canvasIconsMacro } from './canvas-icons.js';
|
|
26
|
+
/** Every macro we ship. Count is asserted in tests/skills/platform-macros.test.ts. */
|
|
27
|
+
export declare const platformMacros: Skill[];
|
|
@@ -0,0 +1,94 @@
|
|
|
1
|
+
/**
|
|
2
|
+
* Platform Macros — Aggregate
|
|
3
|
+
*
|
|
4
|
+
* The prompts we ship. A macro is a named prompt the USER invokes (`/design`, `/prd`); it
|
|
5
|
+
* expands into a message. That is not what a SKILL is — a skill is a capability the MODEL
|
|
6
|
+
* chooses from a catalogue, installed as `SKILL.md` and loaded on demand. These 42 are macros
|
|
7
|
+
* and have always been; they were named "skills" before the two were told apart.
|
|
8
|
+
*
|
|
9
|
+
* They are still built with `defineSkill()` from @compilr-dev/agents, deliberately: that is the
|
|
10
|
+
* shared primitive for "a named prompt with a description", and installed skills extend the same
|
|
11
|
+
* shape. The primitive is not being renamed — the population is.
|
|
12
|
+
*
|
|
13
|
+
* Per-domain files: software-macros.ts, research-macros.ts, business-macros.ts, content-macros.ts,
|
|
14
|
+
* course-macros.ts, book-macros.ts, canvas-macros.ts (+ canvas-exemplars.ts, canvas-icons.ts).
|
|
15
|
+
*/
|
|
16
|
+
// Software Development
|
|
17
|
+
export { designMacro, sketchMacro, prdMacro, refineMacro, refineItemMacro, architectureMacro, sessionNotesMacro, buildMacro, scaffoldMacro, } from './software-macros.js';
|
|
18
|
+
// Research Paper
|
|
19
|
+
export { outlineMacro, literatureReviewMacro, draftSectionMacro, peerReviewMacro, researchScaffoldMacro, } from './research-macros.js';
|
|
20
|
+
// Business Plan
|
|
21
|
+
export { businessVisionMacro, marketAnalysisMacro, competitorAnalysisMacro, financialModelMacro, pitchOutlineMacro, businessReviewMacro, } from './business-macros.js';
|
|
22
|
+
// Content & Marketing
|
|
23
|
+
export { brandSetupMacro, contentStrategyMacro, contentCalendarMacro, createContentMacro, contentReviewMacro, } from './content-macros.js';
|
|
24
|
+
// Course / Training
|
|
25
|
+
export { curriculumDesignMacro, lessonPlanMacro, assessmentDesignMacro, courseReviewMacro, } from './course-macros.js';
|
|
26
|
+
// Book
|
|
27
|
+
export { bookOutlineMacro, characterDesignMacro, plotThreadsMacro, sceneBreakdownMacro, bookReviewMacro, } from './book-macros.js';
|
|
28
|
+
// Canvas (visual)
|
|
29
|
+
export { canvasMacro, infographicMacro, carouselMacro, boardMacro, canvasStylesMacro, } from './canvas-macros.js';
|
|
30
|
+
// Canvas exemplars — generated from the design handoff; see canvas-exemplars.ts.
|
|
31
|
+
export { canvasExemplarInfographicMacro, canvasExemplarAppScreenMacro, } from './canvas-exemplars.js';
|
|
32
|
+
export { canvasIconsMacro } from './canvas-icons.js';
|
|
33
|
+
// Import all for the aggregate array
|
|
34
|
+
import { designMacro, sketchMacro, prdMacro, refineMacro, refineItemMacro, architectureMacro, sessionNotesMacro, buildMacro, scaffoldMacro, } from './software-macros.js';
|
|
35
|
+
import { outlineMacro, literatureReviewMacro, draftSectionMacro, peerReviewMacro, researchScaffoldMacro, } from './research-macros.js';
|
|
36
|
+
import { businessVisionMacro, marketAnalysisMacro, competitorAnalysisMacro, financialModelMacro, pitchOutlineMacro, businessReviewMacro, } from './business-macros.js';
|
|
37
|
+
import { brandSetupMacro, contentStrategyMacro, contentCalendarMacro, createContentMacro, contentReviewMacro, } from './content-macros.js';
|
|
38
|
+
import { curriculumDesignMacro, lessonPlanMacro, assessmentDesignMacro, courseReviewMacro, } from './course-macros.js';
|
|
39
|
+
import { bookOutlineMacro, characterDesignMacro, plotThreadsMacro, sceneBreakdownMacro, bookReviewMacro, } from './book-macros.js';
|
|
40
|
+
import { canvasMacro, infographicMacro, carouselMacro, boardMacro, canvasStylesMacro, } from './canvas-macros.js';
|
|
41
|
+
import { canvasExemplarInfographicMacro, canvasExemplarAppScreenMacro, } from './canvas-exemplars.js';
|
|
42
|
+
import { canvasIconsMacro } from './canvas-icons.js';
|
|
43
|
+
/** Every macro we ship. Count is asserted in tests/skills/platform-macros.test.ts. */
|
|
44
|
+
export const platformMacros = [
|
|
45
|
+
// Software (9)
|
|
46
|
+
designMacro,
|
|
47
|
+
sketchMacro,
|
|
48
|
+
prdMacro,
|
|
49
|
+
refineMacro,
|
|
50
|
+
refineItemMacro,
|
|
51
|
+
architectureMacro,
|
|
52
|
+
sessionNotesMacro,
|
|
53
|
+
buildMacro,
|
|
54
|
+
scaffoldMacro,
|
|
55
|
+
// Research (5)
|
|
56
|
+
outlineMacro,
|
|
57
|
+
literatureReviewMacro,
|
|
58
|
+
draftSectionMacro,
|
|
59
|
+
peerReviewMacro,
|
|
60
|
+
researchScaffoldMacro,
|
|
61
|
+
// Business (6)
|
|
62
|
+
businessVisionMacro,
|
|
63
|
+
marketAnalysisMacro,
|
|
64
|
+
competitorAnalysisMacro,
|
|
65
|
+
financialModelMacro,
|
|
66
|
+
pitchOutlineMacro,
|
|
67
|
+
businessReviewMacro,
|
|
68
|
+
// Content (5)
|
|
69
|
+
brandSetupMacro,
|
|
70
|
+
contentStrategyMacro,
|
|
71
|
+
contentCalendarMacro,
|
|
72
|
+
createContentMacro,
|
|
73
|
+
contentReviewMacro,
|
|
74
|
+
// Course (4)
|
|
75
|
+
curriculumDesignMacro,
|
|
76
|
+
lessonPlanMacro,
|
|
77
|
+
assessmentDesignMacro,
|
|
78
|
+
courseReviewMacro,
|
|
79
|
+
// Book (5)
|
|
80
|
+
bookOutlineMacro,
|
|
81
|
+
characterDesignMacro,
|
|
82
|
+
plotThreadsMacro,
|
|
83
|
+
sceneBreakdownMacro,
|
|
84
|
+
bookReviewMacro,
|
|
85
|
+
// Canvas (4)
|
|
86
|
+
canvasMacro,
|
|
87
|
+
infographicMacro,
|
|
88
|
+
carouselMacro,
|
|
89
|
+
boardMacro,
|
|
90
|
+
canvasStylesMacro,
|
|
91
|
+
canvasExemplarInfographicMacro,
|
|
92
|
+
canvasExemplarAppScreenMacro,
|
|
93
|
+
canvasIconsMacro,
|
|
94
|
+
];
|
|
@@ -1,11 +1,17 @@
|
|
|
1
1
|
/**
|
|
2
|
-
* Unified
|
|
2
|
+
* Unified slash-command prompt resolver — used by both CLI and Desktop.
|
|
3
3
|
*
|
|
4
|
-
* Resolves a slash command name to a
|
|
4
|
+
* Resolves a slash command name to a prompt using:
|
|
5
5
|
* 1. Binding resolution (config.json slashCommands)
|
|
6
6
|
* 2. 5-layer priority: project → user → SDK platform → agents builtin → agents-coding
|
|
7
7
|
*
|
|
8
8
|
* Also provides getAllAvailableSkills() for autocomplete/picker display.
|
|
9
|
+
*
|
|
10
|
+
* ⚠️ DELIBERATELY NOT RENAMED YET. This module spans BOTH populations: layer 4 is platform
|
|
11
|
+
* macros, but layers 2–3 read the user's and project's `SKILL.md` directories, so today an
|
|
12
|
+
* installed skill is also reachable by typing its name. That conflation is what M5 removes, by
|
|
13
|
+
* moving user-authored macros to `commands/` and leaving `skills/` to skills alone. Naming this
|
|
14
|
+
* module before that split would name the wrong shape; the rename follows M5, not this group.
|
|
9
15
|
*/
|
|
10
16
|
import type { ForkedFromMarker } from './types.js';
|
|
11
17
|
/** Result of resolving a skill prompt */
|
|
@@ -1,17 +1,23 @@
|
|
|
1
1
|
/**
|
|
2
|
-
* Unified
|
|
2
|
+
* Unified slash-command prompt resolver — used by both CLI and Desktop.
|
|
3
3
|
*
|
|
4
|
-
* Resolves a slash command name to a
|
|
4
|
+
* Resolves a slash command name to a prompt using:
|
|
5
5
|
* 1. Binding resolution (config.json slashCommands)
|
|
6
6
|
* 2. 5-layer priority: project → user → SDK platform → agents builtin → agents-coding
|
|
7
7
|
*
|
|
8
8
|
* Also provides getAllAvailableSkills() for autocomplete/picker display.
|
|
9
|
+
*
|
|
10
|
+
* ⚠️ DELIBERATELY NOT RENAMED YET. This module spans BOTH populations: layer 4 is platform
|
|
11
|
+
* macros, but layers 2–3 read the user's and project's `SKILL.md` directories, so today an
|
|
12
|
+
* installed skill is also reachable by typing its name. That conflation is what M5 removes, by
|
|
13
|
+
* moving user-authored macros to `commands/` and leaving `skills/` to skills alone. Naming this
|
|
14
|
+
* module before that split would name the wrong shape; the rename follows M5, not this group.
|
|
9
15
|
*/
|
|
10
16
|
import { readFileSync, existsSync, readdirSync } from 'node:fs';
|
|
11
17
|
import { join } from 'node:path';
|
|
12
18
|
import { parseSkillMarkdown } from './loader.js';
|
|
13
19
|
import { resolveBinding, getSkillsDir, readScopeConfigSync } from './paths.js';
|
|
14
|
-
import {
|
|
20
|
+
import { platformMacros } from './platform-macros.js';
|
|
15
21
|
// Re-export builtinSkills from agents (available via SDK re-export)
|
|
16
22
|
// The SDK re-exports builtinSkills from @compilr-dev/agents
|
|
17
23
|
import { builtinSkills } from '@compilr-dev/agents';
|
|
@@ -99,10 +105,10 @@ export function resolveSkillPrompt(name, projectDir, sources) {
|
|
|
99
105
|
return { prompt, skillName: name, isBound: false, source: 'user' };
|
|
100
106
|
}
|
|
101
107
|
}
|
|
102
|
-
// 4. SDK platform
|
|
103
|
-
const
|
|
104
|
-
if (
|
|
105
|
-
return { prompt:
|
|
108
|
+
// 4. SDK platform macros
|
|
109
|
+
const sdkMacro = platformMacros.find((s) => s.name === name);
|
|
110
|
+
if (sdkMacro) {
|
|
111
|
+
return { prompt: sdkMacro.prompt, skillName: name, isBound: false, source: 'sdk' };
|
|
106
112
|
}
|
|
107
113
|
// 5. Additional sources
|
|
108
114
|
if (sources?.factorySkills) {
|
|
@@ -178,7 +184,7 @@ export function getAllAvailableSkills(projectDir, sources) {
|
|
|
178
184
|
}
|
|
179
185
|
}
|
|
180
186
|
// 2. SDK platform skills
|
|
181
|
-
for (const skill of
|
|
187
|
+
for (const skill of platformMacros) {
|
|
182
188
|
if (!seen.has(skill.name)) {
|
|
183
189
|
seen.add(skill.name);
|
|
184
190
|
entries.push({ name: skill.name, description: skill.description, source: 'sdk' });
|
|
@@ -0,0 +1,10 @@
|
|
|
1
|
+
/**
|
|
2
|
+
* Research Paper Macros
|
|
3
|
+
*
|
|
4
|
+
* outline, literature-review, draft-section, peer-review, research-scaffold
|
|
5
|
+
*/
|
|
6
|
+
export declare const outlineMacro: import("@compilr-dev/agents").Skill;
|
|
7
|
+
export declare const literatureReviewMacro: import("@compilr-dev/agents").Skill;
|
|
8
|
+
export declare const draftSectionMacro: import("@compilr-dev/agents").Skill;
|
|
9
|
+
export declare const peerReviewMacro: import("@compilr-dev/agents").Skill;
|
|
10
|
+
export declare const researchScaffoldMacro: import("@compilr-dev/agents").Skill;
|
|
@@ -1,10 +1,10 @@
|
|
|
1
1
|
/**
|
|
2
|
-
* Research Paper
|
|
2
|
+
* Research Paper Macros
|
|
3
3
|
*
|
|
4
4
|
* outline, literature-review, draft-section, peer-review, research-scaffold
|
|
5
5
|
*/
|
|
6
6
|
import { defineSkill } from '@compilr-dev/agents';
|
|
7
|
-
export const
|
|
7
|
+
export const outlineMacro = defineSkill({
|
|
8
8
|
name: 'outline',
|
|
9
9
|
description: 'Build or refine the research paper structure — define sections, formulate claims with evidence requirements, and map sources to claims. Use when starting a new paper or restructuring an existing one. Produces a ResearchModel outline stored in the project database.',
|
|
10
10
|
prompt: `You are in OUTLINE MODE. Your goal is to help the user build or refine a structured outline for their research paper using the Research Model.
|
|
@@ -148,7 +148,7 @@ Create one work item per section:
|
|
|
148
148
|
✓ User has reviewed and approved the outline`,
|
|
149
149
|
tags: ['research', 'planning', 'outline'],
|
|
150
150
|
});
|
|
151
|
-
export const
|
|
151
|
+
export const literatureReviewMacro = defineSkill({
|
|
152
152
|
name: 'literature-review',
|
|
153
153
|
description: 'Systematically analyze sources from the Knowledge Base — extract key findings, link evidence to claims in the outline, assess source quality, and identify coverage gaps. Use after the outline exists and sources have been added to the Knowledge Base.',
|
|
154
154
|
prompt: `You are in LITERATURE REVIEW MODE. Your goal is to systematically analyze the sources in the Knowledge Base and connect them to the Research Model's sections and claims.
|
|
@@ -252,7 +252,7 @@ If multiple sources have been analyzed, provide a thematic synthesis:
|
|
|
252
252
|
✓ User has reviewed the source-claim mappings`,
|
|
253
253
|
tags: ['research', 'analysis', 'sources'],
|
|
254
254
|
});
|
|
255
|
-
export const
|
|
255
|
+
export const draftSectionMacro = defineSkill({
|
|
256
256
|
name: 'draft-section',
|
|
257
257
|
description: 'Draft a specific paper section using the outline structure, claims, and linked sources. Use when the outline and literature review are complete for the target section. Produces academic prose with inline citations following the selected citation style.',
|
|
258
258
|
prompt: `You are in DRAFT SECTION MODE. Your goal is to write or revise a section of the research paper, guided by the Research Model's outline, claims, and linked sources.
|
|
@@ -364,7 +364,7 @@ Report to the user:
|
|
|
364
364
|
✓ User has reviewed the draft`,
|
|
365
365
|
tags: ['research', 'writing', 'drafting'],
|
|
366
366
|
});
|
|
367
|
-
export const
|
|
367
|
+
export const peerReviewMacro = defineSkill({
|
|
368
368
|
name: 'peer-review',
|
|
369
369
|
description: 'Peer review the research paper — validate argument structure, find logical gaps, check claim-evidence consistency, assess citation coverage, and verify cross-section coherence. Use before submission to identify weaknesses. Produces a structured review report with actionable issues.',
|
|
370
370
|
prompt: `You are in PEER REVIEW MODE. Your goal is to critically evaluate the research paper's argument structure, identify gaps, and check consistency — like an academic peer reviewer.
|
|
@@ -513,7 +513,7 @@ For issues that affect the Research Model:
|
|
|
513
513
|
✓ User has received the review summary`,
|
|
514
514
|
tags: ['research', 'review', 'quality'],
|
|
515
515
|
});
|
|
516
|
-
export const
|
|
516
|
+
export const researchScaffoldMacro = defineSkill({
|
|
517
517
|
name: 'research-scaffold',
|
|
518
518
|
description: 'Scaffold a new research paper project from a template — APA journal article, IEEE conference paper, thesis/dissertation, literature review, or lab report. Use when starting a fresh research project. Creates the ResearchModel with template-appropriate sections, citation style, and document structure.',
|
|
519
519
|
prompt: `You are in RESEARCH SCAFFOLD MODE. Your goal is to help the user set up a new research paper project using a template.
|
|
@@ -6,7 +6,7 @@
|
|
|
6
6
|
* 5-layer priority (first match by name wins):
|
|
7
7
|
* 1. project (<projectDir>/.compilr/skills/)
|
|
8
8
|
* 2. user (~/.compilr-dev/skills/)
|
|
9
|
-
* 3. sdk (
|
|
9
|
+
* 3. sdk (platformMacros)
|
|
10
10
|
* 4. agents (builtinSkills)
|
|
11
11
|
* 5. agents-coding (codingSkills)
|
|
12
12
|
*
|
|
@@ -28,8 +28,14 @@ export interface SkillEligibilityContext {
|
|
|
28
28
|
agentId?: string;
|
|
29
29
|
/** Tool names this agent has access to. */
|
|
30
30
|
toolNames?: ReadonlySet<string> | readonly string[];
|
|
31
|
-
/**
|
|
32
|
-
|
|
31
|
+
/**
|
|
32
|
+
* Skills this agent may choose. `undefined` = no allowlist, `[]` = none.
|
|
33
|
+
*
|
|
34
|
+
* ⚠️ NAMED FOR WHAT IT HOLDS. This was called `enabledSkills` and documented "legacy", while
|
|
35
|
+
* every caller fed it `grantedSkills` — the exact field-name reuse that inverted the contract
|
|
36
|
+
* and stripped every custom agent's skills in 0.25.0, preserved in the type that caused it.
|
|
37
|
+
*/
|
|
38
|
+
grantedSkills?: readonly string[];
|
|
33
39
|
/** Active project category ('software', 'research', 'business', ...). */
|
|
34
40
|
projectType?: string;
|
|
35
41
|
}
|
|
@@ -62,11 +68,15 @@ export declare function resolveSkillsForAgent(skills: CustomSkill[], context: Sk
|
|
|
62
68
|
* than once. Every judgement lives here: which fields of the agent matter, and what an absent
|
|
63
69
|
* allowlist means.
|
|
64
70
|
*
|
|
65
|
-
* ⚠️ `
|
|
66
|
-
*
|
|
67
|
-
*
|
|
68
|
-
*
|
|
69
|
-
*
|
|
71
|
+
* ⚠️ READS `grantedSkills`. There used to be a second field, `enabledSkills`, holding MACRO ids —
|
|
72
|
+
* the 13 its picker offered were `code-review`, `debug`, `design`, `prd` and friends, all things
|
|
73
|
+
* a user types — and 0.25.0 wired Skills enforcement onto it, so ticking "Code Review" wrote a
|
|
74
|
+
* name no installed skill has and the agent silently got zero skills. That field is deleted, and
|
|
75
|
+
* the reason it must never come back in another guise is the whole point of this comment.
|
|
76
|
+
*
|
|
77
|
+
* `grantedSkills` follows the MCP contract: `undefined` = never asked, reaches everything
|
|
78
|
+
* eligible; `[]` = granted nothing. That reading is legitimate here precisely because the field
|
|
79
|
+
* is new and nothing has a prior meaning.
|
|
70
80
|
*
|
|
71
81
|
* @param pool every skill installed for this machine/project, unfiltered
|
|
72
82
|
* @param agent the agent being built — role, id and its allowlist come from here
|
|
@@ -75,7 +85,8 @@ export declare function resolveSkillsForAgent(skills: CustomSkill[], context: Sk
|
|
|
75
85
|
export declare function resolveSkillsForTeamAgent(pool: CustomSkill[], agent: {
|
|
76
86
|
id: string;
|
|
77
87
|
role?: string;
|
|
78
|
-
|
|
88
|
+
/** Skills this agent may choose. undefined = never asked, [] = none. */
|
|
89
|
+
grantedSkills?: readonly string[];
|
|
79
90
|
}, opts?: {
|
|
80
91
|
projectType?: string;
|
|
81
92
|
toolNames?: readonly string[];
|
package/dist/skills/resolver.js
CHANGED
|
@@ -6,7 +6,7 @@
|
|
|
6
6
|
* 5-layer priority (first match by name wins):
|
|
7
7
|
* 1. project (<projectDir>/.compilr/skills/)
|
|
8
8
|
* 2. user (~/.compilr-dev/skills/)
|
|
9
|
-
* 3. sdk (
|
|
9
|
+
* 3. sdk (platformMacros)
|
|
10
10
|
* 4. agents (builtinSkills)
|
|
11
11
|
* 5. agents-coding (codingSkills)
|
|
12
12
|
*
|
|
@@ -47,20 +47,13 @@ export function resolveLayeredSkills(layers) {
|
|
|
47
47
|
export function resolveSkillsForAgent(skills, context) {
|
|
48
48
|
const toolSet = context.toolNames instanceof Set ? context.toolNames : new Set(context.toolNames ?? []);
|
|
49
49
|
/*
|
|
50
|
-
⚠️
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
0.25.0 copied the MCP reading (`[]` = granted nothing) onto this field and inverted it. Because
|
|
57
|
-
the definition normalises to `[]`, EVERY custom agent ever created carries one — so every one
|
|
58
|
-
of them silently got no skills at all, having been told empty meant everything.
|
|
59
|
-
|
|
60
|
-
MCP grants could afford the stricter reading because they were new and nothing had a prior
|
|
61
|
-
meaning. This field is not new. Honour what the UI has been promising.
|
|
50
|
+
⚠️ THIS SET COMES FROM `grantedSkills`, WHICH IS NEW — so `[]` correctly means "granted
|
|
51
|
+
nothing", the MCP contract. It must NEVER be fed `enabledSkills`, which holds MACRO ids and
|
|
52
|
+
has always documented empty as "all"; 0.25.0 conflated the two and every custom agent
|
|
53
|
+
silently lost its skills. The field is now named `grantedSkills` on both sides, so the two
|
|
54
|
+
cannot be mixed up by a caller that does not read this comment.
|
|
62
55
|
*/
|
|
63
|
-
const allowlist = context.
|
|
56
|
+
const allowlist = context.grantedSkills ? new Set(context.grantedSkills) : null;
|
|
64
57
|
return skills.filter((skill) => {
|
|
65
58
|
if (skill.enabled === false)
|
|
66
59
|
return false;
|
|
@@ -86,7 +79,7 @@ export function resolveSkillsForAgent(skills, context) {
|
|
|
86
79
|
return false;
|
|
87
80
|
}
|
|
88
81
|
}
|
|
89
|
-
// Stage 1.4 —
|
|
82
|
+
// Stage 1.4 — the agent's explicit grant.
|
|
90
83
|
if (allowlist && !allowlist.has(skill.name))
|
|
91
84
|
return false;
|
|
92
85
|
return true;
|
|
@@ -101,11 +94,15 @@ export function resolveSkillsForAgent(skills, context) {
|
|
|
101
94
|
* than once. Every judgement lives here: which fields of the agent matter, and what an absent
|
|
102
95
|
* allowlist means.
|
|
103
96
|
*
|
|
104
|
-
* ⚠️ `
|
|
105
|
-
*
|
|
106
|
-
*
|
|
107
|
-
*
|
|
108
|
-
*
|
|
97
|
+
* ⚠️ READS `grantedSkills`. There used to be a second field, `enabledSkills`, holding MACRO ids —
|
|
98
|
+
* the 13 its picker offered were `code-review`, `debug`, `design`, `prd` and friends, all things
|
|
99
|
+
* a user types — and 0.25.0 wired Skills enforcement onto it, so ticking "Code Review" wrote a
|
|
100
|
+
* name no installed skill has and the agent silently got zero skills. That field is deleted, and
|
|
101
|
+
* the reason it must never come back in another guise is the whole point of this comment.
|
|
102
|
+
*
|
|
103
|
+
* `grantedSkills` follows the MCP contract: `undefined` = never asked, reaches everything
|
|
104
|
+
* eligible; `[]` = granted nothing. That reading is legitimate here precisely because the field
|
|
105
|
+
* is new and nothing has a prior meaning.
|
|
109
106
|
*
|
|
110
107
|
* @param pool every skill installed for this machine/project, unfiltered
|
|
111
108
|
* @param agent the agent being built — role, id and its allowlist come from here
|
|
@@ -115,7 +112,7 @@ export function resolveSkillsForTeamAgent(pool, agent, opts = {}) {
|
|
|
115
112
|
return resolveSkillsForAgent(pool, {
|
|
116
113
|
role: agent.role,
|
|
117
114
|
agentId: agent.id,
|
|
118
|
-
|
|
115
|
+
grantedSkills: agent.grantedSkills,
|
|
119
116
|
projectType: opts.projectType,
|
|
120
117
|
toolNames: opts.toolNames,
|
|
121
118
|
});
|
|
@@ -0,0 +1,14 @@
|
|
|
1
|
+
/**
|
|
2
|
+
* Software Development Macros
|
|
3
|
+
*
|
|
4
|
+
* design, sketch, prd, refine, refine-item, architecture, session-notes, build, scaffold
|
|
5
|
+
*/
|
|
6
|
+
export declare const designMacro: import("@compilr-dev/agents").Skill;
|
|
7
|
+
export declare const refineMacro: import("@compilr-dev/agents").Skill;
|
|
8
|
+
export declare const sketchMacro: import("@compilr-dev/agents").Skill;
|
|
9
|
+
export declare const refineItemMacro: import("@compilr-dev/agents").Skill;
|
|
10
|
+
export declare const architectureMacro: import("@compilr-dev/agents").Skill;
|
|
11
|
+
export declare const prdMacro: import("@compilr-dev/agents").Skill;
|
|
12
|
+
export declare const sessionNotesMacro: import("@compilr-dev/agents").Skill;
|
|
13
|
+
export declare const buildMacro: import("@compilr-dev/agents").Skill;
|
|
14
|
+
export declare const scaffoldMacro: import("@compilr-dev/agents").Skill;
|