@markus-global/cli 0.2.0

package/templates/skills/self-evolution/SKILL.md

@@ -0,0 +1,207 @@
+---
+name: self-evolution
+description: Learn from mistakes, corrections, and successful strategies — evolve your role, tool preferences, and SOPs over time
+---
+
+# Self-Evolution
+
+You have the ability to learn from experience and evolve yourself over time. This goes beyond remembering facts — you can refine your own role definition, optimize your tool usage patterns, and develop standard operating procedures (SOPs) that make you more effective.
+
+This is not optional — continuous self-improvement is a core part of being an effective agent.
+
+## When to Reflect
+
+Trigger the reflection process when any of these happen:
+
+1. **User correction** — The user says "no, do X instead", "that's wrong", or redirects your approach. Strongest signal.
+2. **Task revision** — A task you submitted was rejected and sent back. The system will prompt you to reflect after a revised task is accepted.
+3. **Self-correction** — You tried one approach, it failed, and you found a different approach that worked.
+4. **Resolved error** — An unexpected error (tool failure, wrong API assumption, misunderstood requirement) that you diagnosed and fixed.
+5. **Efficiency insight** — You discover a faster, cleaner, or more reliable way to accomplish a recurring task.
+6. **Pattern recognition** — You notice you keep doing something the same way and realize it could be standardized.
+
+Do NOT trigger reflection for trivial matters — typos, one-off path errors, or situations that won't recur.
+
+## Layer 1: Lessons (Immediate Memory)
+
+### How to Extract a Lesson
+
+When a reflection trigger fires, think through:
+
+1. **Situation** — What were you trying to do?
+2. **What went wrong** — What assumption or action was incorrect?
+3. **What worked** — What was the correct approach?
+4. **Generalized rule** — A reusable principle beyond this specific instance.
+
+### How to Save a Lesson
+
+Use `memory_save` with:
+
+- **type**: `"note"`
+- **content**: Concise lesson in this format:
+  ```
+  [LESSON] <one-line summary>
+  Situation: <brief context>
+  Mistake: <what went wrong>
+  Correction: <what works>
+  Rule: <generalized principle for future use>
+  ```
+- **tags**: Always include `"lesson"` as the first tag, then add category tags:
+  - `coding` — code patterns, language features, library usage
+  - `tool-usage` — correct use of shell, file, git, or other tools
+  - `communication` — how to interact with users, managers, or other agents
+  - `architecture` — system design, file organization, dependency decisions
+  - `process` — workflow, task management, review process
+  - `domain:<topic>` — domain-specific knowledge (e.g., `domain:react`)
+
+### Consolidating Lessons
+
+When you have 3+ unsaved lessons, consolidate into long-term memory:
+
+```
+memory_update_longterm({
+  section: "lessons-learned",
+  content: "<numbered list of top 20 lessons>"
+})
+```
+
+Each lesson: one actionable sentence. Replace older/less impactful ones when you exceed 20.
+
+## Layer 2: Tool Preferences
+
+Over time you will discover which tools work best for specific situations. Record these preferences so you can make better tool choices automatically.
+
+### When to Update Tool Preferences
+
+- You discover a tool is significantly better than another for a specific task type
+- You find optimal parameters or flags for a tool (e.g., `grep` with specific flags vs. `glob`)
+- You learn that a tool has limitations you should work around
+- A tool combination (pipeline) works well for a recurring need
+
+### How to Save Tool Preferences
+
+Use `memory_save` with:
+
+- **type**: `"note"`
+- **content**:
+  ```
+  [TOOL-PREF] <one-line summary>
+  Task: <what kind of task>
+  Preferred: <tool and how to use it>
+  Avoid: <what doesn't work well and why>
+  Reason: <why this preference>
+  ```
+- **tags**: `["lesson", "tool-preference", "<tool-name>"]`
+
+Periodically consolidate into long-term memory:
+
+```
+memory_update_longterm({
+  section: "tool-preferences",
+  content: "<list of tool preferences by task type>"
+})
+```
+
+Format as a compact reference table your future self can quickly scan.
+
+## Layer 3: SOPs (Standard Operating Procedures)
+
+When you find yourself repeatedly doing a multi-step process, document it as an SOP. When you later find a better way, update it.
+
+### When to Create or Update an SOP
+
+- You've done the same multi-step workflow 2+ times and want to standardize it
+- You found a significantly better sequence of steps for an existing SOP
+- A step in an existing SOP failed or was suboptimal, and you found a fix
+
+### How to Save SOPs
+
+Use `memory_update_longterm` with section `"sops"`:
+
+```
+memory_update_longterm({
+  section: "sops",
+  content: "<all your SOPs>"
+})
+```
+
+Format each SOP as:
+
+```
+### SOP: <Name>
+Trigger: <when to use this SOP>
+Steps:
+1. <step 1>
+2. <step 2>
+...
+Notes: <gotchas, tips, common failures>
+Last updated: <date>
+```
+
+Keep SOPs concise and actionable. Maximum 10 SOPs — merge or retire outdated ones.
+
+## Layer 4: Role Evolution (ROLE.md)
+
+This is the deepest level of self-evolution. Your ROLE.md defines your core identity, system prompt, and behavioral guidelines. When you accumulate enough lessons and experience in a domain, you can evolve your own role definition.
+
+**Your ROLE.md path**: `{AGENT_DATA_DIR}/role/ROLE.md` (the system tells you your data directory in the workspace section of your context)
+
+### When to Modify ROLE.md
+
+Only modify your ROLE.md when ALL of these conditions are met:
+
+1. **Pattern threshold** — You have 3+ related lessons pointing to a fundamental behavioral change (not a one-off fix)
+2. **High confidence** — The change reflects proven experience, not speculation
+3. **Systemic impact** — The improvement would affect how you handle many future tasks, not just one type
+4. **Not contradicting core role** — The change refines or extends your role, not contradicts it
+
+### How to Modify ROLE.md
+
+1. First, read your current ROLE.md via `file_read`
+2. Identify where the new guideline fits — append to existing sections or add a new section
+3. Use `file_edit` to make a surgical change — never rewrite the entire file
+4. Log the change in memory:
+
+```
+memory_save({
+  type: "note",
+  content: "[ROLE-EVOLUTION] <summary of change>\nReason: <why this change>\nLessons: <which lessons led to this>\nChange: <what was added/modified in ROLE.md>",
+  tags: ["lesson", "role-evolution"]
+})
+```
+
+### ROLE.md Evolution Rules
+
+- **APPEND, don't replace** — Add new guidelines, don't remove existing ones unless they're clearly wrong
+- **Keep it concise** — Each new guideline should be 1-3 lines. ROLE.md should not grow beyond 200 lines
+- **Never touch the header** — The `# Role Name` and core identity section must stay intact
+- **Log every change** — Always save a `role-evolution` tagged memory entry explaining why
+- **One change at a time** — Don't batch multiple unrelated role changes
+- **Consolidate evolution history** periodically:
+
+```
+memory_update_longterm({
+  section: "role-evolution-log",
+  content: "<chronological list of role changes and reasons>"
+})
+```
+
+## Using Past Experience
+
+Your past evolution data is available in two ways:
+
+1. **Automatic** — Your `lessons-learned`, `tool-preferences`, `sops`, and `role-evolution-log` sections in MEMORY.md appear in your system context every session.
+2. **On-demand** — Use `memory_search` with relevant keywords to find specific past lessons.
+
+Before starting a task, briefly review relevant sections. This takes seconds and prevents repeating mistakes.
+
+## Rules
+
+- **DO NOT** skip reflection when the system prompts you after a task revision.
+- **DO NOT** save trivial or non-generalizable lessons.
+- **DO NOT** let any long-term memory section grow unbounded. Limits: lessons-learned (20), tool-preferences (15), SOPs (10), role-evolution-log (20).
+- **DO NOT** modify ROLE.md for one-off situations — only for proven patterns.
+- **DO** save lessons immediately when a correction happens, while context is fresh.
+- **DO** include specific, actionable advice. "Be more careful" is useless. "Always validate input schema before processing" is useful.
+- **DO** use tags consistently so lessons are discoverable via search.
+- **DO** periodically prune and consolidate each memory section to keep it current.

