@compilr-dev/sdk 0.26.0 → 0.28.0

package/dist/skills/macro-invocation.d.ts

@@ -0,0 +1,78 @@
+/**
+ * What a host actually SENDS when a user invokes a macro.
+ *
+ * ⚠️ THE TWO HOSTS SENT DIFFERENT THINGS FOR THE SAME COMMAND. The CLI wrapped each of these
+ * macros in project context — do not scan the filesystem, the cwd is not the project, save work
+ * items with `workitem_add` and documents with `project_document_add` rather than writing files —
+ * while Desktop sent the prompt alone. Same names, same macros, materially different
+ * instructions, so the same request produced an agent that interviewed you and filled the backlog
+ * in one host and an agent that went looking for source files in the other.
+ *
+ * The prompts were always shared data; what surrounded them was not. It is now.
+ *
+ * ⚠️ THE TEXT IS TRANSCRIBED, NOT REWRITTEN. Every block below was generated from the CLI's own
+ * template and asserted byte-identical to what it sent before the move, because a single reworded
+ * line here is a silent behaviour change in both hosts at once.
+ *
+ * This composes the MESSAGE only. The tool-gap preamble (`macroToolGap`) stays a separate,
+ * host-applied prepend: it depends on which AGENT is addressed, which only the host knows.
+ */
+/** What the host knows about the project a macro is invoked against. */
+export interface MacroProjectContext {
+    id: string | number;
+    name: string;
+    /** Absolute path on disk. `build` and `scaffold` write files and need it. */
+    path?: string;
+}
+/** A backlog item, for `build`. */
+export interface MacroWorkItem {
+    itemId: string;
+    type: string;
+    priority: string;
+    title: string;
+    description?: string;
+}
+export interface MacroInvocationContext {
+    /** Absent when no project is selected; the context block is then omitted entirely. */
+    project?: MacroProjectContext;
+    /** `prd` — the section the user named, if any. */
+    section?: string;
+    /** `session-notes` — the title the user gave, if any. */
+    noteTitle?: string;
+    /** `architecture` — the document type chosen, and how to name it back to the user. */
+    architecture?: {
+        docType: string;
+        displayType?: string;
+    };
+    /** `refine` — the item id, when refining one item rather than the whole backlog. */
+    refineItemId?: string;
+    /** `build` — the item to implement. Without it there is nothing to build. */
+    workItem?: MacroWorkItem;
+    /**
+     * `scaffold` — `factoryContext` is a pre-rendered block the host supplies because only it
+     * knows the Application Model's state; `isFactory` picks the closing instruction.
+     */
+    scaffold?: {
+        factoryContext?: string;
+        isFactory?: boolean;
+    };
+}
+export interface MacroInvocation {
+    /** The text to send to the agent. */
+    message: string;
+    /** The short line to show the user in place of the full message. */
+    displayMessage: string;
+}
+/**
+ * Compose the message for a macro invocation.
+ *
+ * A macro with no wrapper sends its prompt unchanged — the common case, and the default, so
+ * adding a macro needs no edit here. A macro WITH a wrapper falls back to the bare prompt when
+ * the host cannot supply what the wrapper names: better a plain prompt than one asserting a
+ * project, an item or a path that is not there.
+ *
+ * @param macroName the macro being invoked, e.g. `design`
+ * @param prompt    the macro's resolved prompt text
+ * @param ctx       what the host knows
+ */
+export declare function buildMacroInvocation(macroName: string, prompt: string, ctx?: MacroInvocationContext): MacroInvocation;

package/dist/skills/macro-invocation.js

