@juancr11/sibu 0.13.1 → 0.14.0

package/templates/manifest.json

@@ -1,11 +1,11 @@
 {
-  "templateVersion": "97",
+  "templateVersion": "103",
   "templates": {
     "AGENTS.md": {
-      "version": "29",
+      "version": "30",
       "description": "Project-level agent instructions and Sibu maintenance guidance.",
       "changes": [
-        "Can render Layered Architecture routing when that architecture option is selected."
+        "Routes rough future idea capture requests to the mandatory feature-idea-capture skill."
       ]
     },
     ".codex/config.toml": {
@@ -65,17 +65,17 @@
       ]
     },
     "skills/feature-brief-writer/SKILL.md": {
-      "version": "10",
+      "version": "13",
       "description": "Mandatory feature brief writer skill installed once at the shared .agents/skills workspace path.",
       "changes": [
-        "Adds optional Notion export guidance after local feature briefs are written while keeping Markdown as the canonical artifact."
+        "Keeps feature brief writing focused on local Markdown artifacts and moves Notion export workflow guidance to dedicated exporter skills."
       ]
     },
     "skills/technical-design-writer/SKILL.md": {
-      "version": "18",
+      "version": "19",
       "description": "Mandatory technical design writer skill installed once at the shared .agents/skills workspace path.",
       "changes": [
-        "Strengthens technical design interviews to resolve material implementation questions before drafting and replaces open questions with risks/tradeoffs."
+        "Keeps technical design writing focused on local Markdown artifacts and moves Notion export workflow guidance to dedicated exporter skills."
       ]
     },
     "skills/typescript/SKILL.md": {
@@ -121,17 +121,17 @@
       ]
     },
     "skills/react/SKILL.md": {
-      "version": "2",
+      "version": "3",
       "description": "Selectable React skill for component design, props, state ownership, and presentational boundaries.",
       "changes": [
-        "Strengthens React component guidance around Single Responsibility Principle splits, stateless versus stateful boundaries, and one component per file by default."
+        "Adds broadly applicable React screen componentization guidance so route and feature entry files stay thin while meaningful UI regions move into focused nearby files."
       ]
     },
     "skills/scrum-master-planner/SKILL.md": {
-      "version": "11",
+      "version": "12",
       "description": "Mandatory Scrum planner skill for creating pragmatic Epics and User Stories from approved feature and technical design docs.",
       "changes": [
-        "Clarifies that User Stories should be deployable increments that can be merged safely on their own, even when gated or incomplete until the parent Epic is done."
+        "Keeps Scrum planning focused on local Epic and User Story artifacts and moves GitHub export workflow guidance to dedicated exporter skills."
       ]
     },
     "skills/ai-implementation-planner/SKILL.md": {
@@ -148,6 +148,13 @@
         "Clarifies that story and Epic planning requests are confirmation for executor implementation."
       ]
     },
+    "skills/feature-idea-capture/SKILL.md": {
+      "version": "1",
+      "description": "Mandatory feature idea capture skill for storing rough future ideas in docs/feature-ideas.md only when the skill is used.",
+      "changes": [
+        "Adds a mandatory feature idea capture skill for quick, raw idea storage without backlog or planning ceremony."
+      ]
+    },
     "skills/ai-prompt-engineer-master/SKILL.md": {
       "version": "2",
       "description": "Selectable AI prompt engineering skill for prompt creation, optimization, compression, and evaluation.",
@@ -156,10 +163,10 @@
       ]
     },
     "skills/ux-expert/SKILL.md": {
-      "version": "8",
+      "version": "9",
       "description": "Selectable UX expert skill for UI-changing features, responsive design, flows, states, accessibility, and binding mockups.",
       "changes": [
-        "Strengthens UX interviews to resolve material experience questions before drafting and replaces open UX questions with risks/tradeoffs."
+        "Keeps UX design writing focused on local Markdown artifacts and moves Notion export workflow guidance to dedicated exporter skills."
       ]
     },
     "skills/architecture/layered-architecture/SKILL.md": {
@@ -168,6 +175,20 @@
       "changes": [
         "Adds a Layered Architecture skill for smaller apps that need simple separation of concerns."
       ]
+    },
+    "skills/export-to-github/SKILL.md": {
+      "version": "1",
+      "description": "Selectable GitHub export skill for publishing a named feature's Epics and User Stories to GitHub issues and native sub-issues.",
+      "changes": [
+        "Adds a dedicated GitHub exporter skill paired with GitHub MCP selection."
+      ]
+    },
+    "skills/export-to-notion/SKILL.md": {
+      "version": "1",
+      "description": "Selectable Notion export skill for publishing a named feature's core documentation files to Notion.",
+      "changes": [
+        "Adds a dedicated Notion exporter skill paired with Notion MCP selection."
+      ]
     }
   }
 }