package/templates/skills/self-evolution/skill.json

@@ -0,0 +1,14 @@
+{
+  "type": "skill",
+  "name": "self-evolution",
+  "displayName": "Self-Evolution",
+  "version": "1.0.0",
+  "description": "Learn from mistakes, corrections, and successful strategies — extract lessons and persist them as structured memories for future retrieval",
+  "author": "markus",
+  "category": "productivity",
+  "tags": ["learning", "reflection", "memory", "self-improvement", "evolution"],
+  "skill": {
+    "skillFile": "SKILL.md",
+    "alwaysOn": true
+  }
+}

package/templates/skills/skill-building/SKILL.md

@@ -0,0 +1,172 @@
+---
+name: skill-building
+description: Design and create agent skill packages — instruction-based and MCP-based skills, manifest format
+---
+
+# Skill Building
+
+This skill teaches you how to create Markus skill packages — directory-based artifacts that teach agents new capabilities. A skill can work in two ways (or both):
+
+1. **Instruction-based**: A `SKILL.md` file with instructions injected into the agent's context, guiding it to use existing tools in new ways.
+2. **MCP-based**: A bundled MCP server (script) that provides entirely new tools to the agent. The skill directory can contain any scripts, config files, or resources the MCP server needs.
+
+Most skills are instruction-based. Use MCP-based skills when the capability requires new tools that don't exist yet (e.g., connecting to an external API, browser automation, hardware control).
+
+## Artifact Directory
+
+**CRITICAL**: Skill artifacts MUST be saved under this exact path — the Builder page, install system, and deliverable detection all depend on it:
+
+```
+~/.markus/builder-artifacts/skills/{skill-name}/
+├── skill.json       # Manifest (auto-created from your JSON output)
+├── SKILL.md         # Instruction document (you write via file_write)
+├── README.md        # Human-readable documentation (optional)
+└── ...              # Any other files: scripts, MCP servers, configs, templates, etc.
+```
+
+**Do NOT write artifacts to `~/.markus/shared/`, your working directory, or any other location.** Only `~/.markus/builder-artifacts/skills/` is recognized by the system.
+
+A skill directory can contain **any files** needed for the skill to work — not just SKILL.md and README.md. For example:
+- **MCP server scripts** (e.g., `server.mjs`) that provide new tools to the agent
+- **Configuration templates** or data files
+- **Helper scripts** used by the instructions
+
+When the user **installs** the artifact, the **entire directory** (all files) is deployed to `~/.markus/skills/{skill-name}/`. `SKILL.md` is loaded and injected into the agent's context when the skill is activated. If the manifest declares `mcpServers`, those servers are started and their tools registered to the agent. `skill.json` contains metadata used by the skill registry. `README.md` provides documentation for humans browsing or sharing the skill.
+
+## Two-Step Workflow
+
+Output the skill in two steps — manifest first, then content files. **Never put file content inline in the JSON.**
+
+### Chat Mode vs Task Mode
+
+- **Chat mode** (user conversation): Output the manifest JSON in a ```json code block → system auto-saves and creates the directory → then use `file_write` for each content file.
+- **Task mode** (assigned task): Use `file_write` to write the manifest JSON file directly (e.g., `file_write("~/.markus/builder-artifacts/skills/{name}/skill.json", ...)`) → then use `file_write` for each content file. When submitting deliverables, set the reference to the artifact directory path.
+- **A2A mode** (agent-to-agent): Same as task mode — write all files via `file_write`.
+
+### Step 1: Output Manifest JSON
+
+**In chat mode**: Output the skill configuration as a JSON code block. The system auto-saves it.
+**In task/A2A mode**: Write the manifest JSON file directly via `file_write`.
+
+This JSON contains ONLY metadata — **no file content**.
+
+**Instruction-based skill** (most common):
+```json
+{
+  "type": "skill",
+  "name": "skill-name-kebab-case",
+  "displayName": "Skill Name",
+  "version": "1.0.0",
+  "description": "When and why an agent should use this skill",
+  "author": "",
+  "category": "custom",
+  "tags": ["tag1", "tag2"],
+  "skill": {
+    "skillFile": "SKILL.md"
+  }
+}
+```
+
+**MCP-based skill** (provides new tools via a bundled server script):
+```json
+{
+  "type": "skill",
+  "name": "my-api-connector",
+  "displayName": "My API Connector",
+  "version": "1.0.0",
+  "description": "Connect to My API for data retrieval and actions",
+  "author": "",
+  "category": "custom",
+  "tags": ["api", "connector"],
+  "skill": {
+    "skillFile": "SKILL.md",
+    "requiredPermissions": ["network"],
+    "mcpServers": {
+      "my-api": {
+        "command": "node",
+        "args": ["${SKILL_DIR}/server.mjs"]
+      }
+    }
+  }
+}
+```
+
+**Notes on MCP servers:**
+- `${SKILL_DIR}` is resolved at load time to the skill's actual directory path — use it to reference bundled scripts.
+- The `command` can be any executable (`node`, `python3`, `npx`, etc.).
+- The MCP server communicates via JSON-RPC 2.0 over stdio (stdin/stdout).
+- Tool names exposed by MCP servers are automatically prefixed with the server name (e.g., `my-api__tool_name`). Mention these prefixed names in SKILL.md.
+- You can also use externally published MCP servers: `"command": "npx", "args": ["-y", "some-mcp-server@latest"]`.
+
+The system automatically saves this JSON and creates the directory. After that, you proceed to write files.
+
+### Step 2: Write Files with file_write
+
+After the JSON is saved, write each file individually using `file_write`. The base path is `~/.markus/builder-artifacts/skills/{skill-name}/` (use the `name` from your JSON).
+
+**Write files in this order:**
+
+1. **SKILL.md** (REQUIRED) — The instruction document with YAML frontmatter and comprehensive Markdown body:
+   - YAML frontmatter with `name` and `description` (must match manifest)
+   - Overview of what the skill does
+   - Step-by-step instructions referencing actual tools (or MCP tool names if MCP-based)
+   - Error handling guidance
+   - Examples of typical input/output
+
+2. **MCP server script** (if MCP-based) — e.g., `server.mjs` implementing the MCP protocol over stdio. Must handle `initialize`, `tools/list`, and `tools/call` JSON-RPC methods.
+
+3. **README.md** (optional) — Human-readable documentation for browsing or sharing.
+
+4. **Any other files** — Helper scripts, templates, config files, data files, etc.
+
+**Example file_write calls:**
+
+```
+file_write("~/.markus/builder-artifacts/skills/git-changelog/SKILL.md", "---\nname: git-changelog\ndescription: Generate changelogs from git history\n---\n\n# Git Changelog\n\n## Overview\n...\n\n## Instructions\n...\n\n## Examples\n...")
+file_write("~/.markus/builder-artifacts/skills/git-changelog/README.md", "# Git Changelog\n\nA skill that helps agents generate changelogs from git history...\n")
+```
+
+## Field Reference
+
+### Top-level fields
+- **`type`**: Always `"skill"`
+- **`name`**: **MUST be English kebab-case** (e.g., `git-changelog`, `web-scraper`). Must match `SKILL.md` frontmatter name. This is the directory name and identifier.
+- **`displayName`**: Human-readable skill name, can be in any language
+- **`version`**: Semver (default `"1.0.0"`)
+- **`description`**: When and why an agent should use this skill (can be in any language)
+- **`category`**: Typically `"custom"` for user-created skills
+- **`tags`**: Array of descriptive tags
+
+### `skill` section (REQUIRED)
+- **`skillFile`**: Always `"SKILL.md"` — the entry point instruction document
+- **`requiredPermissions`**: (optional) Array of permissions: `"shell"`, `"file"`, `"network"`, `"browser"`
+- **`mcpServers`**: (optional) Map of MCP server name → config. Each config has `command`, `args?`, `env?`. Use `${SKILL_DIR}` in args/env to reference the skill directory.
+- **`alwaysOn`**: (optional, boolean) If `true`, the skill's instructions are automatically injected into **every** agent's context at startup. Only use this for foundational skills that all agents must always follow (e.g., `self-evolution`). Default is `false` — non-alwaysOn built-in skills are listed as "available" in the agent's identity section and can be activated on-demand via `discover_tools`.
+
+## After Creation
+
+Once all files are written, tell the user:
+
+1. **The skill has been created and saved** — summarize what was created (name, purpose, what agents can do with it).
+2. **Go to the Builder page** to manage the skill: install it to make it available to agents, share it to Markus Hub, or delete it.
+3. **To modify or improve** this skill (e.g., add more instructions, update examples, fix edge cases), just continue the conversation here — describe what you want to change and I'll update the files directly.
+
+## Guidelines
+
+- Instructions in SKILL.md should reference actual tools: `shell_execute`, `file_read`, `file_write`, `file_edit`, `grep`, `glob`, `web_fetch`, `web_search`, `gui` — or MCP tool names if the skill provides its own tools
+- For MCP-based skills, document every tool with its prefixed name (e.g., `my-api__search`) in SKILL.md so the agent knows how to use them
+- Be specific — include actual CLI commands, file paths, and URL patterns
+- Include error handling: what to do when commands fail, pages don't load, etc.
+- Provide examples of typical input/output for each workflow step
+- Skills should be self-contained: an agent reading the instructions should know exactly what to do
+- Consider composability: skills that work well alongside other skills
+- After outputting the JSON, immediately proceed to write files via `file_write` — announce what you're writing
+- When creating MCP server scripts, use only Node.js built-in modules (no npm dependencies) for maximum portability, or use `npx` to reference published packages
+
+## Rules
+
+- **DO NOT** use names that conflict with built-in skills. Check the dynamic context for existing skill names.
+- **DO NOT** put file content in the JSON. Always use `file_write` for files.
+- **DO NOT** write artifacts to `~/.markus/shared/` or your working directory. Always use `~/.markus/builder-artifacts/skills/{name}/`.
+- **The `name` field MUST be English kebab-case** (e.g., `git-changelog`, not `网页抓取器`). This is the directory name and package identifier.
+- The `name` field and `SKILL.md` frontmatter `name` must match exactly.

package/templates/skills/skill-building/skill.json

@@ -0,0 +1,13 @@
+{
+  "type": "skill",
+  "name": "skill-building",
+  "displayName": "Skill Building",
+  "version": "1.0.0",
+  "description": "Design and create agent skill packages — instruction-based and MCP-based skills, manifest format, directory structure for Markus skill artifacts",
+  "author": "markus",
+  "category": "development",
+  "tags": ["builder", "skill", "design", "manifest", "mcp"],
+  "skill": {
+    "skillFile": "SKILL.md"
+  }
+}

package/templates/skills/team-building/SKILL.md

@@ -0,0 +1,159 @@
+---
+name: team-building
+description: Design and create AI team packages — manifest format, member structure, directory layout
+---
+
+# Team Building
+
+This skill teaches you how to create Markus team packages — self-contained directory-based artifacts that define a group of specialized AI agents with shared norms and coordination structure.
+
+## Core Philosophy
+
+**Every agent in a team must be a specialist.** Do NOT simply pick generic templates and give them names. Design each agent with a unique identity, expertise, and detailed role documentation. Safety constraints are defined in each agent's `POLICIES.md`, not through tool restrictions.
+
+## Artifact Directory
+
+**CRITICAL**: Team artifacts MUST be saved under this exact path — the Builder page, install system, and deliverable detection all depend on it:
+
+```
+~/.markus/builder-artifacts/teams/{team-name}/
+├── team.json                    # Manifest (auto-created from your JSON output)
+├── ANNOUNCEMENT.md              # Team announcement (you write via file_write)
+├── NORMS.md                     # Working norms (you write via file_write)
+└── members/
+    ├── {manager-slug}/
+    │   ├── ROLE.md              # Manager identity (you write via file_write)
+    │   └── POLICIES.md          # Manager constraints (you write via file_write, optional)
+    └── {worker-slug}/
+        ├── ROLE.md              # Worker identity (you write via file_write)
+        └── POLICIES.md          # Worker constraints (you write via file_write, optional)
+```
+
+**Do NOT write artifacts to `~/.markus/shared/`, your working directory, or any other location.** Only `~/.markus/builder-artifacts/teams/` is recognized by the system.
+
+### Where files are deployed on install
+
+| Package location | Deployed to | Purpose |
+|---|---|---|
+| `ANNOUNCEMENT.md` | `~/.markus/teams/{teamId}/ANNOUNCEMENT.md` | Injected into every member's context |
+| `NORMS.md` | `~/.markus/teams/{teamId}/NORMS.md` | Injected into every member's context |
+| `members/{name}/ROLE.md` | `~/.markus/agents/{agentId}/role/ROLE.md` | Overrides base role template prompt |
+| `members/{name}/POLICIES.md` | `~/.markus/agents/{agentId}/role/POLICIES.md` | Additional agent constraints |
+
+## Two-Step Workflow
+
+Output the team in two steps — manifest first, then content files. **Never put file content inline in the JSON.**
+
+### Chat Mode vs Task Mode
+
+- **Chat mode** (user conversation): Output the manifest JSON in a ```json code block → system auto-saves and creates the directory → then use `file_write` for each content file.
+- **Task mode** (assigned task): Use `file_write` to write the manifest JSON file directly (e.g., `file_write("~/.markus/builder-artifacts/teams/{name}/team.json", ...)`) → then use `file_write` for each content file. When submitting deliverables, set the reference to the artifact directory path.
+- **A2A mode** (agent-to-agent): Same as task mode — write all files via `file_write`.
+
+### Step 1: Output Manifest JSON
+
+**In chat mode**: Output the team structure as a JSON code block. The system auto-saves it.
+**In task/A2A mode**: Write the manifest JSON file directly via `file_write`.
+
+This JSON contains ONLY metadata and structure — **no file content**.
+
+```json
+{
+  "type": "team",
+  "name": "team-name-kebab-case",
+  "displayName": "Team Display Name",
+  "version": "1.0.0",
+  "description": "Team purpose and goals",
+  "author": "",
+  "category": "development | devops | management | productivity | general",
+  "tags": ["tag1", "tag2"],
+  "team": {
+    "members": [
+      {
+        "name": "Manager Name",
+        "role": "manager",
+        "roleName": "project-manager",
+        "count": 1,
+        "skills": ["skill-id-1"]
+      },
+      {
+        "name": "Worker Name",
+        "role": "worker",
+        "roleName": "developer",
+        "count": 1,
+        "skills": ["skill-id-1", "skill-id-2"]
+      }
+    ]
+  }
+}
+```
+
+The system automatically saves this JSON and creates the directory. After that, you proceed to write files.
+
+### Step 2: Write Files with file_write
+
+After the JSON is saved, write each file individually using `file_write`. The base path is `~/.markus/builder-artifacts/teams/{team-name}/` (use the `name` from your JSON).
+
+**Write files in this order:**
+
+1. **ANNOUNCEMENT.md** — Team mission, member introduction, collaboration goals. At least 3 paragraphs.
+
+2. **NORMS.md** — Communication protocols, quality standards, escalation rules. Specific to this team's domain.
+
+3. **Each member's ROLE.md** — Write one at a time. Each ROLE.md should be at least 5 paragraphs, covering:
+   - Who this agent is (identity, personality)
+   - Core expertise and responsibilities
+   - Workflow and methodology
+   - Output standards and quality criteria
+   - Collaboration expectations within the team
+
+4. **POLICIES.md** (optional) — For members that need specific constraints.
+
+**Example file_write calls:**
+
+```
+file_write("~/.markus/builder-artifacts/teams/research-team/ANNOUNCEMENT.md", "# Research Team — Team Announcement\n\n...")
+file_write("~/.markus/builder-artifacts/teams/research-team/NORMS.md", "# Research Team — Working Norms\n\n...")
+file_write("~/.markus/builder-artifacts/teams/research-team/members/research-director/ROLE.md", "# Research Director\n\nYou are **Research Director** — ...\n\n...")
+file_write("~/.markus/builder-artifacts/teams/research-team/members/senior-researcher/ROLE.md", "# Senior Researcher\n\nYou are **Senior Researcher** — ...\n\n...")
+```
+
+**IMPORTANT**: The member directory slug is derived from the member's `name` field — lowercased, spaces to hyphens, non-alphanumeric removed.
+
+## Field Reference
+
+### Top-level fields
+- **`type`**: Always `"team"`
+- **`name`**: **MUST be English kebab-case** (e.g., `frontend-squad`, `research-team`). Even for Chinese teams, use English slug.
+- **`displayName`**: Human-readable name, any language (e.g., `"前端开发小队"`)
+- **`version`**: Semver (default `"1.0.0"`)
+- **`description`**: Team purpose (any language)
+- **`category`**: One of `development`, `devops`, `management`, `productivity`, `general`
+- **`tags`**: Descriptive tags
+
+### `team.members[]` — Member Specifications (REQUIRED)
+- **`name`**: Display name (the slug for file paths is derived from this)
+- **`role`**: `"manager"` or `"worker"`
+- **`roleName`**: Base role template from the dynamic context
+- **`count`**: Number of instances (default 1)
+- **`skills`**: Skill IDs from the dynamic context. **Actively assign skills — don't leave empty!**
+
+## After Creation
+
+Once all files are written, tell the user:
+
+1. **The team has been created and saved** — summarize the team composition (name, members, their roles).
+2. **Go to the Builder page** to manage the team: install it to deploy all members, share it to Markus Hub, or delete it.
+3. **To modify or improve** this team (e.g., add new members, update roles, change team norms), just continue the conversation here — describe what you want to change and I'll update the files directly.
+
+## Rules
+
+- **DO NOT** invent role names or skill IDs. Only use values from the dynamic context.
+- **DO NOT** leave skills empty when relevant skills are available. Review the skills list!
+- **DO NOT** put file content in the JSON. Always use `file_write` for files.
+- **DO NOT** write artifacts to `~/.markus/shared/` or your working directory. Always use `~/.markus/builder-artifacts/teams/{name}/`.
+- **The `name` field MUST be English kebab-case**.
+- Every team MUST have exactly **one** member with `"role": "manager"` and at least **one** `"worker"`.
+- Write each ROLE.md with **full attention** — at least 5 substantive paragraphs per member.
+- Do NOT rush through members. Each one deserves careful, tailored content.
+- After outputting the JSON, write files one by one — announce what you're writing each time.