@@ -0,0 +1,286 @@
+/**
+ * What a host actually SENDS when a user invokes a macro.
+ *
+ * ⚠️ THE TWO HOSTS SENT DIFFERENT THINGS FOR THE SAME COMMAND. The CLI wrapped each of these
+ * macros in project context — do not scan the filesystem, the cwd is not the project, save work
+ * items with `workitem_add` and documents with `project_document_add` rather than writing files —
+ * while Desktop sent the prompt alone. Same names, same macros, materially different
+ * instructions, so the same request produced an agent that interviewed you and filled the backlog
+ * in one host and an agent that went looking for source files in the other.
+ *
+ * The prompts were always shared data; what surrounded them was not. It is now.
+ *
+ * ⚠️ THE TEXT IS TRANSCRIBED, NOT REWRITTEN. Every block below was generated from the CLI's own
+ * template and asserted byte-identical to what it sent before the move, because a single reworded
+ * line here is a silent behaviour change in both hosts at once.
+ *
+ * This composes the MESSAGE only. The tool-gap preamble (`macroToolGap`) stays a separate,
+ * host-applied prepend: it depends on which AGENT is addressed, which only the host knows.
+ */
+function designContext(project) {
+    return `I want to design my project and create the backlog.
+
+## PROJECT CONTEXT (IMPORTANT)
+- Project Name: ${project.name} (ID: ${String(project.id)})
+- This is a NEW project being designed from scratch
+- Do NOT scan the filesystem - the current directory is NOT the project
+- Do NOT use detect_project, glob, read_file, or ls tools
+- Focus ONLY on gathering requirements via ask_user questions
+
+## DOCUMENT STORAGE (CRITICAL)
+Save all documents and backlog items using the database - do NOT write files directly.
+- For backlog items: \`workitem_add({ type: "feature", title: "...", description: "...", priority: "high" })\`
+- For documents: \`project_document_add({ doc_type: "prd", title: "...", content: "..." })\`
+- The database is the source of truth for all project documents
+- Do NOT use write_file or edit tools for documentation
+`;
+}
+const DESIGN_CLOSER = 'Please start by using todo_write to track the design phases, then begin with Phase 1: Vision. ' +
+    'Use the ask_user tool to gather information efficiently.';
+function sketchMessage(p, prompt) {
+    return `I want to quickly outline my project.
+
+## PROJECT CONTEXT (IMPORTANT)
+- Project Name: ${p.name} (ID: ${String(p.id)})
+- This is a NEW project being designed from scratch
+- Do NOT scan the filesystem - the current directory is NOT the project
+- Do NOT use detect_project, glob, read_file, or ls tools
+- Focus ONLY on gathering requirements via ask_user questions
+
+## DOCUMENT STORAGE (CRITICAL)
+Save all documents and backlog items using the database - do NOT write files directly.
+- For backlog items: \`workitem_add({ type: "feature", title: "...", description: "..." })\`
+- For documents: \`project_document_add({ doc_type: "prd", title: "...", content: "..." })\`
+- Do NOT use write_file or edit tools for documentation
+
+${prompt}
+
+Please start by asking me about the type of application I'm building using the ask_user_simple tool.`;
+}
+function refineMessage(p, prompt, userIntent, agentInstructions) {
+    return `${userIntent}
+
+## PROJECT CONTEXT (IMPORTANT)
+- Project Name: ${p.name} (ID: ${String(p.id)})
+- Do NOT scan the filesystem - the current directory is NOT the project
+- Do NOT use detect_project, glob, read_file, or ls tools
+- Use ONLY database tools to access project data
+
+## DOCUMENT STORAGE (CRITICAL)
+Use database tools for all updates - do NOT write files directly.
+- Use \`workitem_query\` to read items
+- Use \`workitem_update\` to modify items
+- Do NOT use write_file or edit tools
+
+${prompt}
+
+${agentInstructions}`;
+}
+function buildMessage(p, prompt, item) {
+    return `I want to implement backlog item ${item.itemId}: "${item.title}".
+
+## PROJECT CONTEXT (CRITICAL)
+- Project Name: ${p.name} (ID: ${String(p.id)})
+- **Project Directory: ${p.path ?? ''}**
+- ALL files MUST be created/modified in this directory
+
+## WORK ITEM DETAILS
+- Item ID: ${item.itemId}
+- Type: ${item.type}
+- Priority: ${item.priority}
+- Description: ${item.description ?? 'No description provided'}
+
+## TOOL RESTRICTIONS (CRITICAL)
+- Do NOT use detect_project or find_project_root
+- Do NOT scan filesystem to detect project type
+- The project path above is the ONLY source of truth for where to create/modify files
+- Use \`project_document_get\` to read PRD and architecture docs from the database
+- Use \`workitem_query\` to read related backlog items from the database
+- Use \`workitem_update\` to update the item status when done
+
+## FILE OPERATIONS (CRITICAL)
+When creating or modifying files:
+- Use absolute paths starting with: ${p.path ?? ''}/
+- Example: write_file({ path: "${p.path ?? ''}/src/index.ts", ... })
+- NEVER use relative paths
+- IGNORE the current working directory (cwd) - it may be different from the project!
+- The user may have started the CLI from a different folder
+
+${prompt}
+
+Please start by:
+1. Using todo_write to plan the implementation steps
+2. Reading project documents from the database (project_document_list, project_document_get)
+3. Updating the work item status to 'in_progress' using workitem_update
+4. Implementing the feature
+5. Updating the work item status to 'completed' when done`;
+}
+function sessionNotesMessage(p, prompt, titleInstruction) {
+    return `I want to create a session note capturing what we've done.
+
+## PROJECT CONTEXT
+- Project Name: ${p.name} (ID: ${String(p.id)})
+
+## DOCUMENT STORAGE (CRITICAL)
+Save session notes using the database - do NOT write files directly.
+- Tool: \`project_document_add({ doc_type: "session-note", title: "...", content: "..." })\`
+- The database is the source of truth for all project documents
+- Do NOT use write_file or edit tools for documentation
+
+${prompt}
+
+${titleInstruction}
+
+Review the conversation context to understand what was accomplished, then create the session note.`;
+}
+function prdMessage(p, prompt, sectionInstruction) {
+    return `I want to update the Product Requirements Document.
+
+## DOCUMENT STORAGE (CRITICAL)
+Save PRD updates using the database - do NOT write files directly.
+- Project: ${p.name} (ID: ${String(p.id)})
+- Tool: \`project_document_add({ doc_type: "prd", title: "Product Requirements Document", content: "..." })\`
+- The database is the source of truth for all project documents
+- Do NOT use write_file or edit tools for documentation
+
+${prompt}
+
+${sectionInstruction}
+
+Start by reading the existing PRD from the database using project_document_get({ doc_type: "prd" }). If no document exists yet, create a new one.`;
+}
+function architectureMessage(p, prompt, arch) {
+    return `I want to create architecture documentation.
+
+## DOCUMENT STORAGE (CRITICAL)
+Save architecture documentation using the database - do NOT write files directly.
+- Project: ${p.name} (ID: ${String(p.id)})
+- Tool: \`project_document_add({ doc_type: "architecture", title: "...", content: "..." })\`
+- The database is the source of truth for all project documents
+- Do NOT use write_file or edit tools for documentation
+
+${prompt}
+
+Please start by using project_document_list to find any existing PRD, and workitem_query to understand the project backlog. Then use ask_user to gather the information needed for this ${arch.docType} document.`;
+}
+function scaffoldMessage(p, prompt, factoryContext, closingInstruction) {
+    return `I want to create the project scaffold/foundation.
+
+## PROJECT CONTEXT (CRITICAL)
+- Project Name: ${p.name} (ID: ${String(p.id)})
+- **Project Directory: ${p.path ?? ''}**
+- ALL files MUST be created in this directory
+${factoryContext}
+## TOOL RESTRICTIONS (CRITICAL)
+- Do NOT use detect_project or find_project_root
+- Do NOT scan filesystem to detect project type
+- The project path above is the ONLY source of truth for where to create files
+- Use \`project_document_get\` to read PRD and architecture docs from the database
+- Use \`workitem_query\` to read backlog items from the database
+
+## FILE CREATION (CRITICAL)
+When creating files:
+- Use absolute paths starting with: ${p.path ?? ''}/
+- Example: write_file({ path: "${p.path ?? ''}/package.json", ... })
+- NEVER use relative paths
+- IGNORE the current working directory (cwd) - it may be different from the project!
+- The user may have started the CLI from a different folder
+
+${prompt}
+
+${closingInstruction}`;
+}
+/**
+ * Compose the message for a macro invocation.
+ *
+ * A macro with no wrapper sends its prompt unchanged — the common case, and the default, so
+ * adding a macro needs no edit here. A macro WITH a wrapper falls back to the bare prompt when
+ * the host cannot supply what the wrapper names: better a plain prompt than one asserting a
+ * project, an item or a path that is not there.
+ *
+ * @param macroName the macro being invoked, e.g. `design`
+ * @param prompt    the macro's resolved prompt text
+ * @param ctx       what the host knows
+ */
+export function buildMacroInvocation(macroName, prompt, ctx = {}) {
+    const p = ctx.project;
+    if (!p)
+        return { message: prompt, displayMessage: `/${macroName}` };
+    switch (macroName) {
+        case 'design':
+            return {
+                message: `${designContext(p)}\n${prompt}\n\n${DESIGN_CLOSER}`,
+                displayMessage: 'Start the design process for my project.',
+            };
+        case 'sketch':
+            return { message: sketchMessage(p, prompt), displayMessage: 'Quick project outline.' };
+        case 'refine':
+        case 'refine-item': {
+            // Bound to a local so the narrowing survives into the template literals.
+            const itemId = ctx.refineItemId;
+            const userIntent = itemId !== undefined
+                ? `I want to refine backlog item ${itemId}.`
+                : 'I want to refine my project requirements.';
+            const agentInstructions = itemId !== undefined
+                ? `Please use workitem_query to find item "${itemId}", then guide me through refining it using workitem_update.`
+                : "Please start by using workitem_query with limit:10 to get an overview, then ask me what I'd like to focus on using ask_user_simple.";
+            return {
+                message: refineMessage(p, prompt, userIntent, agentInstructions),
+                displayMessage: userIntent,
+            };
+        }
+        case 'build': {
+            // Nothing to build without an item, and the whole wrapper is about one.
+            if (!ctx.workItem)
+                return { message: prompt, displayMessage: `/${macroName}` };
+            return {
+                message: buildMessage(p, prompt, ctx.workItem),
+                displayMessage: `Build ${ctx.workItem.itemId}: ${ctx.workItem.title}`,
+            };
+        }
+        case 'session-notes': {
+            const titleInstruction = ctx.noteTitle
+                ? `The session title is: "${ctx.noteTitle}"`
+                : 'Please ask me for a title using ask_user_simple, or generate one from the session summary.';
+            return {
+                message: sessionNotesMessage(p, prompt, titleInstruction),
+                displayMessage: ctx.noteTitle
+                    ? `Create session note: "${ctx.noteTitle}"`
+                    : 'Create a session note for this session.',
+            };
+        }
+        case 'prd': {
+            const valid = ['vision', 'scope', 'technical', 'success'];
+            const section = ctx.section ?? '';
+            const sectionInstruction = valid.includes(section)
+                ? `The user wants to update the "${section}" section specifically.`
+                : 'Ask the user which section they want to update using ask_user_simple.';
+            return {
+                message: prdMessage(p, prompt, sectionInstruction),
+                displayMessage: section
+                    ? `Update PRD: ${section} section`
+                    : 'Update the Product Requirements Document',
+            };
+        }
+        case 'architecture': {
+            if (!ctx.architecture)
+                return { message: prompt, displayMessage: `/${macroName}` };
+            return {
+                message: architectureMessage(p, prompt, ctx.architecture),
+                displayMessage: `Create ${ctx.architecture.displayType ?? ctx.architecture.docType} documentation.`,
+            };
+        }
+        case 'scaffold':
+        case 'factory-scaffold': {
+            const closingInstruction = macroName === 'factory-scaffold' || ctx.scaffold?.isFactory
+                ? 'Start by checking the Application Model with app_model_get. If no model exists, read the PRD with project_document_get and build the model incrementally using app_model_update. Then generate with factory_scaffold.'
+                : 'Start by reading the project documents from the database using project_document_list and project_document_get. Then create a plan with todo_write before generating files.';
+            return {
+                message: scaffoldMessage(p, prompt, ctx.scaffold?.factoryContext ?? '', closingInstruction),
+                displayMessage: 'Create project scaffold.',
+            };
+        }
+        default:
+            return { message: prompt, displayMessage: `/${macroName}` };
+    }
+}

