@pantion/mcp-server 0.1.0

package/protocol/templates/traceability-map.md

@@ -0,0 +1,56 @@
+# Traceability Map Template
+
+> **Artifact Type:** Derived / Non-Canonical
+> **Rule:** If this document conflicts with the Canonical Dialog, the Canon wins.
+
+---
+
+## 1) Source Canon Reference
+
+- **Canon Name:** [name]
+- **Canon Date:** [date]
+- **Canon Location:** [path]
+- **Convergence Stamp:**
+  - STATUS: [status]
+  - INFERENCE POLICY: [policy]
+
+---
+
+## 2) How to Use This Map
+
+Each Canon statement (anchored) must map to:
+1. One or more **Derived Requirements** (from spec files)
+2. One or more **Acceptance Tests** (AT-### IDs)
+3. One or more **Implementation References** (file:function)
+4. **Evidence** (logs/screenshots/test output) proving it works
+
+If any row cannot be completed without guessing, the Canon needs an AMENDMENT.
+
+---
+
+## 3) Traceability Table
+
+| Canon Anchor | Canon Statement (short quote) | Requirement ID | Test IDs | Implementation Ref | Evidence |
+|---|---|---|---|---|---|
+| H1 | [quote] | R-001 | AT-001, AT-002 | src/...:... | [evidence] |
+| A2 | [quote] | R-002 | AT-101 | src/...:... | [evidence] |
+| H3 | [quote] | R-003 | AT-401 | src/...:... | [evidence] |
+
+(Add rows until all Canon Anchors are covered.)
+
+---
+
+## 4) Coverage Summary
+
+- **Total Canon Anchors:** [number]
+- **Covered in table:** [number]
+- **Missing coverage:** [number] (must be zero for release)
+
+---
+
+## 5) Change Control
+
+When a Canon AMENDMENT is added:
+- Add new rows for new/changed Canon Anchors
+- Mark superseded requirements/tests
+- Re-run the minimum acceptance set + changed tests

package/skills/image/convergence-rules.md

@@ -0,0 +1,55 @@
+# Image Generation — Additional Convergence Rules
+
+In addition to the standard Pantion convergence elements, always cover:
+
+## Visual Intent
+- What is the core emotion, concept, or message?
+- What should the viewer feel or understand?
+- If the intent is abstract (e.g., "convergence", "growth", "trust"), ask: "How would you visualize that concretely? For example, lines coming together, a plant sprouting, hands shaking — or do you want me to suggest options?"
+- Always arrive at concrete visual elements. Abstract concepts must be translated into something a viewer can see.
+
+## Context and Usage (ask early — determines format and style)
+- Where will this image be used? (website, social media, print, presentation, icon)
+- Are there brand guidelines or constraints?
+- This determines format, resolution, and appropriate style — ask BEFORE format/style questions.
+
+## Subject and Composition
+- What are the key visual elements? What is the main subject?
+- Where should elements be positioned? What is the visual hierarchy? (what draws the eye first?)
+- Format and aspect ratio? (square, landscape, portrait, specific dimensions)
+
+## Style
+- Art style or aesthetic? (photorealistic, illustration, cartoon, abstract, etc.)
+- Color palette or mood?
+- References? ("like X" — helps generators understand the target)
+
+## Anti-References (CRITICAL — drives negative prompts)
+- What should this NOT look like? Be specific.
+- What visual clichés to avoid?
+- What tonal boundaries? (e.g., "not childish", "not aggressive", "not corporate")
+- These are HARD constraints. They MUST appear in the generated prompt as negative guidance.
+
+## Technical
+- Target resolution or medium? (web, print, social media — may already follow from Context)
+- Generator preference? (DALL-E, Midjourney, Stable Diffusion, Gemini — FLEX)
+
+## Question Order
+
+Follow this order to avoid redundant questions:
+
+1. **Visual intent** — what and why
+2. **Context/usage** — where (determines format and style constraints)
+3. **Subject and composition** — what we see, format
+4. **Style** — how it looks
+5. **Color** — palette and mood
+6. **Anti-references** — what it must NOT be
+7. **Technical** — generator preference (only if user cares)
+
+Skip questions whose answers are already implied by earlier answers. If format follows logically from context (e.g., "social media profile" → square), confirm rather than ask.
+
+## IMPORTANT
+- Do NOT choose a generator unless the user insists — mark as FLEX
+- Focus on the VISUAL INTENT, not the technical prompt syntax
+- The canon describes what the image should express, not prompt engineering
+- Abstract concepts MUST be translated into concrete visual descriptions before convergence is complete
+- Anti-references are HARD constraints, not suggestions — treat them with the same weight as positive requirements

package/skills/image/prompts/convergence-intro.md

@@ -0,0 +1,25 @@
+# Image Generation — Convergence Opening
+
+You are converging an image generation intent. Your goal is to reach an unambiguous visual description through targeted questions.
+
+## Opening approach
+
+1. Acknowledge what the user wants to create
+2. Ask for the **core visual intent**: what should the viewer feel or understand?
+3. If the intent is abstract, immediately ask how to visualize it concretely — don't leave abstract concepts unresolved
+4. Then systematically cover (in this order):
+   - Context: where will it be used? (determines format and style)
+   - Subject and key visual elements
+   - Composition and hierarchy (what draws the eye first?)
+   - Format and aspect ratio (may already follow from context — confirm, don't re-ask)
+   - Style and aesthetic (photorealistic, illustration, cartoon, abstract, etc.)
+   - Color palette and mood
+   - What should it NOT look like? (anti-references — be specific, these become negative prompts)
+
+## Tone
+
+- Be direct — ask one visual question at a time
+- Do not suggest a generator unless the user asks — mark as FLEX
+- If the user's visual description is vague, ask for a concrete reference or anti-reference
+- Focus on the visual intent, not on prompt engineering syntax
+- Skip questions whose answers are already implied by earlier answers

package/skills/image/prompts/translate-intro.md

@@ -0,0 +1,37 @@
+# Image Generation — Translation Opening
+
+You are translating a converged image canon into generation-ready files.
+
+## Process
+
+1. Read the complete dialog (canon) — this is the only source of truth
+2. Generate the required files as described in `translate.md`:
+   - `canon/{naam}/prompt.md` — detailed, generator-agnostic image description
+   - `canon/{naam}/brief.md` — human-readable creative brief
+   - Generator-specific prompts if applicable
+3. Every file starts with: `<!-- Derived from: canon/{naam}/dialog.md, [date] -->`
+
+## Key rules
+
+- Source is ALWAYS the dialog, never the summary
+- The prompt describes WHAT the image should express, derived from the converged intent
+- Write the prompt in plain English, even if the dialog was in another language
+- Do not add visual elements that are not in the dialog
+
+## Critical translation steps
+
+### 1. Negative prompts (never skip)
+- Find ALL anti-references in the dialog ("niet X", "geen Y", "vermijd Z")
+- Translate each into explicit negative guidance in the prompt
+- Be specific and use multiple phrasings — generators need redundancy to respect negation
+- Format negative prompts according to generator conventions (see translate.md)
+
+### 2. Abstract → Concrete (never copy literally)
+- Find abstract concepts used as visual intent ("convergentie", "groei", "kracht")
+- Translate each into concrete visual elements (shapes, movements, compositions)
+- If the dialog doesn't specify the visual metaphor, choose the most direct one and mark as FLEX
+
+### 3. Prompt structure
+- Structure as: subject, composition, style, color/mood, technical details
+- Follow with: negative prompt section
+- Include generator-specific formatting where applicable

package/skills/image/skill.json

@@ -0,0 +1,12 @@
+{
+  "name": "image",
+  "displayName": "Image Generation",
+  "description": "Converge intent for image generation. Translates canon to detailed image generation prompts.",
+  "version": "0.1.0",
+  "keywords": [
+    "image", "picture", "photo", "illustration", "art",
+    "visual", "design", "logo", "icon", "drawing",
+    "afbeelding", "foto", "tekening", "illustratie", "beeld",
+    "poster", "banner", "artwork"
+  ]
+}

package/skills/image/translate.md

@@ -0,0 +1,67 @@
+# Image Generation — Translation Instructions
+
+After convergence, generate the following files from the dialog canon.
+
+## Always Generate
+
+1. **`canon/{naam}/prompt.md`**
+   - A detailed, generator-agnostic image description
+   - Structured sections (see Prompt Structure below)
+   - Written in plain English (even if dialog was in another language)
+   - Anti-references as explicit negative guidance section
+
+2. **`canon/{naam}/brief.md`**
+   - A human-readable creative brief
+   - Captures the intent, context, and constraints
+   - Useful for sharing with designers or for future reference
+
+## Generate If Applicable
+
+3. **Generator-specific prompts** (if a generator was chosen or for convenience):
+   - `canon/{naam}/prompt-dalle.md` — optimized for DALL-E / ChatGPT
+   - `canon/{naam}/prompt-midjourney.md` — optimized for Midjourney
+   - `canon/{naam}/prompt-sd.md` — optimized for Stable Diffusion
+   - `canon/{naam}/prompt-gemini.md` — optimized for Gemini
+
+## Prompt Structure
+
+Every prompt (universal and generator-specific) MUST include these sections:
+
+### Positive prompt
+- **Subject**: what is depicted (concrete, visual)
+- **Composition**: layout, positioning, visual hierarchy
+- **Style**: art style, aesthetic, rendering approach
+- **Color**: palette, mood, lighting
+- **Technical**: format, background, resolution
+
+### Negative prompt (CRITICAL)
+- Translate ALL anti-references from the dialog into explicit negative guidance
+- "Niet kinderlijk" → "not childish, not cute, not infantile, no rounded baby-like features"
+- "Niet realistisch" → "not photorealistic, not hyper-detailed, no photo textures"
+- Be specific and redundant — generators need multiple phrasings to respect negation
+
+### Generator-specific formatting
+- **DALL-E**: Negative guidance woven into the prompt text ("Do not make it childish. Avoid...")
+- **Midjourney**: Use `--no` parameter for key negatives, plus textual negatives in prompt
+- **Stable Diffusion**: Separate `negative_prompt:` field with comma-separated terms
+- **Gemini**: Negative guidance woven into the prompt text, similar to DALL-E
+
+## Abstract → Concrete Translation (CRITICAL)
+
+The dialog may contain abstract concepts as visual intent (e.g., "convergence", "growth", "freedom"). These MUST be translated into concrete visual elements in the prompt:
+
+- **Abstract concept in dialog** → **Concrete visual in prompt**
+- "convergentie" → "lines converging to a focal point, funnel shape, elements gathering toward center"
+- "groei" → "plant sprouting, upward movement, expanding forms"
+- "vrijheid" → "open sky, spread wings, unbound flowing elements"
+
+If the dialog does not specify how to visualize an abstract concept, choose the most direct visual metaphor and note it as a FLEX choice.
+
+## Rules
+
+- Source is ALWAYS the dialog, not the summary
+- Each file starts with: `<!-- Derived from: canon/{naam}/dialog.md, [date] -->`
+- The prompt captures WHAT the image should express, derived from the converged intent
+- Anti-references MUST appear as negative prompt/guidance — never omit them
+- Abstract concepts MUST be translated to concrete visuals — never copy them literally
+- Update `canon/{naam}/traceability.md` with complete mapping

package/skills/skill-builder/convergence-rules.md

@@ -0,0 +1,64 @@
+# Skill Builder — Additional Convergence Rules
+
+You are building a Pantion SKILL — a domain-specific knowledge module that will guide future convergence dialogs. Your job is to extract the user's domain expertise and codify it as convergence guidance.
+
+In addition to the standard Pantion convergence elements, always cover:
+
+## Domain Identity
+- What domain does this skill cover? (one sentence, be specific)
+- Who are the typical users? What are they trying to achieve?
+- What is explicitly OUT of scope?
+- What adjacent domains might users confuse with this one?
+
+## Critical Domain Questions
+- What questions MUST always be asked when converging in this domain?
+- In what order should they be asked? (dependency-aware)
+- For each question: why does it matter? What goes wrong if it is skipped?
+- Which questions are domain-unique (not covered by the standard protocol)?
+
+## Domain-Specific HARD/FLEX Guidance
+- What constraints are typically HARD in this domain?
+- What decisions are typically FLEX?
+- What constraints are commonly overlooked?
+- What non-goals are commonly assumed but should be stated?
+
+## Safety Boundaries
+- What actions must the skill NEVER allow or encourage?
+- What data or resources are off-limits?
+- What are the worst-case outcomes if the skill is misused or poorly applied?
+- Are there legal, ethical, or professional constraints specific to this domain?
+- What guardrails should the skill enforce regardless of user preference?
+
+## Common Mistakes
+- What do agents typically get wrong in this domain?
+- What domain knowledge do agents lack that humans take for granted?
+- What "obvious" assumptions are actually wrong?
+- What questions do agents fail to ask?
+
+## Output Specification
+- What files should translation produce for this domain?
+- For each file: what should it contain? What format?
+- Are there domain-specific output formats?
+- What would a GOOD translation look like vs a BAD one?
+
+## Vocabulary and Concepts
+- What domain-specific terms should the agent understand?
+- Are there terms that mean something different in this domain?
+- What concepts require explanation for a general-purpose agent?
+
+## Success Criteria for the Skill
+- How would you verify that this skill works well?
+- What would a dialog look like that used this skill correctly?
+- What would a BAD dialog look like (skill not working)?
+
+## Keywords
+- What terms should trigger this skill for auto-selection?
+- Include variations, synonyms, and multilingual terms where relevant
+
+## IMPORTANT
+- Ask ONE question at a time — wait for the answer before asking the next
+- The user is the domain expert — extract their knowledge, do not assume it
+- If the user is unsure about a question, mark it as FLEX with a sensible default
+- Do not suggest specific technologies or implementations
+- Focus on WHAT the skill should teach, not HOW it will be implemented
+- Cover anti-patterns (what to avoid) just as thoroughly as patterns (what to do)

package/skills/skill-builder/prompts/convergence-intro.md

@@ -0,0 +1,21 @@
+# Skill Builder — Convergence Opening
+
+You are creating a new Pantion skill. Your goal is to extract the user's domain expertise and codify it as convergence guidance.
+
+## Opening approach
+
+1. Ask what domain this skill is for — in one sentence
+2. Ask who the typical users are and what they are trying to achieve
+3. Then systematically cover:
+   - What questions must always be asked in this domain?
+   - What do agents commonly get wrong?
+   - What does the output of a good convergence look like?
+   - What are the domain-specific constraints and vocabulary?
+
+## Tone
+
+- You are interviewing a domain expert — be respectful of their knowledge
+- Ask one question at a time
+- If they give a broad answer, probe for specifics
+- Focus on extracting IMPLICIT knowledge — things the expert knows but might not think to mention
+- Use concrete examples: "Can you give me an example of when an agent got this wrong?"

package/skills/skill-builder/prompts/translate-intro.md

@@ -0,0 +1,17 @@
+# Skill Builder — Translation Opening
+
+You are translating a converged skill canon into skill files.
+
+## Process
+
+1. Read the complete skill dialog (canon) — this is the only source of truth
+2. Generate the required skill files as described in `translate.md`
+3. Every file starts with: `<!-- Derived from: skills/{skill_name}/canon/skill-dialog.md, [date] -->`
+
+## Key rules
+
+- Source is ALWAYS the dialog, never the summary
+- The convergence-rules.md must be complete enough to guide a convergence dialog without any other context
+- Keywords must be realistic for auto-selection
+- Do not include implementation details — only domain knowledge
+- Anti-patterns are as important as patterns

package/skills/skill-builder/skill.json

@@ -0,0 +1,10 @@
+{
+  "name": "skill-builder",
+  "displayName": "Skill Builder",
+  "description": "Converge intent for creating a new Pantion skill. Extracts domain knowledge to produce a complete skill definition.",
+  "version": "0.1.0",
+  "keywords": [
+    "skill", "create-skill", "new-skill", "skill-builder",
+    "domain", "expertise", "convergence-rules"
+  ]
+}

package/skills/skill-builder/translate.md

@@ -0,0 +1,46 @@
+# Skill Builder — Translation Instructions
+
+After convergence, generate SKILL FILES from the skill dialog canon.
+These files form a complete Pantion skill that can be used in future convergence dialogs.
+
+The skill canon itself (stored in the skill's `canon/` directory) is the source of truth.
+
+## Always Generate
+
+1. **`skills/{skill_name}/skill.json`**
+   - Manifest with: name, displayName, description, version ("0.1.0"), keywords
+   - Keywords derived from the domain identity and keywords discussion
+   - Description is one sentence capturing the domain intent
+
+2. **`skills/{skill_name}/convergence-rules.md`**
+   - Domain-specific convergence guidance derived from the dialog
+   - Structured as additional rules (supplements the core protocol)
+   - Includes: critical domain questions, common mistakes to avoid, domain-specific HARD/FLEX guidance
+   - Each rule should explain WHY it matters
+   - Include an IMPORTANT section with domain-specific warnings
+   - Must be self-contained — an agent reading ONLY this file should understand the domain
+
+3. **`skills/{skill_name}/translate.md`**
+   - Translation instructions for this domain
+   - Lists which files to generate after convergence (Always + If Applicable)
+   - Describes the expected content and format of each file
+   - Follows the pattern of existing skill translate.md files
+
+4. **`skills/{skill_name}/prompts/convergence-intro.md`**
+   - Opening prompt for convergence in this domain
+   - Sets the right tone and first questions
+   - References the domain-specific convergence rules
+
+5. **`skills/{skill_name}/prompts/translate-intro.md`**
+   - Opening prompt for translation in this domain
+   - Sets expectations for output quality
+
+## Rules
+
+- Source is ALWAYS the skill dialog (canon), not the summary
+- Each generated markdown file starts with: `<!-- Derived from: skills/{skill_name}/canon/skill-dialog.md, [date] -->`
+- Do NOT add derivation comments to JSON files (skill.json) — JSON does not support comments
+- The convergence-rules.md file is the most important output — it should be complete and self-contained
+- Do not include implementation details in convergence-rules.md — only domain knowledge
+- Keywords should be broad enough to trigger the skill but specific enough to avoid false matches
+- The translate.md should describe outputs specific to this domain

package/skills/software/convergence-rules.md

@@ -0,0 +1,29 @@
+# Software Development — Additional Convergence Rules
+
+In addition to the standard Pantion convergence elements, always cover:
+
+## Technology Stack
+- Is there a preferred language, framework, or platform? (FLEX unless the user insists)
+- Are there integration requirements with existing systems?
+
+## Data Model
+- What data does the system manage?
+- Where is it stored? What is the retention policy?
+
+## User Interface
+- Who are the users? (roles, permissions)
+- How do they interact? (CLI, web, API, mobile)
+- What does a successful interaction look like?
+
+## Deployment
+- Where will it run? (local, cloud, specific platform)
+- Are there scaling requirements?
+
+## Testing
+- How should correctness be verified?
+- What are the critical paths that must always work?
+
+## IMPORTANT
+- Do NOT choose specific technologies unless the user insists
+- Mark all technology preferences as FLEX
+- Focus on WHAT the software does, not HOW it's built

package/skills/software/prompts/convergence-intro.md

@@ -0,0 +1,22 @@
+# Software Development — Convergence Opening
+
+You are converging a software project. Your goal is to reach an unambiguous intent description through targeted questions.
+
+## Opening approach
+
+1. Acknowledge what the user wants to build
+2. Ask for the **core intent** in one sentence: what does this software do?
+3. Then systematically cover the convergence elements:
+   - Who are the users?
+   - What are the inputs and outputs?
+   - What does success look like? (externally verifiable)
+   - What does it NOT do? (non-goals)
+   - What happens when something fails?
+   - Are there hard constraints? (security, privacy, cost, performance)
+
+## Tone
+
+- Be direct and efficient — ask one or two questions at a time
+- Do not suggest solutions or technologies unless the user asks
+- Mark all technology preferences as FLEX unless the user insists
+- If the user's answer is ambiguous, ask again — do not guess

package/skills/software/prompts/translate-intro.md

@@ -0,0 +1,19 @@
+# Software Development — Translation Opening
+
+You are translating a converged software canon into project specification files.
+
+## Process
+
+1. Read the complete dialog (canon) — this is the only source of truth
+2. Generate the required files as described in `translate.md`
+3. Every file starts with: `<!-- Derived from: canon/[name]-dialog.md, [date] -->`
+4. Update `canon/traceability.md` with the mapping
+
+## Key rules
+
+- Source is ALWAYS the dialog, never the summary
+- Focus on WHAT the project does, not HOW it should be built
+- Do not add requirements that are not in the dialog
+- Do not omit requirements that are in the dialog
+- Mark elements as HARD or FLEX according to the dialog
+- Non-goals must be explicitly listed in the output

package/skills/software/skill.json

@@ -0,0 +1,12 @@
+{
+  "name": "software",
+  "displayName": "Software Development",
+  "description": "Converge intent for software projects. Translates canon to project specification files (requirements, constraints, specs).",
+  "version": "0.1.0",
+  "keywords": [
+    "software", "app", "application", "api", "website", "web",
+    "tool", "cli", "service", "system", "platform", "backend",
+    "frontend", "database", "server", "code", "program",
+    "bouwen", "applicatie", "programma"
+  ]
+}

package/skills/software/translate.md

@@ -0,0 +1,74 @@
+# Software Development — Translation Instructions
+
+After convergence, generate PROJECT SPECIFICATION files from the dialog canon.
+These files describe the project for any developer or tool — they are NOT agent-specific instruction files.
+
+The canon itself (served via MCP) is the authoritative instruction set for any connected agent.
+
+## Always Generate
+
+1. **`canon/{naam}/spec/requirements.md`**
+   - Project intent and goals (from system intent)
+   - Functional requirements (from inputs/outputs/success criteria)
+   - Non-functional requirements (from constraints, authority budget)
+   - Non-goals (explicit exclusions)
+
+2. **`canon/{naam}/spec/constraints.md`**
+   - All HARD constraints from the dialog
+   - Forbidden actions from Authority Budget
+   - Data access and retention policies
+   - Inference policy
+
+3. **`canon/{naam}/spec/success-criteria.md`**
+   - Definition of Done (from success criteria)
+   - Acceptance criteria (externally verifiable)
+   - Error handling requirements (from failure behavior)
+
+## Generate If Applicable
+
+4. **`canon/{naam}/spec/api-spec.md`** — if the project exposes an API
+   - Endpoints, inputs, outputs
+   - Error responses
+   - Authentication/authorization
+
+5. **`canon/{naam}/spec/data-model.md`** — if the project manages persistent data
+   - Entities and relationships
+   - Storage requirements
+   - Retention policies
+
+6. **`canon/{naam}/spec/architecture.md`** — if the system has multiple components
+   - Component overview
+   - Interfaces between components
+   - Deployment model
+
+7. **`canon/{naam}/spec/interfaces/interface-[A]-[B].md`** — per interface (if decomposed)
+   - Parties, guarantees, expectations
+   - Data shape, error semantics
+   - Rate/cost expectations
+
+## Software-Specific Derived Artifacts
+
+These use templates from `protocol/templates/` and are specific to software projects:
+
+8. **`canon/{naam}/spec/behavior-map.md`** — from `protocol/templates/behavior-map.md`
+   - Map each system behavior to Canon Anchors (H1, A3, etc.)
+   - 10 sections: intent, inputs, outputs, core behaviors, constraints, non-goals, failure modes, observability, authority budget
+   - Every entry MUST cite a Canon Anchor
+
+9. **`canon/{naam}/spec/acceptance-tests.md`** — from `protocol/templates/acceptance-tests.md`
+   - AT-### format: positive flows, negative tests, edge cases, failure tests, authority budget tests, non-goal tests
+   - Each test cites Canon Anchors and is labeled HARD or FLEX
+   - Define minimum acceptance set
+
+10. **`canon/{naam}/spec/traceability-map.md`** — from `protocol/templates/traceability-map.md`
+    - Canon Anchor -> Requirement -> Test -> Implementation -> Evidence
+    - Coverage must be 100% (every Canon Anchor covered)
+
+## Rules
+
+- Source is ALWAYS the dialog, not the summary
+- Each file starts with: `<!-- Derived from: canon/{naam}/dialog.md, [date] -->`
+- Update `canon/{naam}/traceability.md` with complete mapping
+- Focus on WHAT the project does, not HOW it should be built
+- These are project artifacts readable by any developer or tool
+- Canon Anchors use the notation: H[N] for HUMAN turn N, A[N] for ASSISTANT turn N (1-indexed)