package/templates/skills/team-building/skill.json

@@ -0,0 +1,13 @@
+{
+  "type": "skill",
+  "name": "team-building",
+  "displayName": "Team Building",
+  "version": "1.0.0",
+  "description": "Design and create AI team packages — manifest format, member structure, directory layout, and deployment for Markus team artifacts",
+  "author": "markus",
+  "category": "development",
+  "tags": ["builder", "team", "design", "manifest"],
+  "skill": {
+    "skillFile": "SKILL.md"
+  }
+}

package/templates/teams/content-team/ANNOUNCEMENT.md

@@ -0,0 +1,10 @@
+# Content Creation Team
+
+Welcome to the Content Team. We create high-quality content that informs, engages, and converts.
+
+## Current Focus
+- Awaiting content brief from stakeholders. The Content Director will set editorial priorities once a project is assigned.
+
+## Workflow
+- The Director assigns topics. The Researcher provides source material. Writers produce drafts. The Director reviews and approves.
+- All content goes through editorial review before publication.

package/templates/teams/content-team/NORMS.md

@@ -0,0 +1,20 @@
+# Content Team — Working Norms
+
+## Quality
+- Every piece needs research backing. No publishing unsupported claims.
+- Follow the brand style guide for tone, formatting, and terminology.
+- All content is reviewed by the Director before acceptance.
+
+## Process
+- Start with an outline or brief before writing the full piece.
+- Writers should request research support early, not after the draft.
+- Submit drafts with a summary of the piece's purpose and target audience.
+
+## Communication
+- Share drafts early for feedback — don't wait until "perfect."
+- Provide constructive feedback focused on improving the piece, not on style preferences.
+- Flag missed deadlines immediately with a revised timeline.
+
+## Collaboration
+- Research briefs are shared documents — everyone can read and build on them.
+- Cross-review between writers improves quality. Volunteer to review teammates' work.