package/dist/skills/macro-list.d.ts

@@ -0,0 +1,54 @@
+/**
+ * The list of macros a host presents — built once, here, for both hosts.
+ *
+ * ⚠️ THIS LIVED IN DESKTOP, AND THE CLI SIMPLY DID WITHOUT. Desktop decided what each entry was
+ * called, which category it belonged to and which ones came first; the terminal listed raw names
+ * in resolver order. That is not a presentation difference, it is the same question answered in
+ * one place and not asked in the other — so the two disagreed about the name of every macro.
+ *
+ * What legitimately differs per host is capability: a terminal cannot render a canvas. That is a
+ * parameter (`capabilities`), so neither host re-decides anything else.
+ *
+ * Spec: project-docs/00-requirements/compilr-dev-sdk/macro-metadata-consolidation.md
+ */
+import { type SkillSources } from './prompt-resolver.js';
+import { type MacroCapabilities } from '../project-types/macro-relevance.js';
+import type { MacroCategory, MacroMeta } from '../project-types/types.js';
+/** One row in a slash menu, command palette or picker. */
+export interface MacroListEntry {
+    id: string;
+    label: string;
+    description: string;
+    category: MacroCategory;
+    icon: string;
+}
+export interface BuildMacroListOptions {
+    /** Project directory, for project-scoped skills and bindings. */
+    projectPath?: string;
+    /** Project type id. Absent means no relevance ordering is applied. */
+    projectType?: string;
+    /** Extra prompt sources the host injects (factory, agents-coding). */
+    sources?: SkillSources;
+    /**
+     * Metadata for macros the SDK does not ship and therefore cannot describe.
+     *
+     * The SDK is the source of truth for ITS macros; a package that injects its own prompts is
+     * the source of truth for those. `factorySkills` is the case in point — factory depends on
+     * the SDK, not the reverse, so no registry here could ever cover it, and `factory-scaffold`
+     * rendered as a raw id. Supplying it through this channel keeps the hole visible and owned
+     * rather than hardcoded somewhere.
+     *
+     * Properly, each such package should export this alongside its prompts; until then the host
+     * that injects the source supplies it and asserts its own coverage.
+     */
+    extraMeta?: Record<string, Omit<MacroMeta, 'id'>>;
+    /** What this host can render. */
+    capabilities?: MacroCapabilities;
+}
+/**
+ * Everything typeable after a slash, labelled, and ordered by relevance to the project type.
+ *
+ * Disabled entries are filtered out — an entry offered and then refused as "Unknown command" is
+ * worse than one never offered.
+ */
+export declare function buildMacroList(options?: BuildMacroListOptions): MacroListEntry[];