package/templates/skills/export-to-github/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: export-to-github
+description: Export a named feature's Epics and User Stories from local Markdown to GitHub issues and native sub-issues using configured GitHub MCP capabilities.
+---
+
+# Export to GitHub
+
+Use this skill when the user asks to export a feature's Epics and User Stories to GitHub.
+
+## Required input
+
+- A feature name or feature slug.
+- Local planning artifacts under `docs/features/<feature-slug>/epics/`.
+- Configured GitHub MCP capabilities for issue creation, issue ID access, and native sub-issue mutation.
+
+If the feature name is ambiguous, inspect `docs/features/` and ask one focused clarification question.
+
+## Workflow
+
+1. Resolve the feature slug from the user's feature name.
+2. Read the feature's Epic briefs and User Story Markdown files under `docs/features/<feature-slug>/epics/**`.
+3. Resolve the target repository from the current local repo's GitHub `origin` remote only. Do not ask for or use another repository.
+4. Verify GitHub MCP can create issues, return issue IDs, and attach native sub-issues.
+5. Ask one explicit opt-in question before any GitHub mutation.
+6. If the user accepts, create a fresh issue set every time:
+   - one issue per Epic, with no labels
+   - one issue per User Story, with no labels
+   - each User Story issue attached as a native sub-issue of its parent Epic issue
+7. Report created issue numbers or URLs.
+
+## Export rules
+
+- Keep issue bodies concise and source-grounded.
+- Include the source local doc path and relevant summary, scope, acceptance criteria, or validation notes.
+- Preserve each created User Story issue's GitHub issue `id`; native sub-issue APIs need the child issue ID, not only its issue number.
+- Do not search for duplicates or update existing issues.
+- Do not use labels, milestones, projects, assignees, status tracking, Markdown checklists, or loose links as a substitute for native sub-issues.
+- Do not modify local Markdown files with GitHub URLs.
+- If issue creation, issue ID access, or native sub-issue attachment is unavailable, fail clearly and do not fall back to another structure.

package/templates/skills/export-to-notion/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: export-to-notion
+description: Export a named feature's local feature brief, UX design, and technical design Markdown files to Notion using configured Notion MCP capabilities.
+---
+
+# Export to Notion
+
+Use this skill when the user asks to export a feature's core documentation to Notion.
+
+## Required input
+
+- A feature name or feature slug.
+- Configured Notion MCP capabilities.
+- `.sibu/state.json` with `mcpServerConfigs.notion.docsParentPage` when available.
+
+If the feature name is ambiguous, inspect `docs/features/` and ask one focused clarification question.
+
+## Source files
+
+Export only these local Markdown files when present:
+
+```txt
+docs/features/<feature-slug>/feature_brief.md
+docs/features/<feature-slug>/ux.md
+docs/features/<feature-slug>/technical_design.md
+```
+
+Do not export Epics, User Stories, implementation plans, product vision, Deep Module Maps, or arbitrary docs with this skill.
+
+## Notion destination
+
+Use this organization under the configured Notion docs parent page:
+
+```txt
+<docsParentPage>
+└── <repo name>
+    └── Features
+        └── <feature name>
+            ├── Feature Brief
+            ├── UX Design
+            └── Technical Design
+```
+
+## Workflow
+
+1. Resolve the feature slug from the user's feature name.
+2. Read `.sibu/state.json` when available and use `mcpServerConfigs.notion.docsParentPage` as the destination parent.
+3. Confirm which of the allowed source files exist.
+4. Ask one explicit opt-in question before creating or modifying Notion pages.
+5. Create or reuse the repo, Features, and feature organization pages under the configured parent.
+6. Export each existing allowed artifact to its matching Notion page.
+7. Report export success or failure per artifact.
+
+## Export rules
+
+- Local Markdown remains canonical.
+- Do not write Notion URLs back into local Markdown.
+- Do not invent missing source artifacts.
+- Do not export files outside the allowed source list.
+- If Notion MCP capabilities or destination configuration are unavailable, fail clearly and explain what is missing.