package/templates/teams/content-team/team.json

@@ -0,0 +1,18 @@
+{
+  "type": "team",
+  "name": "content-team",
+  "displayName": "Content Creation Team",
+  "version": "1.0.0",
+  "description": "A content-focused team with a content strategist who plans, writers who create, and a researcher who provides insights. Ideal for marketing campaigns, documentation projects, and content operations.",
+  "author": "Markus Team",
+  "category": "productivity",
+  "tags": ["content", "writing", "marketing", "documentation", "creative"],
+  "icon": "edit",
+  "team": {
+    "members": [
+      { "name": "Content Director", "role": "manager", "roleName": "project-manager", "count": 1, "skills": [] },
+      { "name": "Writer", "role": "worker", "roleName": "content-writer", "count": 2, "skills": [] },
+      { "name": "Researcher", "role": "worker", "roleName": "research-assistant", "count": 1, "skills": [] }
+    ]
+  }
+}

package/templates/teams/dev-squad/ANNOUNCEMENT.md

@@ -0,0 +1,11 @@
+# Development Squad
+
+Welcome to the Development Squad. We build software features through structured sprints.
+
+## Current Focus
+- Awaiting first project assignment. The PM will decompose requirements into tasks once a project is onboarded.
+
+## How We Work
+- The PM assigns tasks based on requirements. Developers implement, Reviewer ensures quality, QA validates.
+- All work goes through the task system — no side-channel requests.
+- Submit via `task_submit_review` when done. The Reviewer or QA will validate before acceptance.