package/dist/skills/macro-list.js

@@ -0,0 +1,84 @@
+/**
+ * The list of macros a host presents — built once, here, for both hosts.
+ *
+ * ⚠️ THIS LIVED IN DESKTOP, AND THE CLI SIMPLY DID WITHOUT. Desktop decided what each entry was
+ * called, which category it belonged to and which ones came first; the terminal listed raw names
+ * in resolver order. That is not a presentation difference, it is the same question answered in
+ * one place and not asked in the other — so the two disagreed about the name of every macro.
+ *
+ * What legitimately differs per host is capability: a terminal cannot render a canvas. That is a
+ * parameter (`capabilities`), so neither host re-decides anything else.
+ *
+ * Spec: project-docs/00-requirements/compilr-dev-sdk/macro-metadata-consolidation.md
+ */
+import { getAllAvailableSkills } from './prompt-resolver.js';
+import { MACRO_META_REGISTRY } from '../project-types/macro-meta.js';
+import { getRelevantMacros } from '../project-types/macro-relevance.js';
+import { platformMacros } from './platform-macros.js';
+/** Derived from the tag, never a name list — a stale name list is how `canvas-styles` leaked. */
+function isCanvasMacro(name) {
+    return platformMacros.some((m) => m.name === name && (m.tags ?? []).includes('canvas'));
+}
+/**
+ * Everything typeable after a slash, labelled, and ordered by relevance to the project type.
+ *
+ * Disabled entries are filtered out — an entry offered and then refused as "Unknown command" is
+ * worse than one never offered.
+ */
+export function buildMacroList(options = {}) {
+    const { projectPath, projectType, sources, capabilities, extraMeta } = options;
+    const entries = getAllAvailableSkills(projectPath, sources)
+        .filter((entry) => entry.enabled !== false)
+        // A host that cannot render a canvas must not be OFFERED one. Only ours are withheld: a
+        // user's own SKILL.md that happens to be called `canvas` is theirs and still works, which
+        // is the same line the CLI's resolver already draws.
+        .filter((entry) => !(capabilities?.canvas === false && entry.source === 'sdk' && isCanvasMacro(entry.name)))
+        .map((entry) => {
+        // A bound command is named for the binding, not for what it resolves to.
+        if (entry.source === 'binding') {
+            return {
+                id: entry.name,
+                label: `/${entry.name}`,
+                description: entry.description,
+                category: 'development',
+                icon: 'link',
+            };
+        }
+        // A user's or project's own SKILL.md. Its scope is part of how it reads, because two of
+        // them can share a name and the project's wins.
+        if (entry.scope) {
+            return {
+                id: entry.name,
+                label: `/${entry.name}`,
+                description: `[${entry.scope}] ${entry.description}`,
+                category: 'development',
+                icon: 'wand',
+            };
+        }
+        // Something we ship. The fallbacks below are a hole, not a feature — they are what made
+        // twenty macros render as `business-vision`, `market-analysis`, … and they are kept
+        // unreachable by tests/skills/macro-meta-coverage.test.ts.
+        const meta = (entry.name in MACRO_META_REGISTRY ? MACRO_META_REGISTRY[entry.name] : undefined) ??
+            extraMeta?.[entry.name];
+        return {
+            id: entry.name,
+            label: meta?.label ?? entry.name,
+            description: entry.description,
+            category: meta?.category ?? 'development',
+            icon: meta?.icon ?? 'Zap',
+        };
+    });
+    const relevant = getRelevantMacros(projectType, capabilities);
+    if (relevant.length === 0)
+        return entries;
+    // Promoted entries come back in RELEVANCE order — a business plan leads with its business
+    // macros — rather than in whatever order the resolver happened to return them. Everything
+    // else keeps its original order behind them.
+    const rank = new Map(relevant.map((id, i) => [id, i]));
+    const rankOf = (id) => rank.get(id) ?? Number.MAX_SAFE_INTEGER;
+    const promoted = entries
+        .filter((e) => rank.has(e.id))
+        .sort((a, b) => rankOf(a.id) - rankOf(b.id));
+    const rest = entries.filter((e) => !rank.has(e.id));
+    return [...promoted, ...rest];
+}