package/templates/skills/feature-brief-writer/SKILL.md

@@ -95,6 +95,17 @@ Use a short kebab-case feature slug that matches the feature name. Keep all arti
 
 Do not write the brief to technical design, UX, user story, implementation plan, or backlog files unless the user explicitly asks for a separate artifact after the feature brief exists.
 
+## Raw idea sources
+
+If the user asks for a feature brief from an idea in `docs/feature-ideas.md`, read the relevant idea and treat it as raw/vague input only.
+
+- Do not skip the normal interview flow because the idea exists in a file.
+- Use the idea as a seed for the first discovery question, not as complete feature intent.
+- Keep asking one focused question at a time until the usual required context is resolved: problem, target user/scenario, business goal, MVP boundary, out-of-scope boundary, success signals, constraints, and Deep Module fit.
+- Preserve the hard-start requirements for `docs/product-vision.md` and `docs/deep-module-map.md`.
+- After the local `docs/features/<feature-slug>/feature_brief.md` file is successfully written, remove the promoted idea from `docs/feature-ideas.md` while preserving the rest of the file.
+- Do not delete the idea before the feature brief file exists, and do not remove unrelated ideas or headings.
+
 ## Interview posture
 
 Be deliberately interrogative before drafting. The feature brief should reflect the user's intent, not the assistant's assumptions.
@@ -283,31 +294,6 @@ When shaping a feature brief, prefer:
 7. measurable success signals
 8. non-technical acceptance criteria
 
-## Optional Notion export after local write
-
-After the local Markdown file is written successfully, optionally offer Notion export. Local Markdown remains the canonical pipeline artifact and Notion is only a convenience export destination.
-
-1. Do not check Notion export before the local file exists.
-2. After writing the local file, read `.sibu/state.json` if available.
-3. Offer export only when all are true:
-   - `selectedMcpServers` includes `notion`
-   - `mcpServerConfigs.notion.docsParentPage` is present
-   - Notion MCP tools are available in the current agent session
-4. If export is unavailable, do nothing else and finish with the normal local path response.
-5. If export is available, ask for explicit opt-in before creating or modifying any Notion page.
-6. If the user declines, do nothing else.
-7. If the user accepts, create or reuse Notion organization pages under the configured parent page:
-
-```txt
-<docsParentPage>
-└── <repo name>
-    └── Features
-        └── <feature name>
-            └── Feature Brief
-```
-
-Create a new document page for the just-written artifact content. Do not write Notion URLs back into local Markdown. Report Notion export success or a clear Notion export failure, while preserving the local file as the completed artifact either way.
-
 ## Final response behavior
 
 After writing the file, final-answer with only the path created or updated. Do not paste the feature brief body, excerpt, outline, or section summaries.

package/templates/skills/feature-idea-capture/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: feature-idea-capture
+description: Use when the user wants to capture, save, jot down, or add a rough future feature, product, workflow, or improvement idea without turning it into a backlog item, feature brief, or implementation task.
+---
+
+# Feature Idea Capture
+
+Capture rough future ideas quickly in `docs/feature-ideas.md`.
+
+## Behavior
+
+- Write the idea down directly. Do not interview the user before capture.
+- Keep the idea intentionally raw: a short heading and a few bullets are enough.
+- If `docs/feature-ideas.md` does not exist, create it on first use.
+- Append new ideas; do not classify, prioritize, groom, or turn them into backlog work.
+- Do not create feature briefs, epics, stories, implementation plans, or code from captured ideas unless the user separately asks for that later.
+- Do not migrate, rename, inspect, or reconcile pre-existing alternate idea files.
+
+## File shape
+
+Use this lightweight shape:
+
+```md
+# Feature Ideas
+
+## <Idea title>
+
+- <Short note>
+- <Short note>
+```
+
+If the file already exists, preserve its current content and append the new idea using the same simple style.

package/templates/skills/react/SKILL.md

@@ -13,6 +13,8 @@ This skill covers React componentization, component responsibility, state owners
 
 - creating or editing React components
 - splitting large components
