feat: initial marketplace (knowledge-curator + venture)
This commit is contained in:
@@ -0,0 +1,19 @@
|
|||||||
|
{
|
||||||
|
"name": "luki-net",
|
||||||
|
"owner": {
|
||||||
|
"name": "l.kirchner",
|
||||||
|
"url": "https://gitea.luki-net.org/l.kirchner"
|
||||||
|
},
|
||||||
|
"plugins": [
|
||||||
|
{
|
||||||
|
"name": "knowledge-curator",
|
||||||
|
"source": "./knowledge-curator",
|
||||||
|
"description": "Memory-Hub Knowledge-Graph audit & restructuring: structural integrity, dedup, link discovery, taxonomy design (4 read-only subagents). Read-only by default; mutations explicit + backed up."
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"name": "venture",
|
||||||
|
"source": "./venture",
|
||||||
|
"description": "Founder/Fundraising/GTM-Material: Pitch Deck, Investor-Materials-Konsistenz, SaaS-Finanzmodell, Marktanalyse, Executive Summary"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
@@ -0,0 +1,78 @@
|
|||||||
|
# claude-marketplace (Inhalt) — knowledge-curator Plugin
|
||||||
|
|
||||||
|
**Der Inhalt dieses Ordners ist die Wurzel deines Marketplace-Repos**
|
||||||
|
`l.kirchner/claude-marketplace` (bereits angelegt auf
|
||||||
|
https://gitea.luki-net.org/l.kirchner/claude-marketplace). Künftige Skills,
|
||||||
|
Plugins und Agents kommen als weitere Unterordner + Einträge in
|
||||||
|
`.claude-plugin/marketplace.json` dazu.
|
||||||
|
|
||||||
|
## Layout
|
||||||
|
|
||||||
|
```
|
||||||
|
.claude-plugin/marketplace.json # Marketplace-Manifest (Plugin-Liste)
|
||||||
|
knowledge-curator/ # Plugin #1
|
||||||
|
├── .claude-plugin/plugin.json
|
||||||
|
├── skills/knowledge-curator/SKILL.md
|
||||||
|
├── agents/{kg-graph-auditor,kg-entity-deduplicator,kg-relation-miner,kg-taxonomy-architect}.md
|
||||||
|
├── commands/{kg-curate,kg-apply}.md
|
||||||
|
├── hooks/{hooks.json,backup-memory.sh} # Auto-Backup bei Memory-Writes
|
||||||
|
└── README.md # Architektur & Sicherheit
|
||||||
|
push-to-gitea.sh # diesen Baum signiert ins Repo pushen
|
||||||
|
install.sh # local | marketplace (für andere Repos)
|
||||||
|
marketplace-entry.json # Snippet für einen FREMDEN Marketplace
|
||||||
|
```
|
||||||
|
|
||||||
|
## Veröffentlichen (Repo ist schon da, leer)
|
||||||
|
|
||||||
|
Aus diesem Ordner heraus:
|
||||||
|
|
||||||
|
```
|
||||||
|
./push-to-gitea.sh
|
||||||
|
```
|
||||||
|
|
||||||
|
Initialisiert git, setzt das Remote (SSH, Port 2222), committet (mit deiner
|
||||||
|
lokalen Signing-Config) und pusht nach `main`. Danach in Claude Code:
|
||||||
|
|
||||||
|
```
|
||||||
|
/plugin marketplace add https://gitea.luki-net.org/l.kirchner/claude-marketplace
|
||||||
|
/plugin install knowledge-curator@luki-net
|
||||||
|
```
|
||||||
|
|
||||||
|
Manuell geht's genauso:
|
||||||
|
|
||||||
|
```
|
||||||
|
git init -b main
|
||||||
|
git remote add origin ssh://git@gitea.luki-net.org:2222/l.kirchner/claude-marketplace.git
|
||||||
|
git add -A && git commit -S -m "feat: knowledge-curator plugin" && git push -u origin main
|
||||||
|
```
|
||||||
|
|
||||||
|
## Weitere Plugins später hinzufügen
|
||||||
|
|
||||||
|
1. Neuen Unterordner anlegen (`<plugin>/` mit `.claude-plugin/plugin.json` +
|
||||||
|
`skills/`/`agents/`/`commands/`/`hooks/`).
|
||||||
|
2. Eintrag ins `plugins`-Array von `.claude-plugin/marketplace.json`
|
||||||
|
(`{"name": "...", "source": "./<plugin>", "description": "..."}`).
|
||||||
|
3. Committen, pushen. In Claude Code: `/plugin marketplace update luki-net`,
|
||||||
|
dann `/plugin install <plugin>@luki-net`.
|
||||||
|
|
||||||
|
## Schneller Test ohne Marketplace
|
||||||
|
|
||||||
|
`./install.sh local` kopiert Skill/Agents/Commands/Hooks direkt nach
|
||||||
|
`~/.claude/`. Danach Claude Code neu starten bzw. `/reload-plugins`.
|
||||||
|
|
||||||
|
## Wichtig nach der Installation
|
||||||
|
|
||||||
|
- Skill-Änderungen greifen sofort; Änderungen an `agents/`, `commands/`,
|
||||||
|
`hooks/` brauchen `/reload-plugins` oder Neustart.
|
||||||
|
- **Hook konfigurieren:** Der Backup-Hook braucht den Pfad zur Memory-Graph-
|
||||||
|
Datei. `KG_MEMORY_FILE` (oder `MEMORY_FILE_PATH`) in deiner Claude-Code-Env
|
||||||
|
setzen — sonst überspringt der Hook das Datei-Backup sauber (blockiert nie).
|
||||||
|
Optional: `KG_BACKUP_DIR` (Default `~/.claude/kg-backups`),
|
||||||
|
`KG_BACKUP_DEBOUNCE` (120s), `KG_BACKUP_KEEP` (20).
|
||||||
|
- **MCP-Tool-Namen prüfen:** Agents whitelisten `mcp__memory__read_graph`,
|
||||||
|
`…__search_nodes`, `…__open_nodes`; der Hook matcht
|
||||||
|
`mcp__memory__(create|add|delete)_*`. Heißt dein Server anders, in
|
||||||
|
`knowledge-curator/agents/*.md`, `hooks/hooks.json` und SKILL.md anpassen.
|
||||||
|
Check: `claude mcp list` bzw. `/mcp`.
|
||||||
|
|
||||||
|
Architektur, Sicherheit, Kosten: siehe `knowledge-curator/README.md`.
|
||||||
Executable
+77
@@ -0,0 +1,77 @@
|
|||||||
|
#!/usr/bin/env bash
|
||||||
|
# install.sh — Knowledge Curator plugin installer
|
||||||
|
#
|
||||||
|
# ./install.sh local
|
||||||
|
# Copy components straight into ~/.claude/ (skills, agents, commands).
|
||||||
|
# Quick path, no marketplace. Restart Claude Code afterwards.
|
||||||
|
#
|
||||||
|
# ./install.sh marketplace /path/to/your/marketplace-repo
|
||||||
|
# Copy the plugin into an existing marketplace repo and add/replace its
|
||||||
|
# entry in <repo>/.claude-plugin/marketplace.json (needs jq). Prints the
|
||||||
|
# git + /plugin commands to finish. Does NOT push for you.
|
||||||
|
#
|
||||||
|
set -euo pipefail
|
||||||
|
|
||||||
|
HERE="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
|
||||||
|
PLUGIN_DIR="$HERE/knowledge-curator"
|
||||||
|
ENTRY_FILE="$HERE/marketplace-entry.json"
|
||||||
|
MODE="${1:-}"
|
||||||
|
|
||||||
|
die() { echo "ERROR: $*" >&2; exit 1; }
|
||||||
|
[ -d "$PLUGIN_DIR" ] || die "plugin dir not found: $PLUGIN_DIR"
|
||||||
|
|
||||||
|
case "$MODE" in
|
||||||
|
local)
|
||||||
|
DEST="${CLAUDE_HOME:-$HOME/.claude}"
|
||||||
|
echo ">> Local install into $DEST"
|
||||||
|
mkdir -p "$DEST/skills" "$DEST/agents" "$DEST/commands"
|
||||||
|
cp -r "$PLUGIN_DIR/skills/." "$DEST/skills/"
|
||||||
|
cp -r "$PLUGIN_DIR/agents/." "$DEST/agents/"
|
||||||
|
cp -r "$PLUGIN_DIR/commands/." "$DEST/commands/"
|
||||||
|
echo ">> Done. Installed:"
|
||||||
|
echo " skill: knowledge-curator"
|
||||||
|
echo " agents: kg-graph-auditor, kg-entity-deduplicator, kg-relation-miner, kg-taxonomy-architect"
|
||||||
|
echo " commands: /kg-curate, /kg-apply"
|
||||||
|
echo ">> Restart Claude Code (or /reload-plugins) so agents & commands load."
|
||||||
|
echo ">> Verify your MCP tool names in agents/*.md if your server isn't named 'memory'."
|
||||||
|
;;
|
||||||
|
|
||||||
|
marketplace)
|
||||||
|
REPO="${2:-}"
|
||||||
|
[ -n "$REPO" ] || die "usage: ./install.sh marketplace /path/to/marketplace-repo"
|
||||||
|
[ -d "$REPO" ] || die "marketplace repo not found: $REPO"
|
||||||
|
command -v jq >/dev/null 2>&1 || die "jq is required for marketplace mode (install jq or edit marketplace.json by hand)"
|
||||||
|
|
||||||
|
echo ">> Copying plugin into $REPO/knowledge-curator"
|
||||||
|
rm -rf "$REPO/knowledge-curator"
|
||||||
|
cp -r "$PLUGIN_DIR" "$REPO/knowledge-curator"
|
||||||
|
|
||||||
|
MP="$REPO/.claude-plugin/marketplace.json"
|
||||||
|
mkdir -p "$REPO/.claude-plugin"
|
||||||
|
ENTRY="$(cat "$ENTRY_FILE")"
|
||||||
|
|
||||||
|
if [ -f "$MP" ]; then
|
||||||
|
echo ">> Updating existing marketplace.json"
|
||||||
|
tmp="$(mktemp)"
|
||||||
|
jq --argjson e "$ENTRY" \
|
||||||
|
'.plugins = ((.plugins // []) | map(select(.name != $e.name)) + [$e])' \
|
||||||
|
"$MP" > "$tmp" && mv "$tmp" "$MP"
|
||||||
|
else
|
||||||
|
echo ">> Creating new marketplace.json"
|
||||||
|
jq -n --argjson e "$ENTRY" \
|
||||||
|
'{name:"luki-net", owner:{name:"l.kirchner", url:"https://gitea.luki-net.org/l.kirchner"}, plugins:[$e]}' \
|
||||||
|
> "$MP"
|
||||||
|
fi
|
||||||
|
|
||||||
|
echo ">> Done. Next steps:"
|
||||||
|
echo " cd $REPO && git add -A && git commit -m 'add knowledge-curator plugin' && git push"
|
||||||
|
echo " # then in Claude Code:"
|
||||||
|
echo " /plugin marketplace add https://gitea.luki-net.org/l.kirchner/claude-marketplace"
|
||||||
|
echo " /plugin install knowledge-curator@luki-net"
|
||||||
|
;;
|
||||||
|
|
||||||
|
*)
|
||||||
|
sed -n '2,16p' "$0"
|
||||||
|
exit 1
|
||||||
|
;;
|
||||||
|
esac
|
||||||
@@ -0,0 +1,9 @@
|
|||||||
|
{
|
||||||
|
"name": "knowledge-curator",
|
||||||
|
"version": "1.0.0",
|
||||||
|
"description": "Audits and restructures the MCP memory-hub knowledge graph: structural integrity, entity deduplication, link discovery and taxonomy design via four read-only subagents. Read-only by default; mutations are explicit, backed up and confirmed.",
|
||||||
|
"author": { "name": "l.kirchner" },
|
||||||
|
"repository": "https://gitea.luki-net.org/l.kirchner/claude-marketplace",
|
||||||
|
"license": "MIT",
|
||||||
|
"keywords": ["knowledge-graph", "mcp", "memory", "ontology", "deduplication", "curation", "subagents"]
|
||||||
|
}
|
||||||
@@ -0,0 +1,70 @@
|
|||||||
|
# knowledge-curator (plugin internals)
|
||||||
|
|
||||||
|
Orchestrator-Worker-Setup für das Auditieren und Restrukturieren des
|
||||||
|
MCP-Memory-Hubs.
|
||||||
|
|
||||||
|
## Architektur
|
||||||
|
|
||||||
|
```
|
||||||
|
/kg-curate ──► skill: knowledge-curator (Main-Thread, orchestriert)
|
||||||
|
│ dispatcht parallel via Task-Tool:
|
||||||
|
├─► kg-graph-auditor (Struktur-Integrität) read-only / sonnet
|
||||||
|
├─► kg-entity-deduplicator (Überschneidungen/Merges) read-only / opus
|
||||||
|
├─► kg-relation-miner (fehlende Verknüpfungen) read-only / opus
|
||||||
|
└─► kg-taxonomy-architect (Kategorien/Ontologie) read-only / opus
|
||||||
|
│
|
||||||
|
├─► Deutscher Audit-Report
|
||||||
|
└─► kg-changeset.json (Vorschlag, KEINE Mutation)
|
||||||
|
|
||||||
|
/kg-apply ───► liest kg-changeset.json, Backup → Diff → Bestätigung → schreibt
|
||||||
|
```
|
||||||
|
|
||||||
|
**Warum der Orchestrator ein Skill ist:** Subagents werden vom Main-Thread per
|
||||||
|
Task gestartet und verschachteln nicht weiter. Der dispatchende Teil muss im
|
||||||
|
Hauptkontext laufen → Skill (bzw. `/kg-curate`). Jeder Worker arbeitet in
|
||||||
|
eigenem Kontextfenster, zieht den `read_graph`-Dump in seinen Kontext und gibt
|
||||||
|
nur kompaktes JSON zurück — der Hauptkontext bleibt sauber.
|
||||||
|
|
||||||
|
## Sicherheit
|
||||||
|
|
||||||
|
- Audit ist **strikt read-only**: die vier Worker haben im `tools:`-Whitelist
|
||||||
|
keine Write-Tools, können den Graph also nicht verändern.
|
||||||
|
- Mutationen ausschließlich in `/kg-apply`: erst Voll-Backup
|
||||||
|
(`kg-backup-<timestamp>.json`), dann Diff, dann Bestätigung pro destruktiver
|
||||||
|
Gruppe (Merges/Deletes sind unwiderruflich).
|
||||||
|
- Apply-Reihenfolge: additiv (neue Entities/Relations/Observations) → Merges →
|
||||||
|
Migrationen/Renames → Standalone-Deletes zuletzt.
|
||||||
|
- **Backup-Hook (zweite Verteidigungslinie):** `hooks/hooks.json` feuert vor
|
||||||
|
jedem Memory-Write-Tool (`create*`/`add*`/`delete*`) und sichert die
|
||||||
|
Graph-Datei per `backup-memory.sh`. Debounced (ein Apply-Lauf = ein Backup),
|
||||||
|
pruned auf `KG_BACKUP_KEEP`, blockiert nie (Exit 0). Greift auch bei manuellen
|
||||||
|
Writes außerhalb von `/kg-apply`. Pfad zur Graph-Datei via `KG_MEMORY_FILE`
|
||||||
|
(oder `MEMORY_FILE_PATH`) setzen.
|
||||||
|
|
||||||
|
## Komponenten
|
||||||
|
|
||||||
|
| Datei | Rolle |
|
||||||
|
|-------|-------|
|
||||||
|
| `skills/knowledge-curator/SKILL.md` | Orchestrator, Report-Synthese, Change-Set |
|
||||||
|
| `agents/kg-graph-auditor.md` | Orphans, Dangling Relations, leere Entities, Naming |
|
||||||
|
| `agents/kg-entity-deduplicator.md` | Merge-Cluster mit Confidence (≥ 0.6) |
|
||||||
|
| `agents/kg-relation-miner.md` | neue Relations mit Evidenz (≥ 0.5) |
|
||||||
|
| `agents/kg-taxonomy-architect.md` | Typ-Hierarchie + Naming-Regeln + Migrations-Map |
|
||||||
|
| `commands/kg-curate.md` | startet das read-only Audit |
|
||||||
|
| `commands/kg-apply.md` | wendet ein freigegebenes Change-Set an (einziger Writer) |
|
||||||
|
| `hooks/hooks.json` | PreToolUse-Hook auf Memory-Write-Tools |
|
||||||
|
| `hooks/backup-memory.sh` | dateibasiertes Graph-Backup, debounced + pruned |
|
||||||
|
|
||||||
|
## Kosten
|
||||||
|
|
||||||
|
Vier parallele Opus-Subagents ≈ ~7× Tokens vs. Single-Thread. Für
|
||||||
|
Routine-Re-Audits die drei semantischen Worker auf `model: sonnet` setzen — der
|
||||||
|
Auditor läuft bereits auf `sonnet`.
|
||||||
|
|
||||||
|
## Konfiguration
|
||||||
|
|
||||||
|
- MCP-Servername / Tool-Namen in den `agents/*.md` und im SKILL.md an deine
|
||||||
|
Instanz anpassen (Default: Server `memory`, Tools `read_graph` /
|
||||||
|
`search_nodes` / `open_nodes`).
|
||||||
|
- Confidence-Schwellen in den Agent-Bodies justierbar.
|
||||||
|
- Report-Sprache im SKILL.md (Phase 3); Worker-Output bleibt englisch/JSON.
|
||||||
@@ -0,0 +1,46 @@
|
|||||||
|
---
|
||||||
|
name: kg-entity-deduplicator
|
||||||
|
description: >
|
||||||
|
Use this agent to find overlapping or duplicate entities in the MCP
|
||||||
|
memory-hub knowledge graph and propose safe merges. Detects near-duplicate
|
||||||
|
entity names, entities representing the same real-world thing, and
|
||||||
|
observations duplicated across entities. Read-only — proposes merges, never
|
||||||
|
performs them.
|
||||||
|
tools:
|
||||||
|
- mcp__memory__read_graph
|
||||||
|
- mcp__memory__search_nodes
|
||||||
|
- mcp__memory__open_nodes
|
||||||
|
model: opus
|
||||||
|
---
|
||||||
|
|
||||||
|
You find duplicate and overlapping entities. You never merge or delete.
|
||||||
|
|
||||||
|
## Procedure
|
||||||
|
1. `mcp__memory__read_graph` to load all entities + observations.
|
||||||
|
2. Cluster entities that refer to the same underlying thing. Signals:
|
||||||
|
- name variants (`luki-ai` / `luki_ai` / `Luki AI`, abbreviations, typos),
|
||||||
|
- overlapping observation sets,
|
||||||
|
- same entity described under two types.
|
||||||
|
3. For each cluster pick a **canonical** name (most complete / convention-fit)
|
||||||
|
and assign a confidence 0.0–1.0. Be conservative: distinct-but-related
|
||||||
|
entities (e.g. two different Proxmox hosts) are NOT duplicates — those go to
|
||||||
|
the relation-miner, not here. Only flag merges you would defend.
|
||||||
|
4. Separately list observations that are duplicated verbatim across entities.
|
||||||
|
|
||||||
|
## Output — return ONLY this JSON
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"agent": "kg-entity-deduplicator",
|
||||||
|
"duplicate_clusters": [
|
||||||
|
{ "canonical": "<name>",
|
||||||
|
"members": ["<name>", "<name>"],
|
||||||
|
"confidence": 0.0,
|
||||||
|
"rationale": "<why these are the same thing>" }
|
||||||
|
],
|
||||||
|
"duplicate_observations": [
|
||||||
|
{ "observation": "<text>", "entities": ["<name>", "<name>"] }
|
||||||
|
]
|
||||||
|
}
|
||||||
|
```
|
||||||
|
Only include clusters with confidence ≥ 0.6. Flag anything 0.6–0.8 as
|
||||||
|
"review before merge" in the rationale.
|
||||||
@@ -0,0 +1,50 @@
|
|||||||
|
---
|
||||||
|
name: kg-graph-auditor
|
||||||
|
description: >
|
||||||
|
Use this agent to audit the structural integrity of the MCP memory-hub
|
||||||
|
knowledge graph. Detects orphaned entities, dangling relations, empty
|
||||||
|
entities, naming inconsistencies and entity-type sprawl. Read-only.
|
||||||
|
tools:
|
||||||
|
- mcp__memory__read_graph
|
||||||
|
- mcp__memory__search_nodes
|
||||||
|
- mcp__memory__open_nodes
|
||||||
|
model: sonnet
|
||||||
|
---
|
||||||
|
|
||||||
|
You audit the structural integrity of a knowledge graph. You never modify it.
|
||||||
|
|
||||||
|
## Procedure
|
||||||
|
1. Call `mcp__memory__read_graph` once to load the full graph.
|
||||||
|
2. Compute structural issues:
|
||||||
|
- **orphan_entity**: entity with zero relations (in or out).
|
||||||
|
- **dangling_relation**: a relation whose `from` or `to` names an entity
|
||||||
|
that does not exist.
|
||||||
|
- **empty_entity**: entity with zero observations.
|
||||||
|
- **naming_inconsistency**: mixed conventions (snake/kebab/Title Case,
|
||||||
|
singular/plural, language mixing) within the same entity type.
|
||||||
|
- **type_sprawl**: entity types used by only 1 entity, or near-synonym
|
||||||
|
types (e.g. `person` vs `human`, `service` vs `app`).
|
||||||
|
3. Assign severity (low/med/high). Dangling relations and empty core entities
|
||||||
|
are high; one-off naming is low.
|
||||||
|
|
||||||
|
## Output — return ONLY this JSON, nothing else
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"agent": "kg-graph-auditor",
|
||||||
|
"stats": {
|
||||||
|
"entities": 0,
|
||||||
|
"relations": 0,
|
||||||
|
"observations": 0,
|
||||||
|
"entity_types": { "<type>": 0 }
|
||||||
|
},
|
||||||
|
"issues": [
|
||||||
|
{ "type": "orphan_entity|dangling_relation|empty_entity|naming_inconsistency|type_sprawl",
|
||||||
|
"entity": "<name or null>",
|
||||||
|
"from": "<for relations>",
|
||||||
|
"to": "<for relations>",
|
||||||
|
"severity": "low|med|high",
|
||||||
|
"detail": "<one line>" }
|
||||||
|
]
|
||||||
|
}
|
||||||
|
```
|
||||||
|
Keep `detail` to one line each. Do not propose fixes — only report.
|
||||||
@@ -0,0 +1,48 @@
|
|||||||
|
---
|
||||||
|
name: kg-relation-miner
|
||||||
|
description: >
|
||||||
|
Use this agent to discover missing connections in the MCP memory-hub
|
||||||
|
knowledge graph. Finds entities that are semantically related but not linked,
|
||||||
|
proposes new relations with evidence, and suggests new relation types where
|
||||||
|
the existing vocabulary is too coarse. Read-only.
|
||||||
|
tools:
|
||||||
|
- mcp__memory__read_graph
|
||||||
|
- mcp__memory__search_nodes
|
||||||
|
- mcp__memory__open_nodes
|
||||||
|
model: opus
|
||||||
|
---
|
||||||
|
|
||||||
|
You discover missing links between existing entities. You never write to the
|
||||||
|
graph.
|
||||||
|
|
||||||
|
## Procedure
|
||||||
|
1. `mcp__memory__read_graph` to load entities, observations and current
|
||||||
|
relations.
|
||||||
|
2. Find entity pairs that SHOULD be connected but aren't. Evidence sources:
|
||||||
|
- an entity's observations mention another entity by name,
|
||||||
|
- shared context (same host, project, person, location),
|
||||||
|
- transitive gaps (A→B, B→C, but a meaningful A→C is implied),
|
||||||
|
- inverse relations missing (A `hosts` B but B has no `hosted_on` A, if the
|
||||||
|
graph's convention uses inverses).
|
||||||
|
3. Reuse existing `relationType` vocabulary where possible. Only propose a NEW
|
||||||
|
relation type when no existing one fits, and justify it.
|
||||||
|
4. Assign confidence 0.0–1.0 per suggestion. Cite the concrete evidence (the
|
||||||
|
observation text or shared attribute) — no speculative links.
|
||||||
|
|
||||||
|
## Output — return ONLY this JSON
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"agent": "kg-relation-miner",
|
||||||
|
"suggested_relations": [
|
||||||
|
{ "from": "<entity>",
|
||||||
|
"to": "<entity>",
|
||||||
|
"relationType": "<verb phrase>",
|
||||||
|
"confidence": 0.0,
|
||||||
|
"evidence": "<the observation or shared attribute that supports this>" }
|
||||||
|
],
|
||||||
|
"suggested_relation_types": [
|
||||||
|
{ "type": "<new relationType>", "reason": "<why existing vocab is insufficient>" }
|
||||||
|
]
|
||||||
|
}
|
||||||
|
```
|
||||||
|
Only include suggestions with confidence ≥ 0.5. Prefer existing relation types.
|
||||||
@@ -0,0 +1,44 @@
|
|||||||
|
---
|
||||||
|
name: kg-taxonomy-architect
|
||||||
|
description: >
|
||||||
|
Use this agent to design a clean entity-type taxonomy for the MCP memory-hub
|
||||||
|
knowledge graph. Proposes a coherent type hierarchy, naming conventions, and
|
||||||
|
a migration map from the current types to the proposed ones. Read-only —
|
||||||
|
produces a design, applies nothing.
|
||||||
|
tools:
|
||||||
|
- mcp__memory__read_graph
|
||||||
|
- mcp__memory__search_nodes
|
||||||
|
- mcp__memory__open_nodes
|
||||||
|
model: opus
|
||||||
|
---
|
||||||
|
|
||||||
|
You design the category structure (ontology) for a knowledge graph. You never
|
||||||
|
modify the graph.
|
||||||
|
|
||||||
|
## Procedure
|
||||||
|
1. `mcp__memory__read_graph` to load all entity types and how they are used.
|
||||||
|
2. Derive a clean, minimal type taxonomy:
|
||||||
|
- merge near-synonym types,
|
||||||
|
- introduce parent categories where a flat list has obvious groupings
|
||||||
|
(e.g. `proxmox-host`, `lxc`, `vm` → parent `infrastructure`),
|
||||||
|
- keep it as flat as possible while still useful — do not over-engineer.
|
||||||
|
3. Define naming conventions (case style, singular vs plural, language) and a
|
||||||
|
small set of explicit rules.
|
||||||
|
4. Produce a migration map: for every current type, what it becomes. Mark types
|
||||||
|
that stay unchanged.
|
||||||
|
|
||||||
|
## Output — return ONLY this JSON
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"agent": "kg-taxonomy-architect",
|
||||||
|
"proposed_taxonomy": [
|
||||||
|
{ "type": "<type>", "parent": "<parent type or null>", "description": "<one line>" }
|
||||||
|
],
|
||||||
|
"naming_rules": [ "<rule>" ],
|
||||||
|
"type_migration_map": [
|
||||||
|
{ "from_type": "<current>", "to_type": "<proposed>", "entities_affected": 0, "unchanged": false }
|
||||||
|
]
|
||||||
|
}
|
||||||
|
```
|
||||||
|
Favor the smallest taxonomy that cleanly covers the data. Note in a rule if a
|
||||||
|
proposed change is cosmetic-only.
|
||||||
@@ -0,0 +1,38 @@
|
|||||||
|
---
|
||||||
|
description: Apply an approved kg-changeset.json to the memory hub. Backs up the graph first; confirms each destructive operation.
|
||||||
|
allowed-tools:
|
||||||
|
- Read
|
||||||
|
- mcp__memory__read_graph
|
||||||
|
- mcp__memory__create_entities
|
||||||
|
- mcp__memory__create_relations
|
||||||
|
- mcp__memory__add_observations
|
||||||
|
- mcp__memory__delete_entities
|
||||||
|
- mcp__memory__delete_relations
|
||||||
|
- mcp__memory__delete_observations
|
||||||
|
---
|
||||||
|
|
||||||
|
You apply an approved change-set to the memory-hub knowledge graph. This is the
|
||||||
|
ONLY place that writes to the graph.
|
||||||
|
|
||||||
|
## Safety procedure — do not skip
|
||||||
|
1. **Backup first.** Call `mcp__memory__read_graph` and write the full dump to
|
||||||
|
`./kg-backup-<ISO-timestamp>.json`. Confirm the file exists before any write.
|
||||||
|
2. Read `./kg-changeset.json` (or the path in $ARGUMENTS).
|
||||||
|
3. Print a human-readable diff grouped by operation type
|
||||||
|
(merges, new_relations, deletions, type_migrations, renames) with counts.
|
||||||
|
4. **Ask for confirmation per destructive group.** Merges and deletions are
|
||||||
|
irreversible at the graph level — require an explicit "yes" for each group.
|
||||||
|
New relations and non-destructive adds can be batched after a single "yes".
|
||||||
|
5. Apply in this safe order:
|
||||||
|
1. create new entities / relations (additive, low risk),
|
||||||
|
2. add observations,
|
||||||
|
3. perform merges (re-point relations to canonical, copy observations,
|
||||||
|
then delete the redundant members),
|
||||||
|
4. apply type migrations / renames,
|
||||||
|
5. perform standalone deletions last.
|
||||||
|
6. After each group, re-read affected nodes to verify, and report what changed.
|
||||||
|
|
||||||
|
If `kg-changeset.json` is missing or malformed, stop and tell the user to run
|
||||||
|
`/kg-curate` first. Never invent changes that aren't in the change-set.
|
||||||
|
|
||||||
|
$ARGUMENTS
|
||||||
@@ -0,0 +1,10 @@
|
|||||||
|
---
|
||||||
|
description: Audit and restructure the MCP memory-hub knowledge graph (read-only). Produces a German report + kg-changeset.json.
|
||||||
|
---
|
||||||
|
|
||||||
|
Run the `knowledge-curator` skill: dispatch the four read-only KG subagents in
|
||||||
|
parallel, synthesize their findings into a German audit report, and write the
|
||||||
|
proposed change-set to `./kg-changeset.json`. Do not mutate the graph — stop
|
||||||
|
after presenting the report for review.
|
||||||
|
|
||||||
|
$ARGUMENTS
|
||||||
Executable
+64
@@ -0,0 +1,64 @@
|
|||||||
|
#!/usr/bin/env bash
|
||||||
|
# backup-memory.sh — PreToolUse hook for memory write tools.
|
||||||
|
# Snapshots the memory graph FILE before a write. Debounced so one apply-run
|
||||||
|
# produces a single backup. Never blocks the tool call (always exits 0).
|
||||||
|
#
|
||||||
|
# Config (env, all optional):
|
||||||
|
# KG_MEMORY_FILE explicit path to the MCP memory server's JSON store
|
||||||
|
# (falls back to MEMORY_FILE_PATH, the official server's var)
|
||||||
|
# KG_BACKUP_DIR where backups land (default: ~/.claude/kg-backups)
|
||||||
|
# KG_BACKUP_DEBOUNCE seconds; skip if a newer backup exists (default: 120)
|
||||||
|
# KG_BACKUP_KEEP how many backups to retain (default: 20)
|
||||||
|
#
|
||||||
|
# Tip: set KG_MEMORY_FILE in your shell / Claude Code env so the hook knows
|
||||||
|
# which file to copy. Without it the hook logs a notice and exits cleanly.
|
||||||
|
|
||||||
|
set -uo pipefail
|
||||||
|
|
||||||
|
# Drain stdin (hook receives JSON; we don't need it) so the pipe never blocks.
|
||||||
|
cat >/dev/null 2>&1 || true
|
||||||
|
|
||||||
|
MEM="${KG_MEMORY_FILE:-${MEMORY_FILE_PATH:-}}"
|
||||||
|
BACKUP_DIR="${KG_BACKUP_DIR:-$HOME/.claude/kg-backups}"
|
||||||
|
DEBOUNCE="${KG_BACKUP_DEBOUNCE:-120}"
|
||||||
|
KEEP="${KG_BACKUP_KEEP:-20}"
|
||||||
|
LOG="$BACKUP_DIR/backup.log"
|
||||||
|
|
||||||
|
note() { mkdir -p "$BACKUP_DIR" 2>/dev/null || true; echo "[$(date -Iseconds)] $*" >>"$LOG" 2>/dev/null || true; }
|
||||||
|
|
||||||
|
# No file configured or file missing -> notice + clean exit (never block writes).
|
||||||
|
if [ -z "$MEM" ]; then
|
||||||
|
note "no KG_MEMORY_FILE/MEMORY_FILE_PATH set; skipping file backup"
|
||||||
|
exit 0
|
||||||
|
fi
|
||||||
|
if [ ! -f "$MEM" ]; then
|
||||||
|
note "memory file not found at '$MEM'; skipping"
|
||||||
|
exit 0
|
||||||
|
fi
|
||||||
|
|
||||||
|
mkdir -p "$BACKUP_DIR" 2>/dev/null || { note "cannot create $BACKUP_DIR"; exit 0; }
|
||||||
|
|
||||||
|
# Debounce: if the newest existing backup is younger than DEBOUNCE seconds, skip.
|
||||||
|
newest="$(ls -t "$BACKUP_DIR"/kg-backup-*.json 2>/dev/null | head -n1 || true)"
|
||||||
|
if [ -n "$newest" ]; then
|
||||||
|
age=$(( $(date +%s) - $(stat -c %Y "$newest" 2>/dev/null || echo 0) ))
|
||||||
|
if [ "$age" -lt "$DEBOUNCE" ]; then
|
||||||
|
note "debounced (last backup ${age}s ago < ${DEBOUNCE}s)"
|
||||||
|
exit 0
|
||||||
|
fi
|
||||||
|
fi
|
||||||
|
|
||||||
|
ts="$(date +%Y%m%dT%H%M%S)"
|
||||||
|
dest="$BACKUP_DIR/kg-backup-$ts.json"
|
||||||
|
if cp "$MEM" "$dest" 2>/dev/null; then
|
||||||
|
note "backup ok -> $dest"
|
||||||
|
else
|
||||||
|
note "backup FAILED copying $MEM"
|
||||||
|
exit 0
|
||||||
|
fi
|
||||||
|
|
||||||
|
# Prune: keep only the most recent $KEEP backups.
|
||||||
|
mapfile -t old < <(ls -t "$BACKUP_DIR"/kg-backup-*.json 2>/dev/null | tail -n +"$((KEEP+1))")
|
||||||
|
for f in "${old[@]:-}"; do [ -n "$f" ] && rm -f "$f" 2>/dev/null || true; done
|
||||||
|
|
||||||
|
exit 0
|
||||||
@@ -0,0 +1,14 @@
|
|||||||
|
{
|
||||||
|
"PreToolUse": [
|
||||||
|
{
|
||||||
|
"matcher": "mcp__memory__(create|add|delete)_.*",
|
||||||
|
"hooks": [
|
||||||
|
{
|
||||||
|
"type": "command",
|
||||||
|
"command": "bash ${CLAUDE_PLUGIN_ROOT}/hooks/backup-memory.sh",
|
||||||
|
"timeout": 15
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
@@ -0,0 +1,88 @@
|
|||||||
|
---
|
||||||
|
name: knowledge-curator
|
||||||
|
description: >
|
||||||
|
Audits and restructures the MCP memory-hub knowledge graph. Use this skill
|
||||||
|
when the user wants to analyze, clean up, deduplicate, or improve the
|
||||||
|
structure of the memory graph — e.g. "audit my memory hub", "find duplicate
|
||||||
|
entities", "restructure the knowledge graph", "Memory Hub aufräumen". Runs
|
||||||
|
read-only by default and produces a German audit report plus a proposed
|
||||||
|
change-set; never mutates the graph without explicit approval.
|
||||||
|
---
|
||||||
|
|
||||||
|
# Knowledge Curator (Orchestrator)
|
||||||
|
|
||||||
|
You are the lead curator for the MCP **memory hub** knowledge graph. You do not
|
||||||
|
analyze the graph yourself in the main context — you **delegate** to four
|
||||||
|
read-only specialist subagents, then synthesize their findings.
|
||||||
|
|
||||||
|
## Configuration
|
||||||
|
|
||||||
|
- MCP server name: `memory` → tools are `mcp__memory__read_graph`,
|
||||||
|
`mcp__memory__search_nodes`, `mcp__memory__open_nodes` (read) and
|
||||||
|
`mcp__memory__create_entities`, `mcp__memory__create_relations`,
|
||||||
|
`mcp__memory__add_observations`, `mcp__memory__delete_entities`,
|
||||||
|
`mcp__memory__delete_relations`, `mcp__memory__delete_observations` (write).
|
||||||
|
- If your server is named differently or exposes different tool names
|
||||||
|
(e.g. `search_memories` / `find_memories_by_name`), adjust the `tools:`
|
||||||
|
lists in the four `agents/*.md` files accordingly. Confirm
|
||||||
|
with `claude mcp list` or `/mcp`.
|
||||||
|
- **Report language: German.** Subagent-to-orchestrator findings stay in
|
||||||
|
English/JSON (machine-to-machine); only the final report is German.
|
||||||
|
|
||||||
|
## Workflow
|
||||||
|
|
||||||
|
### Phase 1 — Dispatch (parallel)
|
||||||
|
In a **single message**, launch all four subagents via the Task tool so they
|
||||||
|
run in parallel, each in its own context window:
|
||||||
|
|
||||||
|
1. `kg-graph-auditor` — structural integrity
|
||||||
|
2. `kg-entity-deduplicator` — overlap / duplicate detection
|
||||||
|
3. `kg-relation-miner` — missing-link discovery
|
||||||
|
4. `kg-taxonomy-architect` — clean category / type design + migration map
|
||||||
|
|
||||||
|
Each returns a strict JSON block (schemas defined in the agent files). Do not
|
||||||
|
proceed until all four have returned.
|
||||||
|
|
||||||
|
### Phase 2 — Synthesize
|
||||||
|
Merge the four JSON results. Resolve overlaps (e.g. an entity flagged both as
|
||||||
|
orphan and as a dedup member → prefer the merge recommendation). Rank every
|
||||||
|
finding by severity/confidence.
|
||||||
|
|
||||||
|
### Phase 3 — Report (German)
|
||||||
|
Produce a Markdown report with this structure:
|
||||||
|
|
||||||
|
```
|
||||||
|
# Memory-Hub Audit — <Datum>
|
||||||
|
## Zusammenfassung (3–5 Sätze, wichtigste Befunde + Empfehlung)
|
||||||
|
## Statistik (Entities, Relations, Observations, Typ-Verteilung)
|
||||||
|
## Strukturbefunde (priorisiert: Orphans, Dangling Relations, leere Entities, Naming)
|
||||||
|
## Dubletten & Überschneidungen (Merge-Cluster mit Confidence + Begründung)
|
||||||
|
## Vorgeschlagene Verknüpfungen (neue Relations mit Evidenz)
|
||||||
|
## Taxonomie-Vorschlag (Ziel-Typhierarchie + Naming-Regeln + Migrations-Map)
|
||||||
|
## Empfohlenes Vorgehen (Reihenfolge, Risiko, was zuerst)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Phase 4 — Change-set (no mutation)
|
||||||
|
Write the consolidated, machine-readable proposal to
|
||||||
|
`./kg-changeset.json` with this shape:
|
||||||
|
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"generated": "<ISO-8601>",
|
||||||
|
"merges": [ { "canonical": "...", "members": ["..."], "confidence": 0.0 } ],
|
||||||
|
"new_relations": [ { "from": "...", "to": "...", "relationType": "...", "confidence": 0.0 } ],
|
||||||
|
"deletions": [ { "entity": "...", "reason": "..." } ],
|
||||||
|
"type_migrations": [ { "entity": "...", "from_type": "...", "to_type": "..." } ],
|
||||||
|
"rename_suggestions": [ { "from": "...", "to": "...", "reason": "..." } ]
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
Then **stop**. End in Plan-Phase: present the report, point at `kg-changeset.json`,
|
||||||
|
and ask the user to review. Do **not** call any `create_*`/`delete_*`/`add_*`
|
||||||
|
tool in this skill. Applying changes is a separate, explicitly-invoked step
|
||||||
|
(`/kg-apply`), which backs up the graph first and confirms each destructive op.
|
||||||
|
|
||||||
|
## Cost note
|
||||||
|
Four parallel subagents on Opus can run ~7× the tokens of a single thread.
|
||||||
|
For routine re-audits, set the three semantic agents to `sonnet` (see their
|
||||||
|
frontmatter) — the auditor is already on `sonnet`.
|
||||||
@@ -0,0 +1,5 @@
|
|||||||
|
{
|
||||||
|
"name": "knowledge-curator",
|
||||||
|
"source": "./knowledge-curator",
|
||||||
|
"description": "Memory-Hub Knowledge-Graph audit & restructuring: structural integrity, dedup, link discovery, taxonomy design (4 read-only subagents). Read-only by default; mutations explicit + backed up."
|
||||||
|
}
|
||||||
Executable
+43
@@ -0,0 +1,43 @@
|
|||||||
|
#!/usr/bin/env bash
|
||||||
|
# push-to-gitea.sh — publish THIS folder (the marketplace root) to your Gitea
|
||||||
|
# repo l.kirchner/claude-marketplace. Run from inside this folder.
|
||||||
|
#
|
||||||
|
# The repo was created empty, so this sets up clean history with your first push.
|
||||||
|
# Commits use your local git signing config (commit.gpgsign etc.) untouched.
|
||||||
|
#
|
||||||
|
# ./push-to-gitea.sh
|
||||||
|
# REMOTE_URL=https://gitea.luki-net.org/l.kirchner/claude-marketplace.git ./push-to-gitea.sh
|
||||||
|
set -euo pipefail
|
||||||
|
|
||||||
|
REMOTE_URL="${REMOTE_URL:-ssh://git@gitea.luki-net.org:2222/l.kirchner/claude-marketplace.git}"
|
||||||
|
BRANCH="${BRANCH:-main}"
|
||||||
|
|
||||||
|
[ -f ".claude-plugin/marketplace.json" ] || {
|
||||||
|
echo "ERROR: run this from the marketplace root (no .claude-plugin/marketplace.json here)." >&2
|
||||||
|
exit 1
|
||||||
|
}
|
||||||
|
|
||||||
|
if [ ! -d .git ]; then
|
||||||
|
git init -b "$BRANCH"
|
||||||
|
fi
|
||||||
|
|
||||||
|
if git remote get-url origin >/dev/null 2>&1; then
|
||||||
|
git remote set-url origin "$REMOTE_URL"
|
||||||
|
else
|
||||||
|
git remote add origin "$REMOTE_URL"
|
||||||
|
fi
|
||||||
|
|
||||||
|
git add -A
|
||||||
|
# --gpg-sign respects your config; drop the flag if you don't sign locally.
|
||||||
|
git commit -m "feat: knowledge-curator plugin + marketplace manifest" || {
|
||||||
|
echo "Nothing to commit (already committed?). Continuing to push." >&2
|
||||||
|
}
|
||||||
|
git push -u origin "$BRANCH"
|
||||||
|
|
||||||
|
cat <<EOF
|
||||||
|
|
||||||
|
>> Pushed to $REMOTE_URL ($BRANCH)
|
||||||
|
>> In Claude Code:
|
||||||
|
/plugin marketplace add https://gitea.luki-net.org/l.kirchner/claude-marketplace
|
||||||
|
/plugin install knowledge-curator@luki-net
|
||||||
|
EOF
|
||||||
@@ -0,0 +1,19 @@
|
|||||||
|
{
|
||||||
|
"name": "venture",
|
||||||
|
"version": "0.1.0",
|
||||||
|
"description": "Venture-Set: Skills zum Erstellen kohaerenter Founder-/Fundraising-/GTM-Materialien aus einer gemeinsamen Wissensbasis. Enthaelt Pitch-Deck-Builder, Investor-Materials-Konsistenz, SaaS-Finanzmodell, Marktanalyse und Executive-Summary-Writer.",
|
||||||
|
"author": {
|
||||||
|
"name": "LuKi-Net"
|
||||||
|
},
|
||||||
|
"keywords": [
|
||||||
|
"venture",
|
||||||
|
"founder",
|
||||||
|
"fundraising",
|
||||||
|
"pitch-deck",
|
||||||
|
"investor",
|
||||||
|
"saas",
|
||||||
|
"financial-model",
|
||||||
|
"market-research",
|
||||||
|
"go-to-market"
|
||||||
|
]
|
||||||
|
}
|
||||||
@@ -0,0 +1,193 @@
|
|||||||
|
---
|
||||||
|
name: executive-summary-writer
|
||||||
|
description: Use this skill when the user needs a concise executive-level summary - a one-pager, two-pager, briefing memo, investor one-pager, sales one-pager, or condensed version of a larger document. Triggers include 'One-Pager', 'Executive Summary', 'Zusammenfassung', 'Briefing', 'Kurzfassung', 'Investor One-Pager', 'Sales-Material', 'Verkaufs-One-Pager'. Skill produces audience-tailored, scannable, story-driven summaries as .docx or .pdf via document-skills. Skip for full multi-page reports or pitch decks (use other venture skills).
|
||||||
|
---
|
||||||
|
|
||||||
|
# Executive Summary Writer
|
||||||
|
|
||||||
|
## Mission
|
||||||
|
|
||||||
|
Erzeuge knappe, scannbare, story-getriebene Zusammenfassungen, die in 90 Sekunden Lese-Zeit eine fundierte Reaktion ermoeglichen. Das Format passt sich der Zielgruppe an: Investoren wollen Zahlen und Ask, Vertriebler wollen Argumente und Differenzierung, Partner wollen Win-Win-Logik. Konsistenz mit allen anderen Materialien via Anchor-File ist Pflicht.
|
||||||
|
|
||||||
|
## Wann aktivieren
|
||||||
|
|
||||||
|
Bei Anfragen nach One-Pager, Executive Summary, Briefing-Memo, Zusammenfassung, Kurzfassung. Nicht aktivieren bei:
|
||||||
|
|
||||||
|
- Pitch Decks (→ `pitch-deck-builder`)
|
||||||
|
- vollstaendige Konzept-Dokumente (>5 Seiten, anderer Use-Case)
|
||||||
|
- E-Mail-Drafts (kein eigenstaendiges Deliverable)
|
||||||
|
|
||||||
|
## Workflow
|
||||||
|
|
||||||
|
### Schritt 1 — Zielgruppe und Format klaeren
|
||||||
|
|
||||||
|
Frage **immer** zuerst:
|
||||||
|
|
||||||
|
1. **Wer ist die Zielperson?** Investor (Angel/Seed-VC/strategisch) / Vertriebs-Prospect / Partner / Berater / interne Stakeholder
|
||||||
|
2. **Welches Format?**
|
||||||
|
- One-Pager (1 Seite, max. 350 Worte) — fuer Erst-Touchpoint
|
||||||
|
- Two-Pager (2 Seiten, max. 700 Worte) — fuer ernsthaften Erst-Termin
|
||||||
|
- Briefing-Memo (3-5 Seiten) — fuer formelle Follow-up-Vorlage
|
||||||
|
3. **Welches Ziel?** Termin-Vereinbarung / Geld / Beratung / Pilot-Tenant-Gewinnung / Empfehlung
|
||||||
|
|
||||||
|
### Schritt 2 — Anchor-Daten ziehen
|
||||||
|
|
||||||
|
Lies zwingend (falls vorhanden):
|
||||||
|
|
||||||
|
- `inputs/investor-anchors.md` — alle Zahlen, Tagline, One-Liner, Ask
|
||||||
|
- `CLAUDE.md` — Ton, Markenidentitaet
|
||||||
|
- relevantes existierendes Pitch-Deck oder Konzept als Story-Quelle
|
||||||
|
|
||||||
|
Wenn `investor-anchors.md` Werte fehlen, frage gezielt nach — niemals erfinden.
|
||||||
|
|
||||||
|
### Schritt 3 — Story-Arc je nach Zielgruppe
|
||||||
|
|
||||||
|
**Investor-One-Pager** (Default-Struktur):
|
||||||
|
|
||||||
|
```
|
||||||
|
[Tagline - max. 12 Worte, fett, gross]
|
||||||
|
|
||||||
|
[One-Liner - 1 Satz, was ist das Produkt + Wer ist die Zielgruppe]
|
||||||
|
|
||||||
|
PROBLEM
|
||||||
|
2-3 Saetze. Konkret, mit einer Zahl belegt.
|
||||||
|
|
||||||
|
LOESUNG
|
||||||
|
2-3 Saetze. Wie loesen wir das? Was ist anders?
|
||||||
|
|
||||||
|
TRACTION
|
||||||
|
3-4 Bullets mit Pilot-Tenants, Pipeline, MRR/ARR, LOIs.
|
||||||
|
|
||||||
|
MARKT
|
||||||
|
TAM/SAM/SOM in einer Zeile pro Wert mit Quellenhinweis.
|
||||||
|
|
||||||
|
GESCHAEFTSMODELL
|
||||||
|
1-2 Saetze. Tarif-Struktur, ARPA-Range.
|
||||||
|
|
||||||
|
TEAM
|
||||||
|
3-4 Bullets, je Gruender 1 Satz mit relevantester Vita.
|
||||||
|
|
||||||
|
ASK
|
||||||
|
- Hoehe: ...
|
||||||
|
- Use-of-Funds: ... (3-4 Schwerpunkte)
|
||||||
|
- Meilensteine: ... (3 wichtigste)
|
||||||
|
|
||||||
|
Kontakt: Name, Email, Telefon, Website
|
||||||
|
```
|
||||||
|
|
||||||
|
**Vertriebs-One-Pager** (zielgruppen-/branchen-spezifisch):
|
||||||
|
|
||||||
|
```
|
||||||
|
[Branchen-Tagline - z.B. "KI-Plattform fuer Kurverwaltungen"]
|
||||||
|
|
||||||
|
DAS PROBLEM IN IHRER BRANCHE
|
||||||
|
2-3 Saetze. Branchen-spezifisch, nicht generisch.
|
||||||
|
|
||||||
|
UNSERE LOESUNG
|
||||||
|
3-4 Bullets: was kann das Produkt konkret?
|
||||||
|
|
||||||
|
WAS UNS ANDERS MACHT
|
||||||
|
3 Bullets:
|
||||||
|
- DSGVO-On-Prem oder EU-Cloud
|
||||||
|
- BFSG-konform out-of-the-box
|
||||||
|
- Branchen-Templates und -Vokabular
|
||||||
|
|
||||||
|
REFERENZEN / PILOT-TENANTS
|
||||||
|
2-3 anonyme Cases mit konkretem Nutzen, oder LOIs.
|
||||||
|
|
||||||
|
PREIS-MODELL (3 Tarife)
|
||||||
|
| Basic | Pro | Enterprise |
|
||||||
|
mit Range pro Tarif.
|
||||||
|
|
||||||
|
NAECHSTER SCHRITT
|
||||||
|
30-Min Demo / Pilot-Programm / Ansprechpartner
|
||||||
|
|
||||||
|
Kontakt: ...
|
||||||
|
```
|
||||||
|
|
||||||
|
**Partner-One-Pager** (fuer strategische Helfer / Vertriebs-Beraterinnen):
|
||||||
|
|
||||||
|
```
|
||||||
|
[Tagline]
|
||||||
|
|
||||||
|
WAS WIR BAUEN
|
||||||
|
1 Absatz, konkret.
|
||||||
|
|
||||||
|
WO WIR STEHEN
|
||||||
|
Aktuelle Lage, Pilot-Tenants, Roadmap.
|
||||||
|
|
||||||
|
WORIN WIR UNTERSTUETZUNG SUCHEN
|
||||||
|
Konkret: "Wir suchen Zugang zu X / Empfehlung an Y / Beratung zu Z" — nicht vage.
|
||||||
|
|
||||||
|
WAS WIR ANBIETEN
|
||||||
|
Konkretes Angebot fuer Partner (Equity / Revenue-Share / Beraterhonorar / Co-Branding).
|
||||||
|
|
||||||
|
WARUM JETZT
|
||||||
|
1-2 Saetze, Timing-Argument.
|
||||||
|
|
||||||
|
NAECHSTER SCHRITT
|
||||||
|
30-Min-Gespraech / Termin-Vorschlag.
|
||||||
|
|
||||||
|
Kontakt: ...
|
||||||
|
```
|
||||||
|
|
||||||
|
### Schritt 4 — Sprache und Stil
|
||||||
|
|
||||||
|
Anforderungen an jeden Output:
|
||||||
|
|
||||||
|
- **Aktiv statt Passiv**: "Wir verarbeiten ..." nicht "Wird verarbeitet ..."
|
||||||
|
- **Konkret statt abstrakt**: "spart 2 Std/Woche pro Mitarbeiter" nicht "spart Zeit"
|
||||||
|
- **Eine Idee pro Absatz** — keine verschachtelten Argumente
|
||||||
|
- **Zahlen vor Adjektive**: "300 Kurverwaltungen in DE" nicht "viele Kurverwaltungen"
|
||||||
|
- **Keine Buzzwords** ohne Konkretion ("KI-getrieben" ohne zu sagen WIE)
|
||||||
|
- **Sprache spiegelt Zielgruppe**: Investor knapp/zahlen-fokussiert, Vertrieb branchen-vokabular, Partner gegenseitige-Nutzen-Logik
|
||||||
|
|
||||||
|
### Schritt 5 — Layout-Vorgaben
|
||||||
|
|
||||||
|
Fuer One-Pager (1 Seite):
|
||||||
|
|
||||||
|
- Format A4 hochkant
|
||||||
|
- Header mit Logo + Tagline (oben, ca. 15 % der Seite)
|
||||||
|
- 2-Spalten-Layout fuer Body (oder klare visuelle Sektion)
|
||||||
|
- max. 11pt Body-Font, 14pt Header
|
||||||
|
- Footer mit Kontakt, Datum, "vertraulich" wenn relevant
|
||||||
|
|
||||||
|
Fuer Two-Pager:
|
||||||
|
|
||||||
|
- Format A4 hochkant, 2 Seiten
|
||||||
|
- Seite 1: Tagline + Problem + Loesung + Traction + Markt
|
||||||
|
- Seite 2: Geschaeftsmodell + Team + Ask + Kontakt
|
||||||
|
|
||||||
|
Nutze das **docx-document-skill** zum Erstellen, danach optional pdf-Export ueber pdf-document-skill.
|
||||||
|
|
||||||
|
### Schritt 6 — Konsistenz-Check
|
||||||
|
|
||||||
|
Vor dem Speichern: vergleiche alle Zahlen mit `inputs/investor-anchors.md`. Markiere Abweichungen mit `[KONFLIKT mit Anchor: ...]` und frage den User.
|
||||||
|
|
||||||
|
Speichere als:
|
||||||
|
- `deliverables/<Projekt>_One-Pager_<Zielgruppe>_<Datum>.docx` (+ .pdf)
|
||||||
|
|
||||||
|
Beispiel-Naming:
|
||||||
|
- `Atlas_One-Pager_Investor_2026-05-28.docx`
|
||||||
|
- `Atlas_One-Pager_Vertrieb-Kurverwaltung_2026-05-28.docx`
|
||||||
|
- `Atlas_One-Pager_Partner-Vertrieb_2026-05-28.docx`
|
||||||
|
|
||||||
|
### Schritt 7 — Varianten-Hinweis
|
||||||
|
|
||||||
|
Wenn der User mehrere Zielgruppen anspricht, erzeuge **separate** One-Pager statt eines generischen. Generische One-Pager unterperformen — 90 Sekunden Lesezeit verzeihen keine schwammige Zielgruppen-Ansprache.
|
||||||
|
|
||||||
|
## Anti-Patterns (vermeiden)
|
||||||
|
|
||||||
|
- Generischer One-Pager fuer "alle Zielgruppen"
|
||||||
|
- Tagline > 12 Worte
|
||||||
|
- Mehrere konkurrierende One-Liner ("wir sind X und Y und auch Z")
|
||||||
|
- Ask ohne konkrete Hoehe
|
||||||
|
- Use-of-Funds ohne Meilenstein-Verknuepfung
|
||||||
|
- "Team-Bullets" als reine Job-Titel-Aufzaehlung ohne Differenzierung
|
||||||
|
- Marketing-Buzzwords ("disruptive", "revolutionaer", "next-gen") ohne Substanz
|
||||||
|
|
||||||
|
## Querverweise
|
||||||
|
|
||||||
|
- Nutzt: `docx`, `pdf` (document-skills)
|
||||||
|
- Konsumiert: `inputs/investor-anchors.md` (Single Source of Truth), ggf. existierendes Pitch-Deck
|
||||||
|
- Kooperiert mit: `investor-materials` (Anchor-Pflege), `pitch-deck-builder` (Story-Konsistenz)
|
||||||
@@ -0,0 +1,146 @@
|
|||||||
|
---
|
||||||
|
name: investor-materials
|
||||||
|
description: Use this skill whenever the user is creating, updating, or reviewing multiple investor-facing assets (pitch deck, one-pager, financial model, investor memo, executive summary, due-diligence room) and consistency between them matters. Activate when work spans more than one deliverable, when the user mentions 'consistent', 'einheitlich', 'gleiche Zahlen ueberall', 'investor package', 'fundraising assets' or when reviewing/updating an existing set of investor docs. Skill enforces a single source of truth, prevents drift between documents, and flags inconsistencies. Skip for single one-off documents with no cross-doc concerns.
|
||||||
|
---
|
||||||
|
|
||||||
|
# Investor Materials Consistency Steward
|
||||||
|
|
||||||
|
## Mission
|
||||||
|
|
||||||
|
Sichere Konsistenz und Glaubwuerdigkeit aller investor-facing Materialien (Pitch Deck, Finanzmodell, One-Pager, Memos, Executive Summary, Due-Diligence-Raum). Verhindere die haeufigste Fundraising-Falle: widerspruechliche Zahlen oder Aussagen zwischen Dokumenten, die in der Due Diligence sofort auffallen und Vertrauen kosten.
|
||||||
|
|
||||||
|
Dieses Skill steht **ueber** den einzelnen Dokumenten-Skills (`pitch-deck-builder`, `saas-financial-projections`, `executive-summary-writer`, `market-research`) und koordiniert sie.
|
||||||
|
|
||||||
|
## Wann aktivieren
|
||||||
|
|
||||||
|
Aktiviere wenn:
|
||||||
|
|
||||||
|
- mehr als ein investor-facing Dokument im Spiel ist
|
||||||
|
- der User Konsistenz explizit verlangt (`konsistent`, `single source of truth`, `gleiche Zahlen`)
|
||||||
|
- ein bestehendes Material-Set ueberarbeitet wird (z.B. neue Funding-Round, neue Zahlen)
|
||||||
|
- die User-Frage ein "Investor-Paket" oder "Fundraising-Stack" referenziert
|
||||||
|
|
||||||
|
Nicht aktivieren bei einzelnen einmaligen Dokumenten ohne Cross-Doc-Bezug.
|
||||||
|
|
||||||
|
## Workflow
|
||||||
|
|
||||||
|
### Schritt 1 — Anchor-File etablieren
|
||||||
|
|
||||||
|
Lege oder pruefe die zentrale Wahrheits-Datei: `inputs/investor-anchors.md` mit folgenden Sektionen:
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
# Investor Anchors — verbindliche Werte fuer alle Materialien
|
||||||
|
|
||||||
|
## Identitaet
|
||||||
|
- Firmenname:
|
||||||
|
- Produktname:
|
||||||
|
- Tagline (max. 12 Worte):
|
||||||
|
- One-Liner (1 Satz):
|
||||||
|
|
||||||
|
## Markt
|
||||||
|
- TAM (mit Quelle + Jahr):
|
||||||
|
- SAM (mit Quelle + Jahr):
|
||||||
|
- SOM (mit Quelle + Begruendung):
|
||||||
|
- Marktwachstum p.a.:
|
||||||
|
|
||||||
|
## Geschaeftsmodell
|
||||||
|
- Tarif-Modell (kurz):
|
||||||
|
- Average Revenue Per Account (ARPA):
|
||||||
|
- Gross-Margin-Ziel:
|
||||||
|
|
||||||
|
## Aktuelle Lage
|
||||||
|
- Stand: (Datum)
|
||||||
|
- MRR / ARR aktuell:
|
||||||
|
- Tenants / Kunden aktuell:
|
||||||
|
- Pipeline (qualifiziert):
|
||||||
|
- Cash on hand:
|
||||||
|
- Burn-Rate (monatlich):
|
||||||
|
- Runway:
|
||||||
|
|
||||||
|
## Forecast-Anker
|
||||||
|
- ARR-Ziel Year-1 / Year-2 / Year-3:
|
||||||
|
- Tenants Year-1 / Year-2 / Year-3:
|
||||||
|
- Break-Even (Quartal):
|
||||||
|
|
||||||
|
## Ask
|
||||||
|
- Funding-Hoehe:
|
||||||
|
- Pre-Money-Bewertung (falls genannt):
|
||||||
|
- Use-of-Funds (Aufteilung in %):
|
||||||
|
- Milestones, die mit dem Geld erreicht werden:
|
||||||
|
|
||||||
|
## Team
|
||||||
|
- Gruender + Schluesselrollen (Name, Rolle, 1-Satz-Erfahrung):
|
||||||
|
|
||||||
|
## Wettbewerber (Top 3-5)
|
||||||
|
- pro Wettbewerber: Name, Positionierung, eigene Differenzierung
|
||||||
|
|
||||||
|
## Risiken (Top 3)
|
||||||
|
- pro Risiko: Beschreibung, Mitigation
|
||||||
|
```
|
||||||
|
|
||||||
|
Wenn diese Datei nicht existiert, erzeuge sie aus vorhandenen Inputs und frage gezielt nach den fehlenden Werten. **Niemals erfinden.**
|
||||||
|
|
||||||
|
### Schritt 2 — Cross-Doc-Consistency-Check
|
||||||
|
|
||||||
|
Bevor du irgendein investor-facing Material veraenderst:
|
||||||
|
|
||||||
|
1. Identifiziere alle existierenden Materialien in `deliverables/`:
|
||||||
|
- `*Pitch-Deck*.pptx`
|
||||||
|
- `*Finanzmodell*.xlsx`
|
||||||
|
- `*Executive-Summary*.pdf` / `*.docx`
|
||||||
|
- `*Investor-Memo*.pdf` / `*.docx`
|
||||||
|
- `*One-Pager*.pdf`
|
||||||
|
|
||||||
|
2. Extrahiere die zentralen Zahlen aus jedem Dokument (ARR, MRR, Tenants, Burn, Runway, Ask, TAM-Werte).
|
||||||
|
|
||||||
|
3. Vergleiche mit `inputs/investor-anchors.md`.
|
||||||
|
|
||||||
|
4. Erzeuge `notes/consistency-check_<Datum>.md` mit:
|
||||||
|
- **Konsistent**: Liste der Werte, die in allen Dokumenten uebereinstimmen
|
||||||
|
- **Drift**: Liste der Diskrepanzen mit Dokument-Pfaden und beiden Werten
|
||||||
|
- **Fehlend**: Werte, die im Anchor stehen, aber in einem Dokument nicht erscheinen
|
||||||
|
- **Nicht-im-Anchor**: Werte in Dokumenten, die nicht im Anchor verankert sind
|
||||||
|
|
||||||
|
### Schritt 3 — Drift-Bereinigung
|
||||||
|
|
||||||
|
Wenn Drift gefunden wird:
|
||||||
|
|
||||||
|
- Frage den User: *Welcher Wert ist der korrekte? (a) Anchor, (b) Dokument X, (c) neuer Wert*
|
||||||
|
- Aktualisiere zuerst den Anchor (Single Source of Truth)
|
||||||
|
- Aktualisiere dann alle abweichenden Dokumente per Hand-off an deren jeweiliges Skill (`pitch-deck-builder` aktualisiert Deck, `saas-financial-projections` aktualisiert Modell, etc.)
|
||||||
|
|
||||||
|
### Schritt 4 — Vor jedem Doc-Create
|
||||||
|
|
||||||
|
Wenn ein anderes venture-Skill ein neues Dokument erzeugt, fordere als upstream-Aktion:
|
||||||
|
|
||||||
|
- Lies `inputs/investor-anchors.md`
|
||||||
|
- Verwende nur Anchor-Werte; markiere alles andere als `[ANNAHME: ...]`
|
||||||
|
- Liefere am Ende eine "Anchor-Konsistenz-Bestaetigung": welche Anchor-Werte wurden verwendet?
|
||||||
|
|
||||||
|
### Schritt 5 — Investor-Paket-Erstellung
|
||||||
|
|
||||||
|
Wenn der User ein vollstaendiges Investor-Paket wuenscht, schlage diese Reihenfolge vor:
|
||||||
|
|
||||||
|
1. **`market-research`** liefert TAM/SAM/SOM → in Anchor schreiben
|
||||||
|
2. **`saas-financial-projections`** liefert Forecast → in Anchor schreiben
|
||||||
|
3. **`investor-materials`** (dieses Skill) finalisiert den Anchor
|
||||||
|
4. **`pitch-deck-builder`** baut das Deck (liest Anchor)
|
||||||
|
5. **`executive-summary-writer`** baut One-Pager + 2-Pager (liest Anchor)
|
||||||
|
6. Optional: Memo-Variante (2-3 Seiten, liest Anchor)
|
||||||
|
|
||||||
|
Diese Reihenfolge ist nicht zwingend, aber sie minimiert Re-Work.
|
||||||
|
|
||||||
|
## Anti-Patterns (vermeiden)
|
||||||
|
|
||||||
|
- Zahlen direkt in Dokumenten aendern, ohne den Anchor anzupassen → unvermeidliche Drift
|
||||||
|
- Verschiedene MRR/ARR-Werte aus "verschiedenen Stichtagen" zwischen Deck und Modell → Investoren misstrauen sofort
|
||||||
|
- "Use-of-Funds %" passt nicht zum Ask in Euro
|
||||||
|
- Tenant-Zahlen Year-2 im Deck != Modell-Forecast
|
||||||
|
- Wettbewerbs-Differenzierung im Deck != im One-Pager
|
||||||
|
- Tagline-Drift zwischen Materialien
|
||||||
|
|
||||||
|
## Querverweise
|
||||||
|
|
||||||
|
- Steuert / koordiniert: `pitch-deck-builder`, `saas-financial-projections`, `executive-summary-writer`
|
||||||
|
- Konsumiert: `market-research` (TAM/SAM/SOM in Anchor)
|
||||||
|
- Persistenz: `inputs/investor-anchors.md` (zentraler Anker), `notes/consistency-check_<Datum>.md` (Audit-Trail)
|
||||||
@@ -0,0 +1,163 @@
|
|||||||
|
---
|
||||||
|
name: market-research
|
||||||
|
description: Use this skill when the user asks for market sizing (TAM/SAM/SOM), competitive landscape analysis, market opportunity validation, industry trends, or due-diligence-grade market research. Triggers include 'Marktanalyse', 'TAM/SAM/SOM', 'Marktgroesse', 'Wettbewerber', 'Wettbewerbsanalyse', 'competitive landscape', 'market opportunity', 'Branchen-Brief'. Skill produces a sourced, structured market brief as .md and optionally .pdf, using web search rigorously and distinguishing between fact, inference, and recommendation. Skip for casual market questions or product feature comparisons.
|
||||||
|
---
|
||||||
|
|
||||||
|
# Market Research & Competitive Analysis
|
||||||
|
|
||||||
|
## Mission
|
||||||
|
|
||||||
|
Liefere eine due-diligence-faehige Marktanalyse, die Investor-Pruefung standhaelt. Trenne strikt zwischen Fakt (mit Quelle), Inferenz (eigene Schlussfolgerung) und Empfehlung (subjektive Bewertung). Jede Zahl ist quellenbelegt — keine erfundenen Marktgroessen.
|
||||||
|
|
||||||
|
## Wann aktivieren
|
||||||
|
|
||||||
|
Bei Anfragen nach Marktgroesse, TAM/SAM/SOM-Berechnung, Wettbewerbsanalyse, Branchen-Briefs, Markt-Opportunity-Validierung. Nicht aktivieren fuer:
|
||||||
|
|
||||||
|
- casual Markt-Fragen ohne Quellen-Anspruch
|
||||||
|
- Produkt-Feature-Vergleiche ohne Marktkontext
|
||||||
|
- Customer-Interviews / qualitative Discovery (anderes Werkzeug)
|
||||||
|
|
||||||
|
## Workflow
|
||||||
|
|
||||||
|
### Schritt 1 — Scope abstecken
|
||||||
|
|
||||||
|
Klaere mit dem User vor jeder Recherche:
|
||||||
|
|
||||||
|
- **Geografie**: DACH / EU / global / nationaler Markt? Atlas-LuKi-Net-Default ist DACH-Mittelstand.
|
||||||
|
- **Branche / Vertical**: Branchen-agnostisch oder spitz (z.B. nur Kurverwaltungen, nur Verlage)?
|
||||||
|
- **Zeit-Horizont**: aktuelles Jahr / 5-Jahres-Projektion?
|
||||||
|
- **Detailtiefe**: Brief (5-8 Seiten) vs. Tiefenanalyse (15+ Seiten)?
|
||||||
|
- **Zielgruppe des Outputs**: Investor / Vertrieb / interne Roadmap-Validierung?
|
||||||
|
|
||||||
|
### Schritt 2 — TAM/SAM/SOM strukturieren
|
||||||
|
|
||||||
|
Berechne in drei Schritten, jeweils mit expliziter Methodik:
|
||||||
|
|
||||||
|
**TAM (Total Addressable Market)** — das gesamte adressierbare Marktvolumen, wenn jedes potentielle Konto gewonnen wuerde.
|
||||||
|
|
||||||
|
- Top-Down: Branchenreport-Werte (Gartner, IDC, Statista, Bitkom, Branchenverbaende)
|
||||||
|
- Bottom-Up: Anzahl potentielle Konten × durchschnittliches Jahresbudget
|
||||||
|
- Beide Werte ausweisen, plausibilisieren, Quellen zitieren
|
||||||
|
|
||||||
|
**SAM (Serviceable Addressable Market)** — der Teil des TAM, den das Produkt mit aktuellem Geschaeftsmodell und geografischem Fokus bedienen kann.
|
||||||
|
|
||||||
|
- Geografische Eingrenzung
|
||||||
|
- Kundengroessen-Eingrenzung (z.B. KMU 50-500 MA)
|
||||||
|
- Branchen-Eingrenzung
|
||||||
|
- Eigene Methodik pro Filter dokumentieren
|
||||||
|
|
||||||
|
**SOM (Serviceable Obtainable Market)** — der Teil des SAM, den das Produkt realistisch in einem definierten Zeitraum gewinnen kann.
|
||||||
|
|
||||||
|
- Typisch 1-5% des SAM in 3-5 Jahren fuer neue Produkte
|
||||||
|
- Begruendung der Annahme (Wettbewerbslage, Salesteam-Groesse, Marketing-Budget, Pilot-Validierung)
|
||||||
|
- SOM-Wachstumstrajektorie ueber Year-1 / Year-2 / Year-3 ausweisen
|
||||||
|
|
||||||
|
### Schritt 3 — Web-Recherche
|
||||||
|
|
||||||
|
Nutze Web-Search systematisch:
|
||||||
|
|
||||||
|
- Suche zuerst nach **offiziellen Branchen-/Verbandsdaten** (Bitkom, Bundesverband Digitale Wirtschaft, KfW-Mittelstandsmonitor, Statistisches Bundesamt)
|
||||||
|
- Dann **Marktforschungs-Berichte** (Statista, Gartner, IDC, Forrester) — beachte Paywall, oft nur Headline-Werte oeffentlich
|
||||||
|
- Dann **Wettbewerbs-Websites, Investor-Presentations, Annual Reports**
|
||||||
|
- Dann **Fach-Medien und Branchenpresse**
|
||||||
|
|
||||||
|
Pro relevanter Datenpunkt: URL, Titel, Datum, Quellen-Typ.
|
||||||
|
|
||||||
|
Wenn eine Zahl nicht belegbar ist: explizit als **Schaetzung** kennzeichnen und Schaetzungs-Methode angeben.
|
||||||
|
|
||||||
|
### Schritt 4 — Wettbewerbsanalyse
|
||||||
|
|
||||||
|
Strukturiere die Wettbewerbslage in drei Schichten:
|
||||||
|
|
||||||
|
**Schicht 1 — Direkte Wettbewerber** (gleiches Produkt-Konzept, gleiche Zielgruppe)
|
||||||
|
|
||||||
|
| Wettbewerber | Positionierung | Preis-Range | Staerke | Schwaeche | Differenzierung von uns |
|
||||||
|
|---|---|---|---|---|---|
|
||||||
|
| ... | ... | ... | ... | ... | ... |
|
||||||
|
|
||||||
|
**Schicht 2 — Indirekte Wettbewerber** (loesen das gleiche Problem anders)
|
||||||
|
|
||||||
|
z.B. fuer Atlas: Inhouse-ChatGPT-Enterprise-Deployment, generische DSGVO-konforme KI-Plattformen, Open-Source-Selbstbau (Ollama + LangChain).
|
||||||
|
|
||||||
|
**Schicht 3 — Substitute** (Status-quo, gegen den geworben werden muss)
|
||||||
|
|
||||||
|
z.B. fuer Atlas: manuelle FAQ-Pflege, klassisches Wissensmanagement, Email-Hotline.
|
||||||
|
|
||||||
|
**Positionierungs-Matrix** (2x2): Identifiziere 2 Achsen, die das Marktverstaendnis strukturieren (z.B. „DSGVO-On-Prem vs. Cloud" × „Mittelstand vs. Enterprise"). Platziere alle Wettbewerber und das eigene Produkt. Ziel: weisser Fleck, in dem das eigene Produkt einzigartig steht.
|
||||||
|
|
||||||
|
### Schritt 5 — Markttrends und Treiber
|
||||||
|
|
||||||
|
Identifiziere 3-5 strukturelle Trends, die fuer das Produkt rueckenwindartig wirken:
|
||||||
|
|
||||||
|
- regulatorisch (DSGVO, EU AI Act, BFSG)
|
||||||
|
- technologisch (LLM-Reife, On-Prem-Inferenz wird bezahlbar)
|
||||||
|
- wirtschaftlich (Mittelstand-Digitalisierungsdruck)
|
||||||
|
- demografisch / kulturell (KMU-IT-Personalmangel, Buergerservice-Erwartungen)
|
||||||
|
|
||||||
|
Pro Trend: 1 Quelle (Studie, Pressebericht, Gesetzestext).
|
||||||
|
|
||||||
|
### Schritt 6 — Output-Aufbau
|
||||||
|
|
||||||
|
Erzeuge `deliverables/<Projekt>_Marktanalyse_<Datum>.md`:
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
# <Projekt> — Marktanalyse
|
||||||
|
Stand: <Datum>
|
||||||
|
Geografie: <DACH/...>
|
||||||
|
Branchen-Fokus: <...>
|
||||||
|
|
||||||
|
## Executive Summary (1 Seite)
|
||||||
|
3-5 Kernaussagen, jede mit Zahlen unterlegt.
|
||||||
|
|
||||||
|
## 1. TAM/SAM/SOM
|
||||||
|
### 1.1 TAM
|
||||||
|
### 1.2 SAM
|
||||||
|
### 1.3 SOM mit Year-1/Y2/Y3-Trajektorie
|
||||||
|
|
||||||
|
## 2. Marktreiber und Trends
|
||||||
|
1-2 Seiten
|
||||||
|
|
||||||
|
## 3. Wettbewerbslage
|
||||||
|
### 3.1 Direkte Wettbewerber (Tabelle)
|
||||||
|
### 3.2 Indirekte Wettbewerber
|
||||||
|
### 3.3 Substitute
|
||||||
|
### 3.4 Positionierungs-Matrix (2x2)
|
||||||
|
|
||||||
|
## 4. Markteintritts-These
|
||||||
|
1 Seite — Warum jetzt? Welcher Spalt? Warum wir?
|
||||||
|
|
||||||
|
## 5. Risiken und Annahmen
|
||||||
|
Was koennte den Markt verschieben? Welche Annahmen sind besonders kritisch?
|
||||||
|
|
||||||
|
## 6. Quellenverzeichnis
|
||||||
|
URL, Titel, Datum, Zugriffsdatum, Typ (Studie/Bericht/Pressemitteilung)
|
||||||
|
```
|
||||||
|
|
||||||
|
Optional: Auch als .pdf exportieren (via pdf document-skill).
|
||||||
|
|
||||||
|
### Schritt 7 — Konsistenz mit Anchor
|
||||||
|
|
||||||
|
Schreibe TAM/SAM/SOM-Werte und Top-Wettbewerber zurueck in `inputs/investor-anchors.md` (wenn vorhanden) fuer Cross-Doc-Konsistenz.
|
||||||
|
|
||||||
|
## Fakt vs. Inferenz vs. Empfehlung — Sprachregeln
|
||||||
|
|
||||||
|
| Kategorie | Sprachmuster | Beispiel |
|
||||||
|
|---|---|---|
|
||||||
|
| **Fakt** | Aktiv, mit Quellen-Anker | "Bitkom 2024: 73 % der DE-KMU planen KI-Investitionen [Quelle 12]" |
|
||||||
|
| **Inferenz** | Konjunktiv oder "deutet darauf hin" | "Daraus laesst sich ableiten, dass ..." / "deutet auf einen TAM von ca. 800 Mio EUR hin" |
|
||||||
|
| **Empfehlung** | "wir empfehlen" / "strategisch sinnvoll" | "Wir empfehlen den Markteintritt ueber die Kurverwaltungs-Vertikale, weil ..." |
|
||||||
|
|
||||||
|
Verbiete dir das Verschmelzen — Investoren erkennen den Unterschied sofort.
|
||||||
|
|
||||||
|
## Anti-Patterns (vermeiden)
|
||||||
|
|
||||||
|
- TAM = Marktwert ohne Geografie-/Branchen-Eingrenzung
|
||||||
|
- "Wir gehen davon aus, dass wir X % des SAM gewinnen" ohne Begruendung
|
||||||
|
- Wettbewerber-Tabelle ohne Quellen-Datum (Wettbewerb veraendert sich monatlich)
|
||||||
|
- Cherry-picking guenstiger Marktstudien
|
||||||
|
- "Markt waechst um 30 % p.a." ohne CAGR-Zeitraum und Quelle
|
||||||
|
|
||||||
|
## Querverweise
|
||||||
|
|
||||||
|
- Nutzt: Web-Search, optional `pdf` (document-skills)
|
||||||
|
- Liefert Input an: `investor-materials` (TAM/SAM/SOM in Anchor), `pitch-deck-builder` (Slide 5 Markt, Slide 9 Wettbewerb)
|
||||||
@@ -0,0 +1,122 @@
|
|||||||
|
---
|
||||||
|
name: pitch-deck-builder
|
||||||
|
description: Use this skill when the user asks to create, draft, build, or design a pitch deck, investor presentation, fundraising deck, sales deck, or board deck. Triggers include phrases like 'pitch deck', 'investor deck', 'investor presentation', 'fundraising slides', 'Slides fuer Investoren', 'Praesentation fuer Geldgeber', 'Pitch fuer ...'. Skill produces a coherent, story-driven 11-slide deck as .pptx by combining strategic narrative work with the pptx document-skill. Skip this skill for short ad-hoc slides without investor/sales narrative intent or when the user already provides full slide content and only wants a layout pass.
|
||||||
|
---
|
||||||
|
|
||||||
|
# Pitch Deck Builder
|
||||||
|
|
||||||
|
## Mission
|
||||||
|
|
||||||
|
Produziere einen kohaerenten, story-getriebenen Investor- oder Vertriebs-Pitch-Deck als .pptx. Der Deck folgt einem 11-Slide-Framework, ist visuell professionell und nutzt die gemeinsame Wissensbasis im Projekt (`inputs/`) als single source of truth — damit Zahlen, Positionierung und Story konsistent mit allen anderen Materialien des venture-Sets bleiben.
|
||||||
|
|
||||||
|
## Wann aktivieren
|
||||||
|
|
||||||
|
Aktiviere bei expliziten Anfragen nach Pitch-Decks, Investor-Praesentationen, Fundraising-Slides oder Sales-Decks. Nicht aktivieren fuer:
|
||||||
|
|
||||||
|
- generelle Slide-Aufgaben ohne investor/sales intent (z.B. "mach mir ein paar Slides zu Thema X")
|
||||||
|
- Layout-Polish auf einem bereits fertig getexteten Deck (dann nur das pptx-Skill nutzen)
|
||||||
|
- One-Pager / Executive Summary (dafuer `executive-summary-writer` nutzen)
|
||||||
|
|
||||||
|
## Workflow
|
||||||
|
|
||||||
|
### Schritt 1 — Kontext aufnehmen (Single Source of Truth)
|
||||||
|
|
||||||
|
Lies vor jeder weiteren Aktion zwingend folgende Dateien aus `inputs/` (sofern vorhanden):
|
||||||
|
|
||||||
|
- `CLAUDE.md` (Projekt-Wurzel) — Projekt-Positionierung, Zielgruppen, Ton
|
||||||
|
- `inputs/strategie-brief.md` oder `inputs/positionierung.md` — Kernbotschaft
|
||||||
|
- `inputs/finanzmodell-anker.md` oder vergleichbar — verbindliche Zahlen (MRR, ARR, Burn, Runway, Ask)
|
||||||
|
- `inputs/marktanalyse.md` — TAM/SAM/SOM, Wettbewerb
|
||||||
|
- alle weiteren `.md` in `inputs/` ueberfliegen
|
||||||
|
|
||||||
|
Wenn diese Dateien fehlen, frage gezielt nach dem Fehlenden statt zu raten. Erfinde **niemals** Finanzzahlen oder Marktdaten.
|
||||||
|
|
||||||
|
### Schritt 2 — Discovery-Interview (nur wenn Kontext luekenhaft)
|
||||||
|
|
||||||
|
Wenn Kontext-Dateien fehlen oder einzelne Slides nicht aus ihnen ableitbar sind, fuehre ein gezieltes Interview. Frage pro Slide maximal 1-2 praezise Rueckfragen, nicht alles auf einmal. Beispiele:
|
||||||
|
|
||||||
|
- Wer ist die Zielgruppe des Decks (Angel / Seed-VC / strategischer Partner / Sales-Prospect)?
|
||||||
|
- Was ist der Ask (Geldhoehe / Hilfe-Art / Use-of-Funds)?
|
||||||
|
- Gibt es Traction-Zahlen (Pilot-Tenants, Pipeline, MRR/ARR)?
|
||||||
|
|
||||||
|
### Schritt 3 — Story-Arc festlegen
|
||||||
|
|
||||||
|
Folge dem 11-Slide-Framework als Default, aber passe es zielgruppen-spezifisch an:
|
||||||
|
|
||||||
|
| # | Slide | Inhalt |
|
||||||
|
|---|---|---|
|
||||||
|
| 1 | **Cover** | Produkt/Firmenname, One-Liner-Tagline, Autor, Datum, vertraulich-Hinweis |
|
||||||
|
| 2 | **Problem** | konkretes, messbares Problem; 1-2 Datenpunkte; emotional anschlussfaehig |
|
||||||
|
| 3 | **Loesung** | klare Kurz-Erklaerung wie das Produkt das Problem loest; nicht Tech-Detail |
|
||||||
|
| 4 | **Warum jetzt** | Marktreife, regulatorische Treiber, technologische Verschiebung |
|
||||||
|
| 5 | **Markt** | TAM/SAM/SOM mit Quellen; klar abgegrenzt |
|
||||||
|
| 6 | **Produkt-Demo / Screenshots** | reales UI; nicht "Lorem Ipsum"; Tour der Kernfunktionen |
|
||||||
|
| 7 | **Geschaeftsmodell** | Tarife, Preise, Unit-Economics, ggf. Pricing-Tabelle |
|
||||||
|
| 8 | **Traction / Validierung** | Pilot-Tenants, Pipeline, Quotes, Letters-of-Intent; ehrlich |
|
||||||
|
| 9 | **Wettbewerb** | 2x2-Matrix oder Feature-Table; differenzierende Achsen |
|
||||||
|
| 10 | **Team** | Gruender + Schluesselrollen; relevante Erfahrung pro Person |
|
||||||
|
| 11 | **Ask + Use-of-Funds** | Hoehe, Verwendung, Meilensteine, Kontakt |
|
||||||
|
|
||||||
|
Fuer Sales-Decks (statt Investor): tausche Slide 11 gegen "Naechster Schritt" und reduziere Slide 5+9 zu Branchen-spezifischen Argumenten.
|
||||||
|
|
||||||
|
Verbiete Buzzword-Kaskaden. Jede Aussage muss durch eine Zahl, eine Quelle oder ein konkretes Beispiel gestuetzt sein.
|
||||||
|
|
||||||
|
### Schritt 4 — Slide-Content draften
|
||||||
|
|
||||||
|
Schreibe pro Slide:
|
||||||
|
|
||||||
|
- **Headline** (max. 7 Worte, Aktiv-Aussage, kein Frage-Titel)
|
||||||
|
- **Subheadline / Kernaussage** (1 Satz, max. 18 Worte)
|
||||||
|
- **Bullet-Body** (3-5 Bullets, je 6-12 Worte)
|
||||||
|
- **Speaker-Notes** (3-5 Saetze, was der Sprecher live sagt)
|
||||||
|
- **Visual-Konzept** (Was ist auf der Folie zu sehen? Diagramm-Typ, Bild-Hinweis)
|
||||||
|
|
||||||
|
Pro Slide max. 30 Worte sichtbarer Text (Headline + Bullets). Speaker-Notes koennen laenger sein.
|
||||||
|
|
||||||
|
### Schritt 5 — Konsistenz-Check
|
||||||
|
|
||||||
|
Bevor der pptx gebaut wird, vergleiche alle Zahlen mit `inputs/finanzmodell-anker.md`. Wenn ein Wert im Deck nicht aus den Inputs ableitbar ist, markiere ihn `[ANNAHME: ...]` und frage den User.
|
||||||
|
|
||||||
|
Konsistenz-Regeln:
|
||||||
|
|
||||||
|
- ARR/MRR-Zahlen identisch mit Finanzmodell
|
||||||
|
- Tenant-Skalierungs-Trajektorie identisch mit Roadmap
|
||||||
|
- Use-of-Funds-Summe = Ask-Summe
|
||||||
|
- Zeitachse durchgehend (kein Q3-2026 auf einer Slide und Q4-2026 auf der naechsten)
|
||||||
|
|
||||||
|
### Schritt 6 — pptx erzeugen
|
||||||
|
|
||||||
|
Nutze das **pptx-document-skill** (`document-skills` Plugin) fuer die technische Erstellung. Anweisung an pptx-Skill:
|
||||||
|
|
||||||
|
- Format 16:9, US Letter oder A4 landscape
|
||||||
|
- Atlas-/LuKi-Net-Markenidentitaet (Farbpalette aus `CLAUDE.md`)
|
||||||
|
- Eine Slide = eine Idee
|
||||||
|
- Datenfolien: Charts statt Tabellen wo moeglich
|
||||||
|
- Speaker-Notes als Notes-Section embedded
|
||||||
|
- Slide-Nummerierung im Footer
|
||||||
|
- Vertraulich-Hinweis im Footer
|
||||||
|
|
||||||
|
Speichere als `deliverables/<Projekt>_Pitch-Deck_<Datum>.pptx`.
|
||||||
|
|
||||||
|
### Schritt 7 — Abnahme
|
||||||
|
|
||||||
|
Nach Erstellung gib zurueck:
|
||||||
|
|
||||||
|
- Pfad zur .pptx
|
||||||
|
- Kurzfassung der Story-Arc (1 Satz)
|
||||||
|
- 3 wichtigste Speaker-Note-Highlights
|
||||||
|
- Liste der `[ANNAHME: ...]`-Stellen, die der User reviewen muss
|
||||||
|
|
||||||
|
## Anti-Patterns (vermeiden)
|
||||||
|
|
||||||
|
- "Generische Investor-Sprache" ohne Bezug zum Konkret-Produkt
|
||||||
|
- Lange Stichpunktlisten auf Slides (>5 Bullets)
|
||||||
|
- Wettbewerber-Slide mit grossen Logos nur als Branding-Display ohne Differenzierung
|
||||||
|
- Team-Slide ohne konkrete Erfolgs-/Erfahrungs-Anker
|
||||||
|
- Use-of-Funds mit Prozent-Tortendiagramm ohne Meilenstein-Verknuepfung
|
||||||
|
|
||||||
|
## Querverweise
|
||||||
|
|
||||||
|
- Nutzt: `pptx` (document-skills), `investor-materials` (fuer Zahlen-Konsistenz)
|
||||||
|
- Liefert Input an: `executive-summary-writer` (One-Pager-Version des Decks)
|
||||||
|
- Konkurriert nicht mit: `market-research` (eigenes Recherche-Skill)
|
||||||
@@ -0,0 +1,117 @@
|
|||||||
|
---
|
||||||
|
name: saas-financial-projections
|
||||||
|
description: Use this skill when the user asks to build, project, model or forecast SaaS finances - revenue, MRR/ARR, CAC, LTV, burn, runway, gross margin, cohort retention, or to create a financial model spreadsheet for investors or internal planning. Triggers include 'financial model', 'Finanzmodell', 'Forecast', 'MRR/ARR-Projektion', 'Burn-Rate', 'Runway', 'CAC-LTV', 'Unit-Economics', 'cohort analysis', 'Rule of 40'. Skill produces a four-step model (baseline, drivers, projection, sensitivity) as .xlsx using the xlsx document-skill, with all numbers traceable back to source assumptions. Skip for simple price calculations or single-cell math.
|
||||||
|
---
|
||||||
|
|
||||||
|
# SaaS Financial Projections
|
||||||
|
|
||||||
|
## Mission
|
||||||
|
|
||||||
|
Erzeuge ein investor-graded SaaS-Finanzmodell mit transparenter Driver-Logik. Jede Output-Zahl ist auf eine explizite Input-Annahme zurueckfuehrbar. Das Modell ist live-rechenbar (Aenderung einer Annahme → Konsistenz-Update aller abhaengigen Felder).
|
||||||
|
|
||||||
|
## Wann aktivieren
|
||||||
|
|
||||||
|
Bei jeder Anfrage zu Finanzmodell, Forecast, Unit-Economics, MRR/ARR-Projektion, Burn/Runway, CAC/LTV, Gross-Margin oder Rule-of-40. Nicht aktivieren fuer einzelne Preis-Berechnungen, einfache Rechen-Fragen oder reine Cost-Tracking-Aufgaben.
|
||||||
|
|
||||||
|
## Workflow — 4-Stufen-Framework
|
||||||
|
|
||||||
|
### Stufe 1 — Baseline (Current State)
|
||||||
|
|
||||||
|
Erfasse den Ist-Zustand. Wenn `inputs/investor-anchors.md` existiert, lies die Anker-Werte zuerst. Sonst frage gezielt nach:
|
||||||
|
|
||||||
|
| Metrik | Was | Default-Frage wenn fehlt |
|
||||||
|
|---|---|---|
|
||||||
|
| MRR | Monthly Recurring Revenue heute | "Wie viel MRR habt ihr aktuell? Falls vor-Revenue: 0" |
|
||||||
|
| ARR | MRR × 12 | abgeleitet |
|
||||||
|
| Tenants/Kunden | Anzahl zahlender Kunden | "Wie viele zahlende Kunden heute?" |
|
||||||
|
| ARPA | MRR / Tenants | abgeleitet |
|
||||||
|
| CAC | Customer Acquisition Cost | "Was kostet euch ein Neukunde inklusive Sales/Marketing-Anteil?" |
|
||||||
|
| Gross-Margin | (Revenue - COGS) / Revenue | "Welche Gross-Margin habt ihr/zielt ihr an?" |
|
||||||
|
| Burn-Rate | monatlicher Verlust | "Wie hoch ist der monatliche Burn?" |
|
||||||
|
| Runway | Cash / Burn | "Wie hoch ist Cash on Hand?" |
|
||||||
|
| Churn (Logo) | gekuendigte Kunden / Bestand | "Habt ihr Churn-Daten? Falls neu: Schaetzung." |
|
||||||
|
| Churn (Revenue) | gekuendigtes Revenue / Bestands-Revenue | abgeleitet oder geschaetzt |
|
||||||
|
|
||||||
|
**Wichtige Regel:** Wenn das Unternehmen pre-Revenue ist, ueberspringe Baseline-Metriken, die Null/N.A. waeren, und beginne direkt bei Stufe 2 mit Annahmen.
|
||||||
|
|
||||||
|
### Stufe 2 — Drivers (Wachstums-Treiber)
|
||||||
|
|
||||||
|
Definiere die expliziten Annahmen, die das Modell antreiben:
|
||||||
|
|
||||||
|
| Driver | Typische Einheit | Was abfragen |
|
||||||
|
|---|---|---|
|
||||||
|
| Neukunden pro Monat | Anzahl/Monat | Akquise-Trajektorie: linear / S-Curve / step-function |
|
||||||
|
| Tarif-Mix | % Basic/Pro/Enterprise | Verteilung der Neukunden ueber Tarifstufen |
|
||||||
|
| ARPA pro Tarif | Euro/Monat | Setup-Fee separat |
|
||||||
|
| Token-Quota-Overage | % der Tenants | wie viele Tenants reissen ihre Quota? |
|
||||||
|
| Logo-Churn-Annahme | %/Monat | typisch 1-3% fuer B2B-SaaS |
|
||||||
|
| Revenue-Expansion | % Net-Revenue-Retention | Upgrades + Cross-Sell |
|
||||||
|
| Sales/Marketing-Budget | Euro/Monat | budgetiert oder revenue-gekoppelt? |
|
||||||
|
| Personal-Roadmap | FTE pro Quartal | Hires-Plan |
|
||||||
|
| COGS-Treiber | LLM-Kosten/Hosting/Sub-AVs | Skaleneffekte? |
|
||||||
|
|
||||||
|
Jeder Driver braucht eine **Quelle oder Begruendung** in einer Notes-Spalte. Beispiele:
|
||||||
|
|
||||||
|
- "Linear 2 Tenants/Monat im Y1, basierend auf Pipeline-Geschwindigkeit aus Pilot-Phase"
|
||||||
|
- "ARPA 1.200 EUR Professional aus Pricing-Tabelle Block 11.1 Konzept v2"
|
||||||
|
- "Logo-Churn 2%/Monat ist Branchen-Benchmark fuer B2B-SaaS Mittelstand (Quelle: ...)"
|
||||||
|
|
||||||
|
### Stufe 3 — Projection (Monats-/Quartalsmodell)
|
||||||
|
|
||||||
|
Baue einen 36-Monats- oder 12-Quartals-Forecast mit:
|
||||||
|
|
||||||
|
- **Revenue-Sheet**: Tenants pro Tarif, MRR pro Tarif, ARR aggregiert
|
||||||
|
- **Cost-Sheet**: Personal, LLM/Hosting, Sales/Marketing, Externe (Pentest, BFSG, Cyber-Versicherung), Sonstiges
|
||||||
|
- **Cash-Sheet**: Cash-In, Cash-Out, Net-Burn, kumulierter Cash, Runway-Anzeige
|
||||||
|
- **KPI-Sheet**: MRR, ARR, ARPA, CAC, LTV, LTV/CAC-Ratio, CAC-Payback-Months, Gross-Margin, Burn-Multiple, Rule-of-40, NRR
|
||||||
|
|
||||||
|
**Pflicht-Formeln** (mit Excel-Syntax in xlsx, nicht hardcoded):
|
||||||
|
- LTV = ARPA × Gross-Margin / Logo-Churn (monthly)
|
||||||
|
- CAC-Payback = CAC / (ARPA × Gross-Margin)
|
||||||
|
- Burn-Multiple = Net-Burn / Net-New-ARR
|
||||||
|
- Rule of 40 = Growth-Rate (YoY %) + Profit-Margin (%)
|
||||||
|
- NRR = (Starting-MRR + Expansion - Downgrades - Churn) / Starting-MRR
|
||||||
|
|
||||||
|
### Stufe 4 — Sensitivity & Szenarien
|
||||||
|
|
||||||
|
Erzeuge mindestens drei Szenarien als separate Sheets oder Spalten:
|
||||||
|
|
||||||
|
| Szenario | Anpassungen ggu. Base | Zweck |
|
||||||
|
|---|---|---|
|
||||||
|
| **Conservative** | -30% Neukunden, +50% Churn, +20% CAC | Worst-credible-case fuer Investor-Stresstest |
|
||||||
|
| **Base** | gepflegte Annahmen | Default-Forecast |
|
||||||
|
| **Optimistic** | +30% Neukunden, -20% Churn | Upside-Story |
|
||||||
|
|
||||||
|
Optional: Sensitivitaets-Tabellen (zweiachsig) fuer kritische Driver-Paare (z.B. Neukunden/Monat × Churn).
|
||||||
|
|
||||||
|
## xlsx-Erstellung
|
||||||
|
|
||||||
|
Nutze das **xlsx-document-skill** mit folgenden Konventionen:
|
||||||
|
|
||||||
|
- Tabs in dieser Reihenfolge: `Annahmen`, `Revenue`, `Costs`, `Cash`, `KPIs`, `Scenario_Conservative`, `Scenario_Optimistic`, `Notes`
|
||||||
|
- Annahmen-Sheet hat **alle** Driver an einer Stelle, farblich markiert (gelb = User-Input, blau = abgeleitet)
|
||||||
|
- Revenue/Costs/Cash referenzieren **per Formel** auf Annahmen, niemals Hardcoded-Werte ausserhalb der Annahmen-Sheet
|
||||||
|
- KPIs-Sheet zeigt alle Schluessel-Metriken in Quartals-Spalten plus Year-Totals
|
||||||
|
- Notes-Sheet listet jede Annahme mit Quelle/Begruendung
|
||||||
|
- Header-Zeile gefroren, Quartals-Spalten farblich gegliedert
|
||||||
|
|
||||||
|
Speichere als `deliverables/<Projekt>_Finanzmodell_<Datum>.xlsx`.
|
||||||
|
|
||||||
|
## Konsistenz-Verpflichtung
|
||||||
|
|
||||||
|
Wenn `inputs/investor-anchors.md` existiert: Schreibe **alle** Output-Anker zurueck in den Anker (ARR-Ziele, Break-Even-Quartal, Tenant-Trajektorie, Runway). Dies ist die Voraussetzung fuer Cross-Doc-Konsistenz via `investor-materials`-Skill.
|
||||||
|
|
||||||
|
## Anti-Patterns (vermeiden)
|
||||||
|
|
||||||
|
- Hardcoded-Zahlen in Revenue/Cost-Sheets (alles muss auf Annahmen referenzieren)
|
||||||
|
- Hockey-Stick ohne Driver-Logik (Wachstum von 10 auf 1000 Kunden in 12 Monaten "weil")
|
||||||
|
- Optimistic-Szenario ohne Conservative
|
||||||
|
- Fehlende CAC/LTV-Begruendung
|
||||||
|
- LTV ohne Gross-Margin-Beruecksichtigung
|
||||||
|
- Rule of 40 ohne Definition welcher Growth-Begriff (ARR YoY vs. MRR MoM)
|
||||||
|
|
||||||
|
## Querverweise
|
||||||
|
|
||||||
|
- Nutzt: `xlsx` (document-skills)
|
||||||
|
- Kooperiert mit: `investor-materials` (Anchor-File-Pflege), `pitch-deck-builder` (Slide 7 Geschaeftsmodell, Slide 11 Ask)
|
||||||
|
- Unabhaengig von: `market-research` (TAM ist nicht Forecast)
|
||||||
Reference in New Issue
Block a user