package/dist/skills/operations.js

@@ -7,8 +7,8 @@
  * - Validation (quality checks beyond parseSkillMarkdown)
  * - Binding resolution (config.json slash command remapping)
  */
-import { RESERVED_SKILL_NAMES } from './types.js';
-import { platformSkills } from './platform-skills.js';
+import { RESERVED_MACRO_NAMES } from './types.js';
+import { platformMacros } from './platform-macros.js';
 /**
  * Detect user/project skills that shadow SDK reserved names.
  * Called at startup to warn users about collisions introduced by SDK updates.
@@ -18,7 +18,7 @@ import { platformSkills } from './platform-skills.js';
  * already has a skill with that name.
  */
 export function detectCollisions(userSkills) {
-    const reserved = new Set(RESERVED_SKILL_NAMES);
+    const reserved = new Set(RESERVED_MACRO_NAMES);
     const collisions = [];
     for (const skill of userSkills) {
         if (reserved.has(skill.name)) {
@@ -54,7 +54,7 @@ export function formatCollisionWarnings(collisions) {
 export function diffForkVsUpstream(forkPrompt, upstreamSkillName) {
     // Find the upstream SDK skill
     // Check all platform skills + builtins
-    const allSdk = [...platformSkills];
+    const allSdk = [...platformMacros];
     const upstream = allSdk.find((s) => s.name === upstreamSkillName);
     if (!upstream)
         return null;

package/dist/skills/platform-macros.d.ts

@@ -0,0 +1,27 @@
+/**
+ * Platform Macros — Aggregate
+ *
+ * The prompts we ship. A macro is a named prompt the USER invokes (`/design`, `/prd`); it
+ * expands into a message. That is not what a SKILL is — a skill is a capability the MODEL
+ * chooses from a catalogue, installed as `SKILL.md` and loaded on demand. These 42 are macros
+ * and have always been; they were named "skills" before the two were told apart.
+ *
+ * They are still built with `defineSkill()` from @compilr-dev/agents, deliberately: that is the
+ * shared primitive for "a named prompt with a description", and installed skills extend the same
+ * shape. The primitive is not being renamed — the population is.
+ *
+ * Per-domain files: software-macros.ts, research-macros.ts, business-macros.ts, content-macros.ts,
+ * course-macros.ts, book-macros.ts, canvas-macros.ts (+ canvas-exemplars.ts, canvas-icons.ts).
+ */
+import type { Skill } from '@compilr-dev/agents';
+export { designMacro, sketchMacro, prdMacro, refineMacro, refineItemMacro, architectureMacro, sessionNotesMacro, buildMacro, scaffoldMacro, } from './software-macros.js';
+export { outlineMacro, literatureReviewMacro, draftSectionMacro, peerReviewMacro, researchScaffoldMacro, } from './research-macros.js';
+export { businessVisionMacro, marketAnalysisMacro, competitorAnalysisMacro, financialModelMacro, pitchOutlineMacro, businessReviewMacro, } from './business-macros.js';
+export { brandSetupMacro, contentStrategyMacro, contentCalendarMacro, createContentMacro, contentReviewMacro, } from './content-macros.js';
+export { curriculumDesignMacro, lessonPlanMacro, assessmentDesignMacro, courseReviewMacro, } from './course-macros.js';
+export { bookOutlineMacro, characterDesignMacro, plotThreadsMacro, sceneBreakdownMacro, bookReviewMacro, } from './book-macros.js';
+export { canvasMacro, infographicMacro, carouselMacro, boardMacro, canvasStylesMacro, } from './canvas-macros.js';
+export { canvasExemplarInfographicMacro, canvasExemplarAppScreenMacro, } from './canvas-exemplars.js';
+export { canvasIconsMacro } from './canvas-icons.js';
+/** Every macro we ship. Count is asserted in tests/skills/platform-macros.test.ts. */
+export declare const platformMacros: Skill[];

package/dist/skills/platform-macros.js

@@ -0,0 +1,94 @@
+/**
+ * Platform Macros — Aggregate
+ *
+ * The prompts we ship. A macro is a named prompt the USER invokes (`/design`, `/prd`); it
+ * expands into a message. That is not what a SKILL is — a skill is a capability the MODEL
+ * chooses from a catalogue, installed as `SKILL.md` and loaded on demand. These 42 are macros
+ * and have always been; they were named "skills" before the two were told apart.
+ *
+ * They are still built with `defineSkill()` from @compilr-dev/agents, deliberately: that is the
+ * shared primitive for "a named prompt with a description", and installed skills extend the same
+ * shape. The primitive is not being renamed — the population is.
+ *
+ * Per-domain files: software-macros.ts, research-macros.ts, business-macros.ts, content-macros.ts,
+ * course-macros.ts, book-macros.ts, canvas-macros.ts (+ canvas-exemplars.ts, canvas-icons.ts).
+ */
+// Software Development
+export { designMacro, sketchMacro, prdMacro, refineMacro, refineItemMacro, architectureMacro, sessionNotesMacro, buildMacro, scaffoldMacro, } from './software-macros.js';
+// Research Paper
+export { outlineMacro, literatureReviewMacro, draftSectionMacro, peerReviewMacro, researchScaffoldMacro, } from './research-macros.js';
+// Business Plan
+export { businessVisionMacro, marketAnalysisMacro, competitorAnalysisMacro, financialModelMacro, pitchOutlineMacro, businessReviewMacro, } from './business-macros.js';
+// Content & Marketing
+export { brandSetupMacro, contentStrategyMacro, contentCalendarMacro, createContentMacro, contentReviewMacro, } from './content-macros.js';
+// Course / Training
+export { curriculumDesignMacro, lessonPlanMacro, assessmentDesignMacro, courseReviewMacro, } from './course-macros.js';
+// Book
+export { bookOutlineMacro, characterDesignMacro, plotThreadsMacro, sceneBreakdownMacro, bookReviewMacro, } from './book-macros.js';
+// Canvas (visual)
+export { canvasMacro, infographicMacro, carouselMacro, boardMacro, canvasStylesMacro, } from './canvas-macros.js';
+// Canvas exemplars — generated from the design handoff; see canvas-exemplars.ts.
+export { canvasExemplarInfographicMacro, canvasExemplarAppScreenMacro, } from './canvas-exemplars.js';
+export { canvasIconsMacro } from './canvas-icons.js';
+// Import all for the aggregate array
+import { designMacro, sketchMacro, prdMacro, refineMacro, refineItemMacro, architectureMacro, sessionNotesMacro, buildMacro, scaffoldMacro, } from './software-macros.js';
+import { outlineMacro, literatureReviewMacro, draftSectionMacro, peerReviewMacro, researchScaffoldMacro, } from './research-macros.js';
+import { businessVisionMacro, marketAnalysisMacro, competitorAnalysisMacro, financialModelMacro, pitchOutlineMacro, businessReviewMacro, } from './business-macros.js';
+import { brandSetupMacro, contentStrategyMacro, contentCalendarMacro, createContentMacro, contentReviewMacro, } from './content-macros.js';
+import { curriculumDesignMacro, lessonPlanMacro, assessmentDesignMacro, courseReviewMacro, } from './course-macros.js';
+import { bookOutlineMacro, characterDesignMacro, plotThreadsMacro, sceneBreakdownMacro, bookReviewMacro, } from './book-macros.js';
+import { canvasMacro, infographicMacro, carouselMacro, boardMacro, canvasStylesMacro, } from './canvas-macros.js';
+import { canvasExemplarInfographicMacro, canvasExemplarAppScreenMacro, } from './canvas-exemplars.js';
+import { canvasIconsMacro } from './canvas-icons.js';
+/** Every macro we ship. Count is asserted in tests/skills/platform-macros.test.ts. */
+export const platformMacros = [
+    // Software (9)
+    designMacro,
+    sketchMacro,
+    prdMacro,
+    refineMacro,
+    refineItemMacro,
+    architectureMacro,
+    sessionNotesMacro,
+    buildMacro,
+    scaffoldMacro,
+    // Research (5)
+    outlineMacro,
+    literatureReviewMacro,
+    draftSectionMacro,
+    peerReviewMacro,
+    researchScaffoldMacro,
+    // Business (6)
+    businessVisionMacro,
+    marketAnalysisMacro,
+    competitorAnalysisMacro,
+    financialModelMacro,
+    pitchOutlineMacro,
+    businessReviewMacro,
+    // Content (5)
+    brandSetupMacro,
+    contentStrategyMacro,
+    contentCalendarMacro,
+    createContentMacro,
+    contentReviewMacro,
+    // Course (4)
+    curriculumDesignMacro,
+    lessonPlanMacro,
+    assessmentDesignMacro,
+    courseReviewMacro,
+    // Book (5)
+    bookOutlineMacro,
+    characterDesignMacro,
+    plotThreadsMacro,
+    sceneBreakdownMacro,
+    bookReviewMacro,
+    // Canvas (4)
+    canvasMacro,
+    infographicMacro,
+    carouselMacro,
+    boardMacro,
+    canvasStylesMacro,
+    canvasExemplarInfographicMacro,
+    canvasExemplarAppScreenMacro,
+    canvasIconsMacro,
+];