+- constructing or refactoring page-level UI from smaller route-local components
+- deciding when a page file should delegate sections, repeated items, panels, overlays, menus, states, and formatting helpers to focused files
 - deciding where state should live
 - separating presentational components from server-interacting or data-owning components
 - reviewing component responsibility and prop design
@@ -68,15 +70,61 @@ This skill covers React componentization, component responsibility, state owners
 - Each component should live in its own file by default; do not define multiple components in the same file just because they are currently small.
 - If a helper component is only temporary, promote it to its own file as soon as it represents a meaningful UI responsibility.
 
+### 9. Build screens as composition roots, not component dumping grounds
+- Treat page-level components, route-level containers, and major feature components as composition roots: they should assemble focused child components, not define every section, repeated item, overlay, menu, state, helper, and interaction inline.
+- A top-level screen component may own data loading, high-level layout, route states, and wiring, but should delegate meaningful UI regions to named components.
+- If a UI region has its own state, interaction, repeated rendering, overlay, menu, empty/error/loading state, or domain formatting concern, strongly prefer extracting it to a focused nearby file.
+- Keep route entry files especially thin: they should fetch or prepare data, handle route-level states, and compose the screen. Avoid placing substantial presentational or interactive subcomponents directly inside them.
+- Route-local or feature-local components are good defaults for UI that belongs to one screen or feature. Shared components should be extracted only when reuse is real, not speculative.
+
+## File splitting triggers
+
+When editing a React page, route container, or major component, extract a separate component or helper file when any of these are true:
+
+- The file defines more than one meaningful UI responsibility, such as a container plus repeated item plus action surface plus state view.
+- A nested component has a product/UI name a user, designer, or teammate would recognize.
+- A UI region owns local state, submission or mutation behavior, pending/optimistic feedback, validation, confirmation, or recovery behavior.
+- A component renders a repeated unit, such as a row, card, list item, tile, timeline entry, tab panel, or menu group.
+- A component represents an empty state, error state, no-results state, loading state, permission state, or other named screen state.
+- A helper formats domain-visible values, such as money, dates, percentages, names, quantities, labels, or statuses, and is used by more than one component.
+- The parent component becomes hard to scan in one pass or requires scrolling through implementation details to understand the screen structure.
+
+Prefer nearby files first, using names from the product or UI. For example:
+
+```txt
+page.tsx
+feature-shell.tsx
+feature-summary.tsx
+feature-list.tsx
+feature-item.tsx
+feature-actions.tsx
+feature-state.tsx
+feature-format.ts
+feature-types.ts
+```
+
 ## Decision rule
 
 When unsure, prefer:
-1. one clear responsibility per component
-2. more focused components instead of fewer overloaded components
-3. one component per file by default
-4. stateless presentational components that render from props
-5. stateful components only where local interaction state is genuinely owned
-6. data/server interaction in obvious owner components
-7. local state unless coordination requires lifting it
-8. composition over flag-heavy component APIs
-9. no duplicated derived state
+1. route entry files as thin composition roots
+2. route-level or feature-level containers that own only the interaction state they coordinate
+3. one clear responsibility per component
+4. more focused components instead of fewer overloaded components
+5. one meaningful component per file by default
+6. nearby component files before shared abstractions
+7. stateless presentational components that render from props
+8. stateful components only where local interaction state is genuinely owned
+9. data/server interaction in obvious owner components
+10. local state unless coordination requires lifting it
+11. composition over flag-heavy component APIs
+12. no duplicated derived state
+
+## Componentization self-review
+
+Before finishing a React change, ask:
+
+- Can I understand the screen structure from the top-level file without reading repeated item, action surface, overlay, state, or formatting internals?
+- Are meaningful UI regions and repeated units in named components?
+- Does each file have one obvious reason to change?
+- Are server/client boundaries still as small as practical?
+- Did I avoid creating shared abstractions before there is real reuse?

package/templates/skills/scrum-master-planner/SKILL.md

@@ -213,37 +213,6 @@ Before finishing, verify:
 - no Story adds scope that is absent from the feature brief or technical design
 - acceptance criteria are testable enough for a reviewer
 
-### 6. Mandatory GitHub export gate
-
-After all local Epic and User Story files are written, you must run the GitHub export gate before the final response. This gate is mandatory whenever Scrum planning creates or updates local Epic or User Story files.
-
-Do not skip the gate because the user did not mention GitHub. Do not assume GitHub MCP is unavailable. Explicitly check whether GitHub MCP tools are available for issue creation, issue ID access, and native sub-issue mutation.
-
-If any required GitHub MCP capability is unavailable, do not offer GitHub export. In the final response, include a single concise note that GitHub export was skipped because the required GitHub MCP capabilities were unavailable.
-
-If the required GitHub MCP capabilities are available:
-
-1. Resolve the target repository from the current local repo's GitHub `origin` remote only. Do not ask for or use another repository.
-2. Ask one explicit opt-in question before any GitHub mutation: "GitHub MCP is available. Create GitHub Issues for these Epics and User Stories in the current repo?"
-3. If the user declines, perform no GitHub mutation.
-4. If the user accepts, create a fresh issue set every time. Do not search for duplicates or update existing issues.
-5. Create one issue per Epic with no labels.
-6. Create one issue per User Story with no labels.
-7. Attach each User Story issue as a native GitHub sub-issue of its parent Epic issue.
-8. Report created issue numbers or URLs.
-
-Keep issue bodies concise and source-grounded. Include the source local doc path and relevant summary, scope, acceptance criteria, or validation notes. Do not modify local Markdown files with GitHub URLs.
-
-Native sub-issues are required for this export. Preserve each created User Story issue's GitHub issue `id` because native sub-issue APIs need the child issue ID, not only its issue number. If issue creation, issue ID access, or native sub-issue attachment fails or is unavailable, fail clearly and do not fall back to labels, Markdown checklists, loose links, GitHub Projects, milestones, assignees, or status tracking.
-
-Passing the gate means exactly one of these outcomes occurred:
-
-- GitHub MCP was unavailable or incomplete, and the final response says export was skipped for that reason.
-- GitHub MCP was available, the user declined export, and no GitHub mutation occurred.
-- GitHub MCP was available, the user accepted export, and the created issue numbers or URLs are reported.
-
-Never finish a Scrum planning run without one of these three GitHub export outcomes.
-
 ## Final response behavior
 
 After writing files, final-answer with only:
@@ -251,6 +220,5 @@ After writing files, final-answer with only:
 - the Epic directories created or updated
 - the number of Epics and User Stories
 - any source-scope items intentionally left unresolved or captured as risks
-- the GitHub export gate outcome
 
 Do not paste artifact bodies, excerpts, outlines, story text, acceptance criteria, or section summaries. Only include generated artifacts when the user explicitly asks for inline review in the current request.

package/templates/skills/technical-design-writer/SKILL.md

@@ -173,31 +173,6 @@ Use this structure as a starting point. Delete sections that do not add value.
 
 A good technical design is short, specific, and useful. It should not try to be the product brief, architecture skill, clean-code skill, implementation plan, or ticket backlog.
 
-## Optional Notion export after local write
-
-After the local Markdown file is written successfully, optionally offer Notion export. Local Markdown remains the canonical pipeline artifact and Notion is only a convenience export destination.
-
-1. Do not check Notion export before the local file exists.
-2. After writing the local file, read `.sibu/state.json` if available.
-3. Offer export only when all are true:
-   - `selectedMcpServers` includes `notion`
-   - `mcpServerConfigs.notion.docsParentPage` is present
-   - Notion MCP tools are available in the current agent session
-4. If export is unavailable, do nothing else and finish with the normal local path response.
-5. If export is available, ask for explicit opt-in before creating or modifying any Notion page.
-6. If the user declines, do nothing else.
-7. If the user accepts, create or reuse Notion organization pages under the configured parent page:
-
-```txt
-<docsParentPage>
-└── <repo name>
-    └── Features
-        └── <feature name>
-            └── Technical Design
-```
-
-Create a new document page for the just-written artifact content. Do not write Notion URLs back into local Markdown. Report Notion export success or a clear Notion export failure, while preserving the local file as the completed artifact either way.
-
 ## Final response behavior
 
 After writing the file, final-answer with only the path created or updated. Do not paste the technical design body, excerpt, outline, or section summaries.

package/templates/skills/ux-expert/SKILL.md

@@ -133,31 +133,6 @@ Use only helpful sections from this shape:
 
 The Binding Mockups section is authoritative for downstream work unless this UX spec is revised.
 
-## Optional Notion export after local write
-
-After the local Markdown file is written successfully, optionally offer Notion export. Local Markdown remains the canonical pipeline artifact and Notion is only a convenience export destination.
-
-1. Do not check Notion export before the local file exists.
-2. After writing the local file, read `.sibu/state.json` if available.
-3. Offer export only when all are true:
-   - `selectedMcpServers` includes `notion`
-   - `mcpServerConfigs.notion.docsParentPage` is present
-   - Notion MCP tools are available in the current agent session
-4. If export is unavailable, do nothing else and finish with the normal local path response.
-5. If export is available, ask for explicit opt-in before creating or modifying any Notion page.
-6. If the user declines, do nothing else.
-7. If the user accepts, create or reuse Notion organization pages under the configured parent page:
-
-```txt
-<docsParentPage>
-└── <repo name>
-    └── Features
-        └── <feature name>
-            └── UX Design
-```
-
-Create a new document page for the just-written artifact content. Do not write Notion URLs back into local Markdown. Report Notion export success or a clear Notion export failure, while preserving the local file as the completed artifact either way.
-
 ## Final response behavior
 
 After writing the file, final-answer with only the path created or updated. Do not paste the UX spec body, excerpt, outline, mockups, or section summaries.

package/bin/shared/templates.js

@@ -1,60 +0,0 @@
-import fs from 'node:fs';
-import path from 'node:path';
-import { getTemplatesPath } from './paths.js';
-export function readTemplate(relativePath) {
-    return fs.readFileSync(path.join(getTemplatesPath(), relativePath), 'utf8');
-}
-export function readTemplateManifest() {
-    const manifest = JSON.parse(fs.readFileSync(path.join(getTemplatesPath(), 'manifest.json'), 'utf8'));
-    if (!isTemplateManifest(manifest)) {
-        throw new Error('templates/manifest.json is not a valid template manifest.');
-    }
-    return manifest;
-}
-export function getTemplateVersion(manifest, templateRelativePath) {
-    const template = manifest.templates[templateRelativePath];
-    if (!template) {
-        throw new Error(`Template ${templateRelativePath} is missing from templates/manifest.json.`);
-    }
-    return template.version;
-}
-export function renderTemplateForSync({ templateRelativePath, currentPath, selectedLanguageSkills, selectedFrameworkSkills, selectedArchitectureSkill, selectedWorkflowSkills = [], }) {
-    let contents = readTemplate(templateRelativePath);
-    if (contents.includes('{{PROJECT_OVERVIEW}}')) {
-        contents = contents.replace('{{PROJECT_OVERVIEW}}', extractProjectOverview(currentPath) ?? 'Describe this project.');
-    }
-    return renderSkillRouting(contents, selectedLanguageSkills, selectedFrameworkSkills, selectedArchitectureSkill, selectedWorkflowSkills);
-}
-export function renderSkillRouting(contents, selectedLanguageSkills, selectedFrameworkSkills, selectedArchitectureSkill, selectedWorkflowSkills = []) {
-    if (!contents.includes('{{OPTIONAL_SKILL_ROUTING}}')) {
-        return contents;
-    }
-    const optionalRouting = [...selectedLanguageSkills, ...selectedFrameworkSkills, ...(selectedArchitectureSkill ? [selectedArchitectureSkill] : []), ...selectedWorkflowSkills]
-        .map((skill) => `- ${skill.routingInstruction}`)
-        .join('\n');
-    return contents.replace('{{OPTIONAL_SKILL_ROUTING}}', optionalRouting);
-}
-export function extractProjectOverview(filePath) {
-    if (!fs.existsSync(filePath)) {
-        return undefined;
-    }
-    const contents = fs.readFileSync(filePath, 'utf8');
-    const match = contents.match(/## Project overview\s+([\s\S]*?)(?=\n## |$)/);
-    const overview = match?.[1]?.trim();
-    return overview || undefined;
-}
-function isTemplateManifest(value) {
-    if (!value || typeof value !== 'object') {
-        return false;
-    }
-    const manifest = value;
-    return (typeof manifest.templateVersion === 'string' &&
-        !!manifest.templates &&
-        typeof manifest.templates === 'object' &&
-        Object.values(manifest.templates).every((template) => !!template &&
-            typeof template === 'object' &&
-            typeof template.version === 'string' &&
-            typeof template.description === 'string' &&
-            Array.isArray(template.changes) &&
-            template.changes.every((change) => typeof change === 'string')));
-}