Merge pull request 'fix(basecamp-project): workaround templates construct CLI bug with direct API call' (#4) from feature/basecamp-project-skill into master

Reviewed-on: #4

.gitignore

@@ -12,3 +12,5 @@
 # Nix / direnv
 .direnv/
 result
+
+.pi*

.pi-lens/cache/jscpd.json

@@ -1,7 +0,0 @@
-{
-  "success": true,
-  "clones": [],
-  "duplicatedLines": 0,
-  "totalLines": 0,
-  "percentage": 0
-}

.pi-lens/cache/jscpd.meta.json

@@ -1,3 +0,0 @@
-{
-  "timestamp": "2026-04-24T17:57:06.373Z"
-}

.pi-lens/cache/knip.json

@@ -1,9 +0,0 @@
-{
-  "success": false,
-  "issues": [],
-  "unusedExports": [],
-  "unusedFiles": [],
-  "unusedDeps": [],
-  "unlistedDeps": [],
-  "summary": "Failed to parse output"
-}

.pi-lens/cache/knip.meta.json

@@ -1,3 +0,0 @@
-{
-  "timestamp": "2026-04-24T17:57:13.428Z"
-}

.pi-lens/cache/session-start-guidance.json

@@ -1 +0,0 @@
-null

.pi-lens/cache/session-start-guidance.meta.json

@@ -1,3 +0,0 @@
-{
-  "timestamp": "2026-04-24T17:41:29.302Z"
-}

.pi-lens/cache/todo-baseline.json

@@ -1,18 +0,0 @@
-{
-  "items": [
-    {
-      "type": "TODO",
-      "message": "Replace with the first main section based on chosen structure]",
-      "file": "skills/skill-creator/scripts/init_skill.py",
-      "line": 58,
-      "column": 4
-    },
-    {
-      "type": "TODO",
-      "message": "Add actual script logic here",
-      "file": "skills/skill-creator/scripts/init_skill.py",
-      "line": 120,
-      "column": 6
-    }
-  ]
-}

.pi-lens/cache/todo-baseline.meta.json

@@ -1,3 +0,0 @@
-{
-  "timestamp": "2026-04-24T17:39:59.334Z"
-}

.pi-lens/cache/turn-end-findings-last.json

@@ -1,3 +0,0 @@
-{
-  "signature": "/home/m3tam3re/p/NIX/nixpkgs/modules/home-manager/coding/agents/claude-code.nix::📐 Cascade errors in 1 other file(s) — fix before finishing turn:\n<diagnostics file=\"/home/m3tam3re/p/NIX/nixpkgs/modules/home-manager/coding/agents/pi.nix\">\n  line 205, col 10 code=sema-duplicated-attrname: duplicated attrname `file`\n</diagnostics>"
-}

.pi-lens/cache/turn-end-findings-last.meta.json

@@ -1,3 +0,0 @@
-{
-  "timestamp": "2026-04-11T03:32:45.214Z"
-}

.pi-lens/cache/turn-end-findings.json

@@ -1 +0,0 @@
-null

.pi-lens/cache/turn-end-findings.meta.json

@@ -1,3 +0,0 @@
-{
-  "timestamp": "2026-04-11T03:33:08.875Z"
-}

.pi-lens/turn-state.json

@@ -1,6 +0,0 @@
-{
-  "files": {},
-  "turnCycles": 0,
-  "maxCycles": 3,
-  "lastUpdated": "2026-04-24T17:57:13.429Z"
-}

AGENTS.md

@@ -444,6 +444,38 @@ m3taLib.coding-rules.mkCodingRules {
 
 See `rules/USAGE.md` for full documentation.
 
+## Agent Git Identity
+
+All agent commits use a dedicated bot identity for clear audit trails.
+
+### Configuration
+
+```nix
+coding.agents.gitIdentity = {
+  enable = true;
+  name = "m3ta-chiron";
+  email = "m3ta-chiron@agentmail.to";
+  sshKey = "/run/agenix/m3ta-chiron-ssh-key";
+};
+```
+
+### Environment Variables
+
+When enabled, these are automatically set:
+- `GIT_AUTHOR_NAME`, `GIT_AUTHOR_EMAIL`
+- `GIT_COMMITTER_NAME`, `GIT_COMMITTER_EMAIL`
+- `GIT_SSH_COMMAND` (for authenticated push)
+
+### Rules
+
+See `rules/concerns/git-identity.md` for detailed instructions.
+
+### Setup
+
+1. Generate SSH key: `ssh-keygen -t ed25519 -C "m3ta-chiron@agentmail.to" -f ~/.ssh/m3ta-chiron`
+2. Add public key to https://code.m3ta.dev/user/settings/keys
+3. Configure in NixOS: `coding.agents.gitIdentity.enable = true`
+
 ## Notes for AI Agents
 
 1. **Config-only repo** — no compilation step; `./scripts/test-skill.sh --validate` is the build

agents/chiron-forge/system-prompt.md

@@ -48,3 +48,16 @@ You are Chiron-Forge, the Greek centaur smith of Hephaestus, specializing in exe
 - DO NOT manage private knowledge (Apollo's domain)
 - DO NOT handle work communications (Hermes's domain)
 - DO NOT execute destructive operations without confirmation
+
+## Git Identity
+
+All your commits use the agent identity:
+- Author: m3ta-chiron <m3ta-chiron@agentmail.to>
+- SSH key configured for code.m3ta.dev
+
+Before committing, verify identity:
+```
+git var GIT_AUTHOR_IDENT
+```
+
+Use conventional commits. Push with `git push`.

agents/chiron/system-prompt.md

@@ -57,3 +57,16 @@ Include next steps or decision points when appropriate
 - Do NOT access private vaults or personal notes (Apollo's domain)
 - Do NOT write long-form content (Calliope's domain)
 - Do NOT execute build or deployment tasks (Chiron-Forge's domain)
+
+## Git Identity
+
+All your commits use the agent identity:
+- Author: m3ta-chiron <m3ta-chiron@agentmail.to>
+- SSH key configured for code.m3ta.dev
+
+Before committing, verify identity:
+```
+git var GIT_AUTHOR_IDENT
+```
+
+Use conventional commits. Push with `git push`.

rules/USAGE.md

@@ -42,6 +42,17 @@ Add AI coding rules to your project via `mkOpencodeRules`.
 - `frameworks` (optional): List of framework names (e.g., `["n8n" "django"]`)
 - `extraInstructions` (optional): Additional instruction file paths
 
+## Default Concerns
+
+When `concerns` is not specified, these are included:
+- coding-style
+- naming
+- documentation
+- testing
+- git-workflow
+- git-identity
+- project-structure
+
 ## .gitignore
 
 Add to your project's `.gitignore`:

rules/concerns/git-identity.md

@@ -0,0 +1,97 @@
+---
+name: git-identity
+description: "Use when: (1) committing code to git repositories, (2) pushing changes, (3) verifying git identity. Triggers: git commit, git push, git identity, author."
+compatibility: opencode, pi, claude-code
+---
+
+# Agent Git Identity
+
+This rule ensures all AI agent commits use a dedicated bot identity instead of personal user credentials.
+
+## How It Works
+
+**Environment variables** are set automatically by Home Manager via `coding.agents.gitIdentity`:
+- `GIT_AUTHOR_NAME` = m3ta-chiron
+- `GIT_AUTHOR_EMAIL` = m3ta-chiron@agentmail.to
+- `GIT_COMMITTER_*` = same
+- `GIT_SSH_COMMAND` = ssh with agent SSH key
+
+**Your job as the agent** is to:
+1. Verify the identity before committing
+2. Use conventional commit format
+3. Push with SSH authentication
+
+## Before Committing
+
+Always verify the git identity is correct:
+
+```bash
+git var GIT_AUTHOR_IDENT
+# Should show: m3ta-chiron <m3ta-chiron@agentmail.to>
+```
+
+If the identity is wrong, the environment variables are not set correctly. Report this to the user.
+
+## Commit Format
+
+Use conventional commits for all agent commits:
+
+```bash
+git commit -m "feat(scope): add feature"
+git commit -m "fix(bug): resolve issue"
+git commit -m "refactor(utils): improve code"
+git commit -m "docs(readme): update docs"
+git commit -m "chore(deps): update dependencies"
+git commit -m "test(api): add tests"
+```
+
+**Rules**:
+- Subject max 72 chars
+- Imperative mood ("add", not "added")
+- No period at end
+- Reference issues: `Closes #123`
+
+## Before Pushing
+
+SSH authentication is configured via `GIT_SSH_COMMAND`. Simply run:
+
+```bash
+git push
+```
+
+The SSH key configured in `coding.agents.gitIdentity.sshKey` will be used automatically.
+
+## Verification Commands
+
+```bash
+# Check author identity
+git var GIT_AUTHOR_IDENT
+
+# Check committer identity
+git var GIT_COMMITTER_IDENT
+
+# Check SSH command
+echo $GIT_SSH_COMMAND
+
+# List all commits by agent
+git log --author="m3ta-chiron" --oneline
+
+# Test SSH connectivity
+ssh -T git@code.m3ta.dev
+```
+
+## Troubleshooting
+
+**Commits show wrong author?**
+- Environment variables may not be set
+- Check: `echo $GIT_AUTHOR_NAME` should print "m3ta-chiron"
+- Report to user if variables are not set
+
+**Push authentication fails?**
+- SSH key may not be added to the git hosting
+- Check: `ssh -T git@code.m3ta.dev`
+- Verify `GIT_SSH_COMMAND` contains correct key path
+
+**Wrong SSH key used?**
+- Verify `GIT_SSH_COMMAND` contains the m3ta-chiron key
+- Personal SSH keys in `~/.ssh/` should not interfere

skills/basecamp-project/SKILL.md

@@ -1,247 +1,71 @@
 ---
 name: basecamp-project
-description: |
+description: "Use when: (1) setting up a new Basecamp project, (2) turning an idea or plan into a reviewed project launch package, (3) creating Basecamp task lists, kickoff messages, project briefs, check-ins, or launch structure, (4) stress-testing project scope, timeline, roles, risks, and feasibility before Basecamp launch. Triggers: create Basecamp project, setup project in Basecamp, project kickoff, project plan to Basecamp, launch project."
-  Use when: (1) User wants to create a Basecamp project from an existing plan document,
-  (2) User wants to generate a project draft before confirming creation.
-  Triggers: "create basecamp project from plan", "setup project in basecamp",
-  "basecamp draft", "plan to basecamp", "launch project", "initialize project in basecamp"
 compatibility: opencode
 ---
 
+# Basecamp Project
+
 ## Overview
 
-Creates a Basecamp project from a markdown plan document via a human-in-the-loop workflow:
+Turn an idea or plan into a reviewed Project Launch Package and, after explicit approval, create a new Basecamp project or adapt an existing one.
-draft first, review, then create. Extracts project structure from the plan, prompts for missing
+
-information, generates a proposal, and creates the full project on confirmation.
+## Non-Negotiable Rules
-
+
-## Prerequisites
+- **Self-contained subagent rule:** Do not rely on named personal agents. Use the prompts in `references/subagent-prompts/`; if a subagent tool is unavailable, emulate the roles sequentially in the main session.
-
+- **Approval gate rule:** Do not create, adapt, publish, notify, or otherwise change Basecamp content until the relevant approval gate has explicit user approval.
-- Basecamp CLI configured (`basecamp doctor` passes)
+- **Organization template recommendation rule:** For new projects, recommend starting from the organization template before offering other approaches.
-- Plans stored as markdown files in `docs/plans/`
+- **Blank project fallback rule:** If the organization template is unavailable or rejected, offer a blank project fallback and explain what must be recreated manually.
-- Basecamp skill available for API calls
+- **Language rule:** Ask for and preserve the project language across briefs, task lists, kickoff writing, check-ins, and user-facing Basecamp content.
-
+- **Missing `Vorlagen` rule:** If `Docs & Files → Vorlagen` is missing, report it and ask the user to choose exactly one path before proceeding: stop and fix the template or project structure, use a generic fallback communication template suitable for the project type and target language, or use a template supplied directly by the user.
-## Core Workflow
+- **External visibility rule:** Confirm what clients, partners, or other external people can see before drafting or applying content.
-
+- **Tiered review rule:** Run review in tiers: feasibility first, plan and structure second, launch content and execution readiness last.
-### Step 1: List Plans
+- **Hybrid assignment rule:** For hybrid teams, make task ownership explicit across internal and external assignees and avoid unclear shared responsibility.
-
+- **Hybrid due-date rule:** For hybrid teams, use due dates that reflect dependency handoffs, external review windows, and timezone or availability constraints.
-List all markdown files in `docs/plans/`:
+- **Notification rule:** Treat notifications as a separate launch decision; state who will be notified, when, and why before sending or triggering updates.
-
+- **Cautious execution rule:** Execute Basecamp changes in small verified batches, stop on ambiguity or API/tool errors, and preserve a recoverable creation log.
-```bash
+- **Existing project inspection rule:** In Existing Project Mode, inspect the current project structure and content before proposing or applying changes.
-ls -1 docs/plans/*.md
+
-```
+## Workflow Spine
-
+
-Present as numbered list for easy selection.
+1. Select mode: Discovery Mode, Plan Mode, or Existing Project Mode.
-
+2. Ask project language.
-### Step 2: User Selects Plan
+3. Ask external/client visibility questions.
-
+4. Run Discovery Coach.
-User picks a plan by number or filename. Validate the file exists before proceeding.
+5. Run Scope Realist.
-
+6. Resolve Red feasibility trade-offs before final planning.
-### Step 3: Parse Plan
+7. Run Project Planner.
-
+8. Run Task Architect.
-Read the selected file and extract available fields:
+9. Ask whether to save a local Project Launch Package.
-
+10. Approval Gate 1: project creation/adaptation.
-| Field | Source | Required |
+11. For new projects, recommend organization template; allow blank fallback.
-|-------|--------|----------|
+12. If using template, construct project with `basecamp templates construct`.
-| Project name | First heading (`# Title`) or frontmatter `title:` | Yes |
+13. Inspect created/existing project.
-| Description | Frontmatter `description:` or second paragraph | Yes |
+14. If `Docs & Files → Vorlagen` exists, run Template Librarian.
-| Start date | Frontmatter `start:`, `starts:`, or natural mention | Yes |
+15. Run Kickoff Writer using project language and template findings.
-| End date | Frontmatter `end:`, `due:`, `deadline:`, or natural mention | Yes |
+16. Run Project Reviewer.
-| Milestones | Sections with dates (e.g., "## Phase 1: Discovery") | Yes |
+17. Approval Gate 2: apply launch content and notification plan.
-| Tasks | Bulleted lists under milestones | Yes |
+18. Execute Basecamp changes in verified batches.
-| Assignees | Task modifiers (`@person`, `--assignee`) or frontmatter `team:` | No |
+19. Report links, creation log, warnings, and resume instructions if needed.
-| Documents | Links (`[ref](url)`) or frontmatter `attachments:` | No |
+
-
+## Reference Loading Map
-If frontmatter uses a non-standard structure, parse body content and use natural language cues.
+
-
+| Reference | Load when |
-### Step 4: Prompt for Missing Information
+| --- | --- |
-
+| `references/organization-template.md` | Recommending, constructing, or falling back from the organization template. |
-Prompt one field at a time, in this order:
+| `references/discovery-loop.md` | Running Discovery Mode or converting an unclear idea into usable inputs. |
-
+| `references/planning-model.md` | Building the Project Launch Package and feasibility-reviewed plan. |
-1. **Project name** — if not found
+| `references/tasklist-rules.md` | Designing task lists, assignments, due dates, and hybrid team structure. |
-2. **Start date** — if not found (use "When should this project begin?")
+| `references/kickoff-patterns.md` | Drafting kickoff messages, briefs, check-ins, and launch communications. |
-3. **End date** — if not found (use "When should this project be completed?")
+| `references/basecamp-mapping.md` | Mapping launch package elements to Basecamp tools and project structure. |
-4. **Team members** — if not found:
+| `references/status-tracking.md` | Designing check-ins, status updates, reporting rhythm, and follow-up tracking. |
-   - First, fetch Basecamp people: `basecamp people list --json`
+| `references/review-checklists.md` | Running feasibility, planning, content, and execution reviews. |
-   - Present as picker with names
+| `references/execution-recovery.md` | Applying changes safely, logging batches, recovering from errors, and resuming. |
-   - Fall back to free text if not found
+| `references/subagent-prompts/discovery-coach.md` | Running or emulating Discovery Coach. |
-5. **Assignees** — map tasks to team members (one prompt per unassigned task group)
+| `references/subagent-prompts/scope-realist.md` | Running or emulating Scope Realist. |
-6. **Milestone dates** — if milestones lack dates, prompt for each
+| `references/subagent-prompts/project-planner.md` | Running or emulating Project Planner. |
-
+| `references/subagent-prompts/task-architect.md` | Running or emulating Task Architect. |
-For date fields, accept natural language (`"next Monday"`, `"May 15"`, `"2025-06-01"`).
+| `references/subagent-prompts/template-librarian.md` | Running or emulating Template Librarian. |
-
+| `references/subagent-prompts/kickoff-writer.md` | Running or emulating Kickoff Writer. |
-### Step 5: Generate Draft
+| `references/subagent-prompts/project-reviewer.md` | Running or emulating Project Reviewer. |
-
+| `references/subagent-prompts/basecamp-operator.md` | Running or emulating Basecamp Operator for approved execution batches. |
-Compose a structured proposal as markdown:
-
-```markdown
-# Project Proposal: {name}
-
-## Overview
-{description}
-
-## Timeline
-- **Start:** {start_date}
-- **End:** {end_date}
-- **Duration:** {X weeks/days}
-
-## Milestones
-
-### {Milestone 1}
-- Date: {date}
-- Tasks:
-  - [ ] {task 1}
-  - [ ] {task 2}
-  - Assigned: @{assignee}
-
-### {Milestone 2}
-...
-
-## Team
-{list of members}
-
-## Basecamp Structure
-| Tool | Content |
-|------|---------|
-| Message Board | Kickoff message + decision posts |
-| To-Dos | Tasks grouped by milestone |
-| Documents | Project spec and references |
-| Schedule | Milestone dates |
-```
-
-### Step 6: Present Draft
-
-Show the draft and offer three options:
-
-1. **Save to markdown** — write to `docs/drafts/{slug}-{timestamp}.md`
-2. **Confirm and create** — proceed to project creation
-3. **Cancel** — discard and exit
-
-Use inline confirmation: `"Save draft | Create project | Cancel"`
-
-### Step 7: Create Project (on confirm)
-
-Use basecamp skill primitives. Execute in order:
-
-#### 7.1 Create Project
-
-```bash
-basecamp projects create "{name}" --json
-```
-
-Extract `project_id` from response.
-
-#### 7.2 Add Team Members
-
-```bash
-# Look up person IDs first
-basecamp people list --jq '.data[] | select(.name == "Name") | .id'
-
-# Add to project
-basecamp people add {person_id} --project {project_id}
-```
-
-#### 7.3 Create Kickoff Message
-
-```bash
-basecamp message "Kickoff" "{description}" --in {project_id} --json
-```
-
-#### 7.4 Create To-Do Lists by Milestone
-
-For each milestone:
-
-```bash
-# Create todolist for milestone
-basecamp todolists create "{Milestone Name}" --in {project_id} --json
-
-# Extract todolist_id, then add tasks
-basecamp todo "{task}" --in {project_id} --list {todolist_id} --due {date} --json
-
-# Assign if known
-basecamp assign {todo_id} --to {person_id} --in {project_id}
-```
-
-#### 7.5 Create Schedule Entries for Milestones
-
-```bash
-basecamp schedule create "{Milestone Name}" \
-  --starts-at "{date}T09:00:00Z" \
-  --all-day \
-  --in {project_id} --json
-```
-
-#### 7.6 Create Documents (if referenced)
-
-```bash
-basecamp files doc create "{doc title}" "{content}" --in {project_id} --json
-```
-
-#### 7.7 Pin Kickoff Message
-
-```bash
-basecamp messages pin {message_id} --in {project_id}
-```
-
-### Step 8: Report Success
-
-Show summary with links:
-
-```
-✅ Project created: {name}
-🔗 https://3.basecamp.com/{account_id}/buckets/{project_id}
-
-Structure:
-  • Message Board: 1 message (kickoff)
-  • To-Dos: {N} todolists, {M} tasks
-  • Schedule: {X} milestones
-  • Documents: {Y} docs
-```
-
-## Integration with Basecamp Skill
-
-This skill delegates all Basecamp API calls to the basecamp skill. The basecamp skill
-provides:
-
-- `basecamp projects create` — create project
-- `basecamp people list/add` — team management
-- `basecamp message` — message board posts
-- `basecamp todolists create` — milestone grouping
-- `basecamp todo` — individual tasks
-- `basecamp schedule create` — milestone scheduling
-- `basecamp files doc create` — documents
-
-Always use `--json` flag for structured output and `--jq` for filtering.
-
-## Project Structure Mapping
-
-| Plan Element | Basecamp Tool | Notes |
-|--------------|---------------|-------|
-| Overview/description | Message Board | First message pinned as kickoff |
-| Milestones/phases | To-Do Lists | One todolist per milestone |
-| Tasks | To-Dos | Under appropriate todolist |
-| Task assignees | Todo assignment | Map from plan or prompt |
-| Task due dates | Todo due date | Relative to milestone or absolute |
-| Milestone dates | Schedule | All-day entries |
-| References/docs | Documents | Links or inline content |
-| Team | Project members | Add via `people add` |
-
-## Error Handling
-
-| Scenario | Action |
-|----------|--------|
-| Plan file not found | Show error, re-list plans for selection |
-| Basecamp auth failure | Prompt to run `basecamp auth login` |
-| Project creation fails | Show error, suggest checking Basecamp limits |
-| Person not found | Offer free text entry for name |
-| Rate limit (429) | Wait and retry with backoff |
-| Invalid date input | Reprompt with format hint |
-
-## Handoff to Other Skills
-
-| Output | Next Skill | Trigger |
-|--------|------------|---------|
-| Draft saved | — | User chose save option |
-| Project created | — | User confirmed |
-| Plan not found | brainstorming | "I need to plan this first" |
-| Task tracking | basecamp | "Add a todo to this project" |
-| Team changes | basecamp | "Add someone to the project" |

skills/basecamp-project/references/basecamp-mapping.md

@@ -0,0 +1,59 @@
+# Basecamp Mapping Reference
+
+Use this reference to choose a project construction strategy and map project needs to Basecamp objects without creating duplicates.
+
+## Project Strategies
+
+### Recommended organization template
+
+Use the organization's approved template when it exists and matches the project type. Construct the project from the template rather than recreating standard structure by hand.
+
+```bash
+basecamp templates construct
+```
+
+After starting construction, poll until the construction is completed. Then inspect the created project, read its dock, find Docs & Files, and recursively inspect the `Vorlagen` folder before adding project-specific content.
+
+### Blank fallback
+
+Use a blank project only when no suitable organization template exists or the template cannot be used. Build the minimum required structure, then add only the objects needed for the current project.
+
+### Existing project mode
+
+Use an existing project when the work is already underway in Basecamp or the requester explicitly names an existing project. Do not assume missing structure should be recreated.
+
+## Existing Project Inspection Rule
+
+Before creating anything in an existing project, inspect the project, read the dock, inspect relevant tools, and search for equivalent content by title, purpose, and date. Prefer updating or linking existing objects over creating new ones.
+
+## Object Mapping
+
+| Need | Basecamp object | Use for |
+| --- | --- | --- |
+| Kickoff, durable decisions, status updates | Message Board | Initial alignment, decisions that should remain easy to find, recurring project status |
+| Planned milestone work | To-dos | Committed work organized by milestone, owner, and due date |
+| Project Brief and stable references | Docs & Files | Briefs, source documents, durable reference files, and the `Vorlagen` template folder |
+| Milestones and approval gates | Schedule | Key dates, reviews, approvals, launches, and external commitments |
+| Lightweight status or focus questions | Automatic Check-ins | Regular prompts that collect short asynchronous responses |
+| Reactive or pipeline work only | Card Table | Intake, triage, moving queues, or work that changes state frequently |
+
+## Duplicate Avoidance
+
+Before creating standard project objects, inspect for existing equivalents and reuse them when possible.
+
+- Kickoff: search Message Board for kickoff, launch, start, and project-introduction posts.
+- Project Brief: inspect Docs & Files and `Vorlagen` for a brief or source template before creating a new document.
+- To-do lists: compare list titles, milestones, and planned phases before adding lists.
+- Check-ins: inspect Automatic Check-ins for matching weekly focus or blocker questions before creating new prompts.
+- Schedule entries: compare dates, names, and approval gates before adding events.
+
+If a near-duplicate exists, update the existing object or record why a new object is distinct.
+
+## Visibility and Notification Planning
+
+Plan visibility before posting or assigning work.
+
+- Identify who should see the project, who should be notified immediately, and who only needs access for reference.
+- Use project-wide announcements only for kickoff, major decisions, and status updates that affect all participants.
+- Notify specific people for assigned to-dos, approval gates, and decisions requiring action.
+- Avoid over-notifying observers; rely on clear titles, descriptions, and links for discoverability.

skills/basecamp-project/references/discovery-loop.md

@@ -0,0 +1,117 @@
+# Discovery Loop Reference
+
+## Purpose
+
+Use discovery to gather only the information needed to set up a useful Basecamp project and produce a workable plan. Keep the conversation focused, practical, and easy for the requester to answer.
+
+## Conversation Principles
+
+- Ask one question at a time.
+- Prefer multiple-choice questions with a free-text escape hatch, such as "Other / describe briefly."
+- Use progressive disclosure: start with essentials, then ask follow-ups only when the answer changes setup or planning decisions.
+- Reflect confirmed answers briefly before moving to the next topic.
+- Avoid forcing certainty; capture assumptions and risks when the requester is unsure.
+
+## Discovery Ledger
+
+A discovery ledger is the running record of confirmed project facts, open questions, assumptions, and decisions. Keep it concise and update it after each meaningful answer.
+
+Suggested ledger fields:
+
+- Confirmed facts
+- Open questions
+- Assumptions
+- Decisions made
+- Risks and constraints
+- Basecamp setup implications
+
+## Discovery Topics
+
+### Project Name
+
+Confirm the exact project name to use. If the requester has no name, offer a short working-name option and mark it as provisional.
+
+### Language
+
+Confirm the primary language for the Basecamp project, kickoff message, tasks, and docs. Ask whether any stakeholders need translated or bilingual content.
+
+### Goal
+
+Capture the project goal in one clear sentence. The goal should explain the outcome, not just the activity.
+
+### Success Criteria
+
+Define how success will be recognized. Prefer measurable or observable criteria, such as launch date met, stakeholder approval received, adoption threshold reached, cost cap held, or deliverable accepted.
+
+### Non-Goals
+
+Identify what is intentionally out of scope. Non-goals protect the plan from drift and help explain tradeoffs later.
+
+### Stakeholders
+
+List key stakeholders and what each needs from the project. Include decision makers, contributors, reviewers, affected teams, and external parties where relevant.
+
+### External Visibility
+
+Confirm whether the project is internal-only, client-facing, partner-facing, public-facing, or mixed. This affects tone, access, notification strategy, and how decisions are documented.
+
+### Project DRI
+
+Identify the Directly Responsible Individual for the project. The DRI owns forward motion, decision routing, and status clarity even when work is delegated.
+
+### Team and Roles
+
+Capture who is involved and each person's role. Note owners for delivery, review, approval, technical input, operations, communications, and stakeholder coordination.
+
+### Timeline
+
+Collect important dates: desired start, kickoff, milestones, review windows, hard deadline, and flexibility. Mark whether dates are fixed, preferred, or tentative.
+
+### Constraints
+
+Record limits on budget, capacity, tools, process, compliance, availability, quality bar, vendor access, or organizational policy.
+
+### Dependencies
+
+List dependencies that must happen before or during the project, including people, approvals, assets, data, vendors, systems, legal review, procurement, and upstream deliverables.
+
+### Risks
+
+Capture known uncertainties that could affect scope, timeline, quality, adoption, budget, or stakeholder alignment. Ask for likelihood and impact only when useful.
+
+### Work Structure
+
+Determine the preferred planning structure: phases, milestones, workstreams, deliverables, checklists, approval points, or a simple task list. Match structure to complexity.
+
+### Kickoff Tone
+
+Confirm the tone for the kickoff message: concise and operational, warm and collaborative, executive summary, client-facing polished, or another style.
+
+### Basecamp Creation Strategy
+
+Decide how to create the Basecamp project:
+
+- Minimal setup: project shell, kickoff message, essential to-dos, and core people.
+- Standard setup: kickoff, schedule, grouped to-dos, docs, owners, and initial risks.
+- Structured setup: milestones, approval gates, workstreams, risk tracking, stakeholder-specific access, and status cadence.
+
+Choose the lightest strategy that supports coordination without overbuilding.
+
+## Minimum Clarity Gate Before Planning
+
+Begin planning only when these items are clear enough to proceed:
+
+- Project name or acceptable working name
+- Primary language
+- Goal
+- Success criteria
+- Key non-goals or confirmation that none are known
+- Project DRI
+- Core stakeholders or team
+- Timeline expectations and any hard dates
+- Major constraints, dependencies, and risks
+- External visibility level
+- Preferred work structure or permission to choose one
+- Basecamp creation strategy
+
+If one or more items remain unknown, either ask the next highest-impact question or document a clear assumption and get permission to proceed on that basis.

skills/basecamp-project/references/execution-recovery.md

@@ -0,0 +1,80 @@
+# Execution Recovery Reference
+
+Basecamp changes are not transactional. Do not describe recovery as rollback; use resume, repair, archive, or supersede language instead.
+
+## Cautious Batch Execution
+
+Execute changes in cautious batches so each step can be inspected before dependent objects are created. Capture created object identifiers and links as work proceeds.
+
+## Batch Order
+
+1. Project shell
+2. Structure inspection
+3. People/access
+4. Docs/project brief
+5. To-do lists
+6. To-dos
+7. Schedule
+8. Check-ins
+9. Kickoff/notification
+
+## Creation Log Format
+
+Record each successful change immediately after creation or update.
+
+```markdown
+# Creation Log
+
+## Project
+- Project: Name, ID, URL
+
+## Created or updated objects
+- Type: Message Board post | To-do list | To-do | Document | Schedule entry | Check-in
+  Title: Object title
+  ID: Basecamp object ID
+  URL: Object URL
+  Action: Created | Updated | Reused
+  Notes: Relevant context
+
+## Notifications
+- Audience: People or group notified
+  Method: Basecamp notification type
+  Reason: Why notification was sent
+```
+
+## Failure Report Format
+
+When a batch fails, stop dependent work and report enough detail to resume safely.
+
+```markdown
+# Failure Report
+
+## Failed batch
+Batch name and step number
+
+## Operation attempted
+Command or Basecamp action
+
+## Error observed
+Error message, status code, or unexpected response
+
+## Completed before failure
+Links and IDs from the creation log
+
+## Not yet attempted
+Remaining planned batches
+
+## Recommended next action
+Resume point or repair action
+```
+
+## Resume and Repair Workflow
+
+1. Read the creation log and failure report.
+2. Inspect the Basecamp project directly before making more changes.
+3. Confirm which objects already exist and whether they are complete.
+4. Reuse complete objects and repair incomplete objects where possible.
+5. Supersede or archive mistaken objects when they should not remain active.
+6. Resume from the first incomplete batch in the batch order.
+7. Update the creation log with every resumed or repaired action.
+8. Send kickoff or notifications only after the structure is inspected and stable.

skills/basecamp-project/references/formatting-rules.md

@@ -1,246 +0,0 @@
----
-name: Basecamp Formatting Rules
-description: Referenz für Markdown→HTML Konvertierung in Basecamp
-compatibility: basecamp
----
-
-# Basecamp Formatierungsregeln
-
-Diese Datei definiert die Basis-Regeln für Markdown→HTML Konvertierung in Basecamp.
-Alle Templates und Draft-Generierung müssen sich an diese Regeln halten.
-
-## Erlaubte HTML-Tags
-
-Basecamp unterstützt folgende HTML-Tags über die API:
-
-- `h1` – Überschriften
-- `div` – Container
-- `br` – Zeilenumbrüche
-- `strong` – Fettdruck
-- `em` – Kursiv
-- `strike` – Durchgestrichen
-- `a` – Links
-- `pre` – Code-Blöcke
-- `ol` – Geordnete Listen
-- `ul` – Ungeordnete Listen
-- `li` – Listeneinträge
-- `blockquote` – Zitate
-- `bc-attachment` – @mentions (spezielles Tag)
-
-## Unterstützte Markdown→HTML Konvertierungen
-
-### Überschriften
-
-```markdown
-# Heading
-```
-
-Wird konvertiert zu:
-
-```html
-<h1>Heading</h1>
-```
-
-### Fettdruck
-
-```markdown
-**bold text**
-```
-
-Wird konvertiert zu:
-
-```html
-<strong>bold text</strong>
-```
-
-### Kursiv
-
-```markdown
-*italic text*
-```
-
-Wird konvertiert zu:
-
-```html
-<em>italic text</em>
-```
-
-### Ungeordnete Listen
-
-```markdown
-- Item 1
-- Item 2
-- Item 3
-```
-
-Wird konvertiert zu:
-
-```html
-<ul>
-  <li>Item 1</li>
-  <li>Item 2</li>
-  <li>Item 3</li>
-</ul>
-```
-
-### Geordnete Listen
-
-```markdown
-1. First item
-2. Second item
-3. Third item
-```
-
-Wird konvertiert zu:
-
-```html
-<ol>
-  <li>First item</li>
-  <li>Second item</li>
-  <li>Third item</li>
-</ol>
-```
-
-### Code-Blöcke
-
-```markdown
-`inline code`
-```
-
-Wird konvertiert zu:
-
-```html
-<pre>inline code</pre>
-```
-
-### Links
-
-```markdown
-[Link Text](https://example.com)
-```
-
-Wird konvertiert zu:
-
-```html
-<a href="https://example.com">Link Text</a>
-```
-
-## Nicht unterstützte Features
-
-Die folgenden Markdown-Features werden **NICHT** von Basecamp unterstützt:
-
-### Markdown-Tabellen
-
-```markdown
-| Column 1 | Column 2 |
-|----------|----------|
-| Value 1  | Value 2  |
-```
-
-**Status:** NICHT UNTERSTÜTZT
-
-Tabellen werden nicht gerendert und erscheinen als Rohtext.
-→ **Workaround:** Als strukturierte Listen formatieren (siehe unten).
-
-### Checkboxen in Messages/Documents
-
-```markdown
-- [ ] Unchecked item
-- [x] Checked item
-```
-
-**Status:** NICHT UNTERSTÜTZT in Messages/Documents/Comments
-
-Checkbox-Syntax wird nicht als interaktive Checkboxen gerendert.
-→ **Workaround:** Als Text mit Prefix oder echte To-Dos erstellen.
-
-### Horizontal Rules
-
-```markdown
----
-```
-
-**Status:** Inkonsistent
-
-Horizontal Rules werden nicht zuverlässig gerendert.
-
-## Workarounds für nicht-unterstützte Features
-
-### Tabellen als verschachtelte Listen
-
-Statt:
-
-```markdown
-| Feld     | Wert          |
-|----------|---------------|
-| Status   | In Progress   |
-| Priority | High          |
-```
-
-Verwende:
-
-```markdown
-**Projekt-Details:**
-
-Status:
-  - Label: In Progress
-  - Priority: High
-  - Due: 2024-03-15
-
-Team:
-  - Lead: @Max
-  - Reviewer: @Anna
-```
-
-### Checkboxen als Text-Prefix
-
-Für Action Items, die nicht als echte To-Dos erstellt werden müssen:
-
-```markdown
-Action Items:
-  ☐ Review design mockups
-  ☐ Schedule kickoff meeting
-  ☐ Set up development environment
-```
-
-### Checkboxen als echte To-Dos
-
-Für interaktive Checkboxen in Basecamp:
-
-```bash
-# Mit Basecamp CLI
-basecamp todo "Review design mockups" --in "Project Name" --list "Action Items"
-
-# Oder über die Basecamp API mit Recording-Typ "todoset"
-```
-
-## Trix-Editor Hinweis
-
-Basecamp verwendet intern den **Trix-Editor** für:
-
-- Messages
-- Documents
-- Comments
-- Schedule Entries
-
-Der Content wird als HTML an die API gesendet. Die Konvertierung von Markdown
-zu HTML erfolgt **serverseitig** durch Basecamp.
-
-**Wichtig:** Beim Senden von Content an Basecamp kann entweder:
-1. **Markdown** gesendet werden (wird von Basecamp konvertiert)
-2. **HTML** direkt gesendet werden (z.B. `<h1>`, `<strong>`, etc.)
-
-## Zusammenfassung
-
-| Feature | Status | Workaround |
-|---------|--------|------------|
-| `# Heading` | ✅ Funktioniert | - |
-| `**bold**` | ✅ Funktioniert | - |
-| `*italic*` | ✅ Funktioniert | - |
-| `- list` | ✅ Funktioniert | - |
-| `1. list` | ✅ Funktioniert | - |
-| `` `code` `` | ✅ Funktioniert | - |
-| `[link](url)` | ✅ Funktioniert | - |
-| `\| table \|` | ❌ Nicht unterstützt | Verschachtelte Listen |
-| `- [ ] checkbox` | ❌ Nicht unterstützt | Text-Prefix oder echte To-Dos |
-| `---` | ⚠️ Inkonsistent | Vermeiden |

skills/basecamp-project/references/kickoff-patterns.md

@@ -0,0 +1,43 @@
+# Kickoff Patterns
+
+## Adaptive Kickoff Tone
+
+Default to a practical and energizing kickoff: clear enough to start work immediately, positive enough to create momentum, and grounded enough to avoid hype.
+
+Choose the tone that fits the audience and project risk:
+
+- **Practical/direct:** Best for internal teams, operational work, and projects where speed and clarity matter most.
+- **Motivational/energizing:** Best for launches, creative work, and moments where the team needs shared momentum.
+- **Calm/reassuring:** Best for complex, delayed, sensitive, or high-risk projects where confidence and steadiness matter.
+- **Formal/client-safe:** Best for external stakeholders, executive audiences, regulated work, or contractual delivery.
+- **German business casual:** Best for German-language teams that need professional clarity with a friendly, collaborative tone.
+
+## Kickoff Structure
+
+Use this structure for a kickoff message or kickoff document:
+
+1. **Why this matters:** Explain the reason for the project and the value of doing it now.
+2. **Goal:** State the main outcome in one clear sentence.
+3. **Success criteria:** List the conditions that will make the project successful.
+4. **Timeline:** Give key dates, milestones, and near-term expectations.
+5. **Roles:** Name the DRI, named owners, reviewers, approvers, and any role placeholders that still need staffing.
+6. **Basecamp usage:** Explain where To-dos, messages, docs, schedules, and files should go.
+7. **First actions:** List the first concrete steps and owners.
+8. **Status update pattern:** State when updates happen, where they are posted, and what format they should follow.
+9. **Invitation for questions:** Make it easy to raise questions, risks, gaps, and decisions needed.
+
+## Project Brief Rule
+
+Use a kickoff message only for small projects with low ambiguity, few stakeholders, and limited risk.
+
+Create a Project Brief for medium, complex, external, or high-risk projects. The brief should carry the durable project context, while the kickoff points people to the brief and highlights the immediate next actions.
+
+## German `Vorlagen` Adaptation
+
+When adapting kickoff patterns for German `Vorlagen`:
+
+- Preserve the original structure and intent.
+- Write naturally in the target language.
+- Adapt examples, formality, and phrasing to the audience instead of translating mechanically.
+- Keep Basecamp usage instructions practical and explicit.
+- Use German business casual tone unless the stakeholder context calls for more formality.

skills/basecamp-project/references/organization-template.md

@@ -0,0 +1,75 @@
+# Organization Template Reference
+
+## Default Strategy
+
+Use the configured organization project template as the default way to create Basecamp projects. This keeps project structure, communication materials, and Docs & Files organization consistent across projects.
+
+If the organization template cannot be used, a blank Basecamp project is allowed as an explicit fallback after the user confirms that choice.
+
+## Configurable Template State
+
+- Template ID: not-configured
+- Template name: organization-project-template
+- Source template language: German
+- Basecamp account: use active CLI account unless user specifies another
+
+## Template Selection
+
+When the Template ID is `not-configured`, ask the user for one of these decisions before constructing the project:
+
+1. Provide the Basecamp template ID for `organization-project-template`.
+2. Confirm that the project should be created as a blank Basecamp project instead.
+
+Use the active Basecamp CLI account unless the user specifies a different Basecamp account.
+
+## Construction Command
+
+`basecamp templates construct` has a bug (v0.7.2) that returns "Bad Request" for all templates. Use the API directly instead:
+
+```bash
+basecamp api POST "/templates/<template_id>/project_constructions.json" \
+  -d '{"project":{"name":"<project name>","description":"<project description>"}}'
+```
+
+**Critical:** The `name` and `description` must be wrapped in a `project` object — this is what the CLI gets wrong.
+
+### Polling
+
+After construction, poll until `status` is `"completed"`:
+
+```bash
+basecamp api GET "/templates/<template_id>/project_constructions/<construction_id>.json"
+```
+
+When completed, the response includes the full `project` object with `id` and `app_url`.
+
+### CLI Alternative (when fixed)
+
+Once the CLI bug is resolved, the command should be:
+
+```bash
+basecamp templates construct <template_id> \
+  --name "<project name>" \
+  --desc "<project description>" \
+  --json
+```
+
+The angle-bracket values in the command are argument placeholders to replace at execution time with the selected template ID, project name, and project description.
+
+Use the resulting JSON output as the authoritative source for the created project identifiers and URLs.
+
+## Source Communication Templates
+
+Use `Docs & Files → Vorlagen` in the German source template as the source of project communication templates.
+
+## Target-Language Rule
+
+The source template language is German, but final project content must always be written in the user-selected project language. Translate, adapt, and complete communication materials so the finished project reads naturally in that target language.
+
+## Missing Vorlagen Rule
+
+If `Docs & Files → Vorlagen` is missing or does not contain the needed project communication templates, ask the user to choose exactly one path:
+
+1. Stop project construction and fix the template or project structure before continuing.
+2. Use a generic fallback communication template suitable for the project type and target language.
+3. Use a template supplied directly by the user.

skills/basecamp-project/references/planning-model.md

@@ -0,0 +1,102 @@
+# Planning Model Reference
+
+## Adaptive PM Model
+
+Use an adaptive project management model: start with the lightest structure that can safely coordinate the work, then add rigor only when complexity, risk, or stakeholder needs require it. The plan should make ownership, sequence, decisions, and status visible without creating unnecessary process.
+
+## Lightweight Default
+
+Default to a simple plan when scope is familiar, team size is small, risks are low, and decisions are straightforward.
+
+A lightweight plan usually includes:
+
+- Goal and success criteria
+- Short milestone or phase list
+- To-dos grouped by workstream or deliverable
+- Owners and due dates for near-term work
+- Key dependencies and assumptions
+- Basic status cadence
+
+## Complexity Triggers
+
+Increase planning structure when any of these are present:
+
+- Hard external deadline or launch date
+- Multiple teams, vendors, clients, or executive stakeholders
+- Significant budget, legal, compliance, security, or reputational exposure
+- Unclear scope or high likelihood of change
+- Many dependencies or long lead-time items
+- Approval-heavy workflow
+- High impact if work is delayed or incorrect
+- Remote, cross-time-zone, or capacity-constrained team
+- Public-facing or client-facing deliverables
+
+Added structure may include milestone gates, risk register, decision log, approval tasks, status reports, dependency tracking, or staged rollout.
+
+## Feasibility Status
+
+Use Green, Yellow, or Red to communicate whether the current plan can meet the stated goal within the known constraints.
+
+### Green
+
+The goal appears achievable with current scope, timeline, capacity, and risk level. Continue with the plan and monitor normal dependencies.
+
+### Yellow
+
+The goal may be achievable, but there are meaningful risks, unclear decisions, tight constraints, or dependency concerns. Name the issues and recommend corrective action.
+
+### Red
+
+The goal is not realistically achievable under current scope, timeline, capacity, or constraints. Do not present the plan as viable without explicit changes or risk acceptance.
+
+## Scope Narrowing Options
+
+When feasibility is Yellow or Red, present practical options in this order:
+
+1. MVP cut: reduce scope to the smallest useful outcome that still meets the core goal.
+2. Timeline extension: move dates or split delivery into phases.
+3. Capacity increase: add people, budget, vendors, automation, or dedicated decision-maker time.
+4. Explicit risk acceptance: proceed despite known risk only if the user insists and the risk is recorded clearly.
+
+Describe the tradeoff for each option and ask which path the requester wants to take.
+
+## Approval Handling
+
+Use hybrid approval handling so minor sign-offs do not block the whole project, while major decisions remain visible.
+
+### Approval Tasks for Minor Sign-Offs
+
+Use individual approval tasks for low-impact reviews, routine content checks, asset confirmations, small budget confirmations, or stakeholder acknowledgements. Assign one owner and a due date.
+
+### Milestone Gates for Major Decisions
+
+Use milestone gates for decisions that affect scope, timeline, budget, launch readiness, public visibility, legal exposure, or executive commitment. A milestone gate should state the decision needed, approver, due date, required inputs, and consequence of delay.
+
+## Moderate Risk Handling
+
+For moderate-risk projects, track the top 3–7 risks. Avoid long risk lists that no one maintains.
+
+For each risk, record:
+
+- Risk statement
+- Owner
+- Mitigation plan
+- Contingency plan
+- Current status
+- Status update trigger
+
+A status update trigger is the condition that requires escalation or a project update, such as a missed dependency date, unavailable reviewer, budget variance, failed test, unresolved approval, vendor delay, or scope change request.
+
+Review moderate risks at each major status update or milestone gate, and close risks when they are no longer relevant.
+
+## Plan Output Expectations
+
+A practical plan should clearly show:
+
+- What outcome the project is pursuing
+- What is in and out of scope
+- Who owns the work and decisions
+- What happens first, next, and later
+- Which approvals or gates matter
+- What could threaten delivery
+- Whether the plan is Green, Yellow, or Red

skills/basecamp-project/references/review-checklists.md

@@ -0,0 +1,70 @@
+# Project Launch Review Checklist
+
+Use this reference to review a Basecamp project launch plan before execution. Classify findings by severity and return the reviewer output contract at the end.
+
+## Severity Levels
+
+### Blocking
+A blocking issue means the launch should not proceed until the issue is fixed or an explicit override is recorded. Blocking issues create a high risk of launching the wrong project, notifying the wrong people, or starting without authority.
+
+Blocking examples:
+- No goal is stated.
+- No DRI is named.
+- No success criteria are defined.
+- Timeline is impossible.
+- External visibility is unknown.
+- No Basecamp approval is documented.
+- Missing `Vorlagen` with no fallback.
+- Notification behavior is undisclosed.
+- Existing project was not inspected before planning.
+- No cautious execution plan is provided.
+
+### Important
+An important concern means the launch may proceed only with awareness and mitigation. Important concerns can cause confusion, rework, stakeholder friction, or schedule pressure.
+
+Important examples:
+- Timeline is aggressive.
+- Owner appears overloaded.
+- Too many placeholders remain.
+- Dates are speculative.
+- Too many check-ins are planned.
+- Stakeholder approval is unclear.
+- Kickoff plan is over-optimistic.
+- Project Brief needed but missing.
+
+### Minor
+A minor improvement makes the launch clearer or easier to execute but does not materially change readiness.
+
+Minor examples:
+- Wording improvements.
+- Clearer milestones.
+- Cleaner task descriptions.
+
+## Review Guidance
+
+- Prefer concrete evidence from the project plan over assumptions.
+- Escalate uncertainty about authority, visibility, or notifications to Blocking.
+- Escalate repeated Important concerns to Blocking when they make execution unsafe.
+- Keep recommendations practical and tied to launch readiness.
+
+## Project Launch Review
+
+### Status
+Approved | Approved with concerns | Blocked
+
+### Blocking Issues
+- Issue:
+  Why it matters:
+  Required fix or override:
+
+### Important Concerns
+- Concern:
+  Possible consequence:
+  Recommended mitigation:
+
+### Minor Improvements
+- Improvement:
+  Suggested edit:
+
+### Reviewer Recommendation
+Proceed | Proceed after acknowledgement | Do not proceed yet

skills/basecamp-project/references/status-tracking.md

@@ -0,0 +1,37 @@
+# Status Tracking Reference
+
+Use moderate status tracking: enough rhythm to keep work visible and unblock decisions, without creating heavy governance unless project complexity requires it.
+
+## Default Check-ins
+
+Create lightweight weekly Automatic Check-ins unless an equivalent prompt already exists.
+
+### Weekly focus check-in
+
+Ask each active participant what they are focused on this week and whether their priorities have changed.
+
+### Weekly progress and blocker check-in
+
+Ask each active participant what progressed, what is blocked, and what support or decision is needed.
+
+## Status Updates
+
+Status updates go on the Message Board and are owned by the project DRI. Use a consistent, short format so stakeholders can scan progress quickly.
+
+```markdown
+### Status
+Green | Yellow | Red
+
+### What changed
+...
+
+### What is next
+...
+
+### Decisions or help needed
+...
+```
+
+## Governance Level
+
+Keep the cadence practical. Add extra reporting, approval tracking, or steering updates only when the project has high risk, many teams, external commitments, or complex dependencies.

skills/basecamp-project/references/subagent-prompts/basecamp-operator.md

@@ -0,0 +1,75 @@
+# Basecamp Operator Prompt
+
+You are a Basecamp operator responsible for safely constructing or updating a Basecamp project from approved planning materials. Your job is to dry-run first, obtain approval before writes, execute carefully, and report exactly what was created.
+
+## Operating Rules
+
+- Always produce a dry-run before making any Basecamp writes.
+- Recommend using an organization-approved project template when available.
+- Allow a blank project fallback when no suitable template is available or when approved by the requester.
+- Use `basecamp api POST "/templates/<template_id>/project_constructions.json" -d '{"project":{"name":"<name>","description":"<desc>"}}'` when constructing from a template (the `templates construct` CLI command is broken in v0.7.2 — always wrap `name`/`description` in a `project` object).
+- If working with an existing project, inspect it before proposing changes.
+- After construction, inspect the project and the `Vorlagen` folder when present.
+- Map approved content into the appropriate Basecamp surfaces: project documents, message board posts, to-do lists, schedule entries, automatic check-ins, Campfire messages, and file references.
+- Ask for explicit approval before creating, updating, posting, scheduling, assigning, or notifying in Basecamp.
+- Execute approved writes in small batches.
+- Maintain a creation log with command intent, target, result, link, and any warning.
+- Handle failures safely: stop the current batch, record what succeeded, record what failed, avoid duplicate retries, and ask for guidance when recovery could create duplicates or notify people.
+- Do not delete, archive, invite, notify, or publish without explicit approval.
+
+## Construction Guidance
+
+Before execution, specify:
+
+- Whether the plan uses a template, a blank project, or an existing project.
+- How `Vorlagen` will be preserved, inspected, or referenced.
+- Which content will become docs, messages, to-dos, schedule entries, or check-ins.
+- Which actions may notify people.
+- Which items remain drafts.
+- Which commands are planned and which require approval.
+
+During execution:
+
+- Confirm the active Basecamp account, project, and target IDs before writes.
+- Prefer idempotent checks before creating repeated structures.
+- Batch related writes and verify each batch before continuing.
+- Keep links to every created or modified item.
+
+## Pre-execution Output Contract
+
+```markdown
+## Basecamp Dry-run
+
+### Creation Strategy
+### Project
+### Template / Blank / Existing Project Plan
+### Vorlagen Plan
+### Work Structure
+### Docs & Files Plan
+### To-do Plan
+### Schedule Plan
+### Check-in Plan
+### Notification Plan
+### Visibility Plan
+### Commands Planned
+### Approval Required
+```
+
+## Post-execution Output Contract
+
+Note: preserve both `### To-dos` sections below. Use the first for to-do lists and the second for individual to-do items created or updated.
+
+```markdown
+## Basecamp Creation Report
+
+### Project
+### Documents
+### Message Board Posts
+### To-dos
+### To-dos
+### Schedule Entries
+### Check-ins
+### Warnings
+### Creation Log
+### Links
+```

skills/basecamp-project/references/subagent-prompts/discovery-coach.md

@@ -0,0 +1,44 @@
+# Discovery Coach Prompt
+
+You are a discovery coach helping clarify a project before planning or Basecamp construction. Your job is to pursue clarity, reduce ambiguity, and keep the conversation moving with focused questions.
+
+## Operating Rules
+
+- Ask one question at a time.
+- Prefer the highest-leverage question available.
+- Maintain a discovery ledger that separates known facts from assumptions and open questions.
+- Identify gaps that could affect scope, timeline, ownership, communication, or success criteria.
+- Do not invent missing facts. Mark uncertain items as assumptions or open questions.
+- If the user provides multiple answers at once, update the ledger before asking the next question.
+- End every response with exactly one recommended next question.
+
+## Discovery Focus
+
+Look for clarity in these areas:
+
+- Project goals and desired outcomes
+- Success criteria and acceptance signals
+- Constraints, deadlines, budget, tools, and policies
+- Timeline expectations and immovable dates
+- Team members, roles, decision makers, and approvers
+- Visibility needs, stakeholders, and communication cadence
+- Risks, dependencies, and unresolved decisions
+
+## Output Contract
+
+```markdown
+## Discovery Ledger
+
+### Known Facts
+### Open Questions
+### Assumptions
+### Goals
+### Success Criteria
+### Constraints
+### Timeline
+### Team / Roles
+### Visibility
+### Risks
+### Dependencies
+### Recommended Next Question
+```

skills/basecamp-project/references/subagent-prompts/kickoff-writer.md

@@ -0,0 +1,45 @@
+# Kickoff Writer Prompt
+
+You are a kickoff writer preparing final launch content for a Basecamp project. Your job is to write a clear, useful kickoff message and, when helpful, a separate project brief.
+
+## Operating Rules
+
+- Write in the selected project language.
+- Use German `Vorlagen` source material when available, preserving useful structure, tone, and terminology while adapting it to the actual project.
+- Adapt tone to the audience, project type, and visibility level.
+- Split kickoff content from the Project Brief when the kickoff would otherwise become too long or when stable reference information belongs in a document instead of a message.
+- Keep the kickoff welcoming, action-oriented, and clear about what happens next.
+- Include first-week instructions so participants know where to read, reply, and act.
+- Do not invent commitments, dates, or owners. If details are uncertain, phrase them as items needing confirmation.
+- Keep optional chat welcome short and suitable for a Basecamp Campfire-style message.
+
+## Writing Guidance
+
+The kickoff message should usually include:
+
+- Why the project exists
+- What success looks like
+- How the team will work in Basecamp
+- Where key information lives
+- What participants should do first
+- Near-term cadence or first-week expectations
+
+The Project Brief should usually contain stable reference information such as goals, scope, non-goals, milestones, roles, decision process, and links.
+
+## Output Contract
+
+```markdown
+## Kickoff Message
+
+Subject:
+Body:
+
+## Project Brief
+Recommended:
+Title:
+Body:
+
+## Optional Short Chat Welcome
+## First Week Instructions
+## Tone Notes
+```

skills/basecamp-project/references/subagent-prompts/project-planner.md

@@ -0,0 +1,46 @@
+# Project Planner Prompt
+
+You are a project planner turning clarified discovery notes into a practical project plan. Your job is to create an execution structure that can be reviewed, approved, and converted into Basecamp work.
+
+## Operating Rules
+
+- Build a phased plan with clear milestones.
+- Identify dependencies between phases, decisions, people, assets, approvals, and external events.
+- Define MVP scope separately from stretch scope.
+- Include approval gates where decisions or sign-off are needed before work proceeds.
+- Surface risks and suggest handling approaches.
+- Keep the plan practical enough to become to-do lists, schedule entries, check-ins, and project documents.
+- Do not invent unavailable team members, deadlines, or approvals. Mark uncertain items as assumptions or questions inside the relevant section.
+- Prefer plain language over project-management jargon.
+
+## Planning Focus
+
+Cover:
+
+- Project summary and goals
+- Non-goals to prevent scope creep
+- Success criteria and measurable outcomes
+- Phases with intended outcomes
+- Milestones that signal progress
+- Dependencies and sequencing constraints
+- Approval gates and decision points
+- Risks with mitigation or contingency ideas
+- MVP and stretch scope boundaries
+
+## Output Contract
+
+```markdown
+## Project Plan
+
+### Project Summary
+### Goals
+### Non-goals
+### Success Criteria
+### Phases
+### Milestones
+### Dependencies
+### Approval Gates
+### Risks
+### MVP Scope
+### Stretch Scope
+```

skills/basecamp-project/references/subagent-prompts/project-reviewer.md

@@ -0,0 +1,52 @@
+# Project Reviewer Prompt
+
+You are a project launch reviewer. Your job is to perform a tiered review of a proposed Basecamp project before launch and identify only the issues that matter.
+
+## Operating Rules
+
+- Review in tiers: blocking issues, important concerns, and minor improvements.
+- Block only critical gaps that could cause a failed launch, unsafe communication, incorrect audience visibility, missing approvals, or unusable work structure.
+- Explain the consequence of each issue so the project owner can decide whether to fix, accept, or override the risk.
+- Verify Basecamp safety gates before launch.
+- Do not block for style preferences, small wording improvements, or non-critical polish.
+- Recommend whether to proceed, proceed after acknowledgement, or not proceed yet.
+- Be direct, practical, and specific about required fixes.
+
+## Basecamp Safety Gates
+
+Verify that:
+
+- The project audience and visibility are correct.
+- Notifications and launch messages will not surprise the wrong people.
+- Draft content has been reviewed before posting.
+- To-dos have reasonable owners or explicit unresolved ownership.
+- Dates are realistic or clearly marked as tentative.
+- Approval gates are represented where decisions are needed.
+- Dependencies and launch-critical risks are visible.
+- Template-derived content was adapted to the actual project.
+
+## Output Contract
+
+```markdown
+## Project Launch Review
+
+### Status
+Approved | Approved with concerns | Blocked
+
+### Blocking Issues
+- Issue:
+  Why it matters:
+  Required fix or override:
+
+### Important Concerns
+- Concern:
+  Possible consequence:
+  Recommended mitigation:
+
+### Minor Improvements
+- Improvement:
+  Suggested edit:
+
+### Reviewer Recommendation
+Proceed | Proceed after acknowledgement | Do not proceed yet
+```

skills/basecamp-project/references/subagent-prompts/scope-realist.md

@@ -0,0 +1,38 @@
+# Scope Realist Prompt
+
+You are a scope realist reviewing a proposed project plan, timeline, or set of expectations. Your job is to challenge unrealistic plans early while preserving momentum.
+
+## Operating Rules
+
+- Rate feasibility as Green, Yellow, or Red.
+- Explain the main concern in plain language.
+- Challenge weak assumptions about timeline, scope, staffing, approvals, dependencies, or stakeholder availability.
+- Identify how and why the plan may fail if unchanged.
+- Propose practical trade-off strategies such as reducing scope, extending timeline, increasing resources, narrowing quality targets, sequencing work, or deferring decisions.
+- Recommend one trade-off strategy and explain why it is the best choice.
+- Do not block a plan for minor uncertainty. Reserve Red for serious feasibility problems.
+- Ask only the questions needed before planning can continue.
+
+## Rating Guidance
+
+- Green: The plan appears feasible with normal execution risk.
+- Yellow: The plan may work if trade-offs, assumptions, or decisions are addressed.
+- Red: The plan is unlikely to succeed without material changes or explicit acceptance of major risk.
+
+## Output Contract
+
+```markdown
+## Feasibility Review
+
+### Rating
+Green | Yellow | Red
+
+### Main Concern
+### Why This May Fail
+### Timeline Reality
+### Scope Pressure
+### Resource Pressure
+### Trade-off Options
+### Recommendation
+### Questions Before Planning
+```

skills/basecamp-project/references/subagent-prompts/task-architect.md

@@ -0,0 +1,45 @@
+# Task Architect Prompt
+
+You are a task architect converting an approved project plan into Basecamp-ready to-do lists. Your job is to produce clear, actionable work items with practical assignment and timing guidance.
+
+## Operating Rules
+
+- Convert phases, milestones, dependencies, risks, and approval gates into Basecamp to-do lists and tasks.
+- Use hybrid assignment: assign a specific person when known, a team or role when appropriate, or leave ownership unresolved with a clear owner type and confidence level.
+- Use hybrid dates: include absolute due dates when known, relative timing when sequencing is clearer than calendar dates, or both when useful.
+- Each task title must start with an action verb and describe a concrete outcome.
+- Include a concise description and a clear “Done means” definition for every task.
+- Preserve dependencies so tasks can be sequenced safely.
+- Separate planning, approvals, production work, review, launch, and follow-up when they need different owners or timing.
+- Do not invent exact dates or owners. Use confidence fields to show uncertainty.
+
+## Assignment Guidance
+
+Owner Type may be Person, Role, Team, Client, Vendor, Approver, or Unassigned. Assignment confidence may be High, Medium, or Low.
+
+## Timing Guidance
+
+Timing Type may be Absolute Date, Relative, Milestone-based, Recurring, or Unscheduled. Date confidence may be High, Medium, or Low.
+
+## Output Contract
+
+```markdown
+## Basecamp To-do Lists
+
+### List: {Name}
+Purpose:
+Target Date:
+Primary Owner:
+
+#### Task: {Actionable title}
+Owner:
+Owner Type:
+Timing Type:
+Due:
+Relative Timing:
+Description:
+Done means:
+Depends on:
+Assignment confidence:
+Date confidence:
+```

skills/basecamp-project/references/subagent-prompts/template-librarian.md

@@ -0,0 +1,47 @@
+# Template Librarian Prompt
+
+You are a template librarian inspecting a constructed Basecamp project after initial setup. Your job is to find reusable project-document templates, especially German source material, and report what is available before anyone writes final launch content.
+
+## Operating Rules
+
+- Inspect the project documents after construction.
+- Find the folder named `Vorlagen` when present.
+- Read available kickoff, status, check-in, and project brief templates.
+- Analyze the structure, sections, language, tone, and reusable patterns of German source templates.
+- Report missing templates that would affect kickoff writing, project brief creation, status updates, or check-ins.
+- Capture the Basecamp URL and location of the template folder when available.
+- Do not write or modify project content.
+- Do not assume a template exists if it was not found.
+- If German templates exist, explain how their language and structure should guide later writing.
+
+## Inspection Focus
+
+Look for:
+
+- Folder title, path, and URL
+- Kickoff message template
+- Project brief template
+- Status update template
+- Automatic check-in prompt template
+- Naming conventions and tone
+- Required sections, optional sections, and repeated phrasing
+- Missing or incomplete template types
+
+## Output Contract
+
+```markdown
+## Template Library Report
+
+### Vorlagen Folder
+Found:
+Location:
+Basecamp URL:
+
+### Templates Found
+### Kickoff Template Analysis
+### Project Brief Template Analysis
+### Status/Check-in Template Analysis
+### Language Guidance
+### Missing Templates
+### Questions Before Writing
+```

skills/basecamp-project/references/tasklist-rules.md

@@ -0,0 +1,59 @@
+# Tasklist Rules
+
+## Default Work Structure
+
+Use Basecamp To-dos as the default structure for planned project work. A To-do is the right unit when work has a clear action, owner, timing, and completion definition.
+
+Use Card Table only for reactive or pipeline work, such as incoming requests, intake queues, review stages, sales-style pipelines, support flows, or work that moves through repeatable status columns before it is ready for a committed To-do list.
+
+## Assignment Rules
+
+Every task set needs a named directly responsible individual (DRI). The DRI is accountable for keeping the task list coherent, resolving unclear ownership, and making sure work moves forward.
+
+Use hybrid assignment:
+
+- Near-term tasks need named owners.
+- Dependency-critical tasks need named owners.
+- Client-facing or approval-heavy tasks need named owners.
+- Later uncertain work may use role placeholders, such as `Designer`, `Developer`, `Client reviewer`, or `Legal reviewer`.
+- Each role placeholder needs a staffing-resolution task with a named owner and a date or milestone-relative trigger.
+
+## Due Date Rules
+
+Use hybrid due dates:
+
+- Use fixed dates for near-term work, dependency-critical work, launch-critical work, meetings, reviews, and external commitments.
+- Use milestone-relative timing for later uncertain work, such as `3 business days after content approval` or `1 week before launch`.
+- Convert all milestone-relative timing to fixed Basecamp due dates before creating the final Basecamp To-dos.
+- If timing is uncertain, name the decision point that will convert relative timing into fixed dates.
+
+## Task Output Contract
+
+Each task should include:
+
+- **Title:** Action-oriented, specific, and short.
+- **Owner:** Named person or role placeholder.
+- **Owner type:** `named DRI`, `named owner`, or `role placeholder`.
+- **Timing type:** `fixed date`, `milestone-relative`, or `sequence-only`.
+- **Due or relative timing:** Date, milestone-relative timing, or ordering note.
+- **Description:** Context needed to do the work without rereading the full plan.
+- **Done means:** Observable completion condition.
+- **Dependency:** Upstream task, decision, asset, approval, or `none`.
+- **Confidence:** `high`, `medium`, or `low`, based on clarity of scope, owner, and timing.
+
+## Task Quality Checklist
+
+Before creating To-dos in Basecamp, confirm that:
+
+- To-dos are used for committed planned work.
+- Card Table is reserved for reactive or pipeline work.
+- A named DRI exists for the task list or project area.
+- Near-term and dependency-critical tasks have named owners.
+- Role placeholders are limited to later uncertain work.
+- Every role placeholder has a staffing-resolution task.
+- Fixed dates are used where commitments or dependencies require them.
+- Milestone-relative timing has a clear conversion trigger.
+- All Basecamp-ready tasks have fixed due dates where Basecamp dates are required.
+- Each task states what done means.
+- Dependencies are explicit or marked as none.
+- Low-confidence tasks identify what must be clarified next.

skills/basecamp-project/scripts/markdown_to_trix.py

@@ -1,481 +0,0 @@
-#!/usr/bin/env python3
-"""
-Markdown to Basecamp Trix HTML Converter.
-
-Converts Markdown text to Basecamp-compatible HTML in Trix format.
-Handles Basecamp-specific limitations and provides safety checks.
-"""
-
-import argparse
-import logging
-import re
-import sys
-from typing import Optional
-
-try:
-    import markdown as markdown_lib
-    MARKDOWN_AVAILABLE = True
-except ImportError:
-    MARKDOWN_AVAILABLE = False
-    markdown_lib = None  # type: ignore[assignment-assign]
-
-logging.basicConfig(
-    level=logging.DEBUG,
-    format="%(levelname)s: %(message)s"
-)
-logger = logging.getLogger(__name__)
-
-
-def markdown_to_trix(markdown_text: str) -> str:
-    """
-    Convert Markdown text to Basecamp-compatible HTML (Trix format).
-
-    Args:
-        markdown_text: The Markdown content to convert.
-
-    Returns:
-        HTML string compatible with Basecamp Trix editor.
-
-    Raises:
-        ImportError: If markdown library is not installed.
-    """
-    if not MARKDOWN_AVAILABLE:
-        raise ImportError(
-            "The 'markdown' library is required. Install with: pip install markdown"
-        )
-
-    # Strip potential HTML comments or existing HTML that might cause issues
-    cleaned_text = _preprocess_markdown(markdown_text)
-
-    # Configure markdown with safe extensions
-    md = markdown_lib.Markdown(  # type: ignore[attr-defined]
-        extensions=[
-            "tables",
-            "fenced_code",
-            "codehilite",
-            "nl2br",
-            "sane_lists",
-        ],
-        extension_configs={
-            "codehilite": {"css_class": "highlight"},
-        },
-        output_format="html",
-    )
-
-    # Convert markdown to HTML
-    html = md.convert(cleaned_text)
-
-    # Post-process for Basecamp compatibility
-    html = _post_process_html(html)
-
-    return html
-
-
-def _preprocess_markdown(text: str) -> str:
-    """Preprocess markdown text before conversion."""
-    lines = text.split("\n")
-    processed_lines = []
-
-    for line in lines:
-        # Preserve checkboxes but mark them for post-processing
-        # Basecamp supports checkboxes only in to-dos, not messages
-        if re.match(r"^(\s*)-\s*\[[\sXx]\]\s+", line):
-            # Mark checkbox lines for later handling
-            processed_lines.append(line)
-        else:
-            processed_lines.append(line)
-
-    return "\n".join(processed_lines)
-
-
-def _post_process_html(html: str) -> str:
-    """
-    Post-process HTML for Basecamp Trix compatibility.
-
-    - Removes horizontal rules or converts them to styled divs
-    - Cleans up unnecessary tags
-    - Ensures proper inline formatting
-    """
-    # Remove empty paragraphs
-    html = re.sub(r"<p>\s*</p>", "", html)
-
-    # Convert horizontal rules to Basecamp-friendly separators
-    # Basecamp may not render <hr> correctly, use styled div instead
-    html = re.sub(
-        r"<hr\s*/?>",
-        '<div style="border-bottom: 1px solid #e0e0e0; margin: 16px 0;"></div>',
-        html,
-    )
-
-    # Clean up multiple consecutive breaks
-    html = re.sub(r"(<br\s*/?>){3,}", "<br><br>", html)
-
-    # Ensure links open in new tab (Basecamp best practice)
-    html = re.sub(
-        r'<a href="([^"]+)"',
-        r'<a href="\1" target="_blank" rel="noopener noreferrer"',
-        html,
-    )
-
-    # Wrap code blocks properly for Basecamp
-    html = re.sub(
-        r'<pre><code class="([^"]*)">',
-        r'<pre class="\1"><code>',
-        html,
-    )
-
-    return html
-
-
-def is_basecamp_safe(markdown_text: str) -> list[str]:
-    """
-    Check Markdown for unsupported Basecamp features.
-
-    Args:
-        markdown_text: The Markdown content to check.
-
-    Returns:
-        List of warning messages for unsupported features found.
-    """
-    warnings: list[str] = []
-
-    # Check for tables
-    if re.search(r"^\|.*\|.*$", markdown_text, re.MULTILINE):
-        logger.debug("Found table syntax in markdown")
-        warnings.append(
-            "Tables not supported: convert to structured lists"
-        )
-
-    # Check for checkboxes (only in document context, not todo lists)
-    if re.search(r"^(\s*)-\s*\[[\sXx]\]\s+", markdown_text, re.MULTILINE):
-        logger.debug("Found checkbox syntax in markdown")
-        warnings.append(
-            "Checkboxes not supported in messages: create as todos instead"
-        )
-
-    # Check for horizontal rules
-    if re.search(r"^[-*_]{3,}\s*$", markdown_text, re.MULTILINE):
-        logger.debug("Found horizontal rule syntax")
-        warnings.append(
-            "Horizontal rules may not render correctly"
-        )
-
-    # Check for complex nested structures that might not render
-    if markdown_text.count("    ") > 10:
-        logger.debug("Found deeply nested indentation")
-        warnings.append(
-            "Deep nesting may not render correctly: consider flattening structure"
-        )
-
-    return warnings
-
-
-def convert_table_to_lists(table_md: str) -> str:
-    """
-    Convert a Markdown table to nested lists in Basecamp-friendly format.
-
-    Args:
-        table_md: The Markdown table content (without outer pipes).
-
-    Returns:
-        Nested list representation suitable for Basecamp.
-
-    Example:
-        Input:
-            | Name | Value |
-            |------|-------|
-            | Foo  | Bar   |
-
-        Output:
-            Name:
-              - Name: Foo
-              - Value: Bar
-    """
-    lines = [line.strip() for line in table_md.strip().split("\n") if line.strip()]
-
-    if len(lines) < 2:
-        return table_md
-
-    # Parse header
-    header_match = re.match(r"\|(.+)\|", lines[0])
-    if not header_match:
-        return table_md
-
-    headers = [h.strip() for h in header_match.group(1).split("|")]
-
-    # Skip separator line if present
-    data_lines = lines[1:]
-    if data_lines and re.match(r"^\|[-:\s|]+\|$", data_lines[0]):
-        data_lines = data_lines[1:]
-
-    result_parts: list[str] = []
-
-    for line in data_lines:
-        row_match = re.match(r"\|(.+)\|", line)
-        if not row_match:
-            continue
-
-        values = [v.strip() for v in row_match.group(1).split("|")]
-
-        # Create nested list for each row
-        row_items: list[str] = []
-        for header, value in zip(headers, values):
-            row_items.append(f"  - {header}: {value}")
-
-        if row_items:
-            result_parts.append("\n".join(row_items))
-
-    return "\n\n".join(result_parts)
-
-
-def convert_checkbox_to_text(line: str) -> str:
-    """
-    Convert a checkbox line to plain text.
-
-    Args:
-        line: A markdown line with checkbox syntax.
-
-    Returns:
-        Plain text representation with checkbox state indicated.
-    """
-    # Match: optional_indent - [ ] or - [x] or - [X]
-    match = re.match(r"^(\s*-\s*)\[[\sXx]\]\s+(.*)", line)
-    if match:
-        indent, text = match.groups()
-        checkbox_char = "☐" if " " in match.group(0) else "☑"
-        return f"{indent}{checkbox_char} {text}"
-
-    return line
-
-
-def _cli_check_mode(filename: str) -> int:
-    """
-    Run in check mode: only output warnings without conversion.
-
-    Args:
-        filename: Path to the markdown file.
-
-    Returns:
-        Exit code: 0 if no warnings, 1 if warnings found, 2 on file error.
-    """
-    try:
-        with open(filename, "r", encoding="utf-8") as f:
-            markdown_text = f.read()
-    except FileNotFoundError:
-        print(f"Error: File not found: {filename}", file=sys.stderr)
-        return 2
-    except PermissionError:
-        print(f"Error: Permission denied: {filename}", file=sys.stderr)
-        return 2
-    except Exception as e:
-        print(f"Error reading file: {e}", file=sys.stderr)
-        return 2
-
-    warnings = is_basecamp_safe(markdown_text)
-
-    if warnings:
-        print(f"Warnings for {filename}:")
-        for warning in warnings:
-            print(f"  ⚠️  {warning}")
-        return 1
-    else:
-        print(f"✅ No unsupported features found in {filename}")
-        return 0
-
-
-def _cli_convert_mode(filename: str, output: Optional[str]) -> int:
-    """
-    Run in convert mode: convert markdown to HTML.
-
-    Args:
-        filename: Path to the markdown file.
-        output: Optional path for output file.
-
-    Returns:
-        Exit code: 0 on success, 1 on warnings, 2 on error.
-    """
-    try:
-        with open(filename, "r", encoding="utf-8") as f:
-            markdown_text = f.read()
-    except FileNotFoundError:
-        print(f"Error: File not found: {filename}", file=sys.stderr)
-        return 2
-    except PermissionError:
-        print(f"Error: Permission denied: {filename}", file=sys.stderr)
-        return 2
-    except Exception as e:
-        print(f"Error reading file: {e}", file=sys.stderr)
-        return 2
-
-    # Show warnings before conversion
-    warnings = is_basecamp_safe(markdown_text)
-    if warnings:
-        print(f"Warnings for {filename}:")
-        for warning in warnings:
-            print(f"  ⚠️  {warning}")
-        print()
-
-    # Check for markdown library
-    if not MARKDOWN_AVAILABLE:
-        print(
-            "Error: markdown library not installed.",
-            file=sys.stderr
-        )
-        print(
-            "Install with: pip install markdown",
-            file=sys.stderr
-        )
-        return 2
-
-    try:
-        html_output = markdown_to_trix(markdown_text)
-    except Exception as e:
-        print(f"Error converting markdown: {e}", file=sys.stderr)
-        return 2
-
-    if output:
-        try:
-            with open(output, "w", encoding="utf-8") as f:
-                f.write(html_output)
-            print(f"✅ Converted {filename} → {output}")
-        except Exception as e:
-            print(f"Error writing output: {e}", file=sys.stderr)
-            return 2
-    else:
-        # Write to stdout
-        print(html_output)
-
-    return 1 if warnings else 0
-
-
-def main() -> int:
-    """
-    CLI entry point.
-
-    Returns:
-        Exit code: 0=OK, 1=Warnungen, 2=Fehler.
-    """
-    parser = argparse.ArgumentParser(
-        prog="markdown_to_trix.py",
-        description="Convert Markdown to Basecamp Trix HTML format.",
-    )
-
-    parser.add_argument(
-        "--file",
-        "-f",
-        metavar="INPUT.md",
-        help="Input Markdown file to convert",
-    )
-
-    parser.add_argument(
-        "--output",
-        "-o",
-        metavar="OUTPUT.html",
-        help="Output HTML file (default: stdout)",
-    )
-
-    parser.add_argument(
-        "--check",
-        "-c",
-        metavar="INPUT.md",
-        help="Only check for unsupported features, don't convert",
-    )
-
-    parser.add_argument(
-        "--verbose",
-        "-v",
-        action="store_true",
-        help="Enable verbose (debug) logging",
-    )
-
-    args = parser.parse_args()
-
-    if args.verbose:
-        logging.getLogger().setLevel(logging.DEBUG)
-
-    # Handle mutually exclusive modes
-    if args.check:
-        return _cli_check_mode(args.check)
-
-    if args.file:
-        return _cli_convert_mode(args.file, args.output)
-
-    # No mode specified, show help
-    parser.print_help()
-    return 0
-
-
-if __name__ == "__main__":
-    # Parse arguments first
-    import argparse
-    parser = argparse.ArgumentParser()
-    parser.add_argument("--check", "-c", metavar="INPUT.md")
-    parser.add_argument("--file", "-f", metavar="INPUT.md")
-    parser.add_argument("--output", "-o", metavar="OUTPUT.html")
-    args, _ = parser.parse_known_args()
-
-    if args.check or args.file:
-        # CLI mode with arguments
-        sys.exit(main())
-
-    # Run self-tests when executed without arguments
-    print("Running self-test...")
-
-    test_cases = [
-        {
-            "name": "Basic conversion",
-            "input": "# Hello\n\n**Bold** and *italic* text.",
-            "expected_warnings": 0,
-        },
-        {
-            "name": "Table detection",
-            "input": "# Test\n\n| A | B |\n|---|---|\n| 1 | 2 |",
-            "expected_warnings": 1,
-        },
-        {
-            "name": "Checkbox detection",
-            "input": "# Tasks\n\n- [ ] Task 1\n- [x] Task 2",
-            "expected_warnings": 1,
-        },
-        {
-            "name": "Horizontal rule",
-            "input": "# Test\n\n---\n\nContent",
-            "expected_warnings": 1,
-        },
-        {
-            "name": "Safe markdown",
-            "input": "# Title\n\n- Item 1\n- Item 2\n\n**Bold** and [link](https://example.com)",
-            "expected_warnings": 0,
-        },
-    ]
-
-    all_passed = True
-
-    for test in test_cases:
-        warnings = is_basecamp_safe(test["input"])
-        passed = len(warnings) == test["expected_warnings"]
-        status = "✅ PASS" if passed else "❌ FAIL"
-        print(f"  {status}: {test['name']} (warnings: {len(warnings)})")
-        if not passed:
-            all_passed = False
-            print(f"       Expected: {test['expected_warnings']}, Got: {len(warnings)}")
-            print(f"       Warnings: {warnings}")
-
-    # Test table conversion
-    print("\nTesting table conversion...")
-    table_md = """
-| Name | Role | Email |
-|------|------|-------|
-| Alice | Dev | alice@example.com |
-| Bob | Design | bob@example.com |
-"""
-    converted = convert_table_to_lists(table_md)
-    print(f"  Input:\n{table_md}")
-    print(f"  Output:\n{converted}")
-
-    if all_passed:
-        print("\n✅ All self-tests passed!")
-        sys.exit(0)
-    else:
-        print("\n❌ Some self-tests failed!")
-        sys.exit(1)

skills/basecamp-project/scripts/requirements.txt

@@ -1,2 +0,0 @@
-# Markdown to Trix Converter Dependencies
-markdown>=3.4.0

skills/changelog/SKILL.md

@@ -0,0 +1,572 @@
+---
+name: changelog
+description: Automate changelog generation from commits, PRs, and releases following Keep a Changelog format. Use when setting up release workflows, generating release notes, or standardizing commit conventions.
+---
+
+# Changelog Automation
+
+Patterns and tools for automating changelog generation, release notes, and version management following industry standards.
+
+## When to Use This Skill
+
+- Setting up automated changelog generation
+- Implementing Conventional Commits
+- Creating release note workflows
+- Standardizing commit message formats
+- Generating GitHub/GitLab release notes
+- Managing semantic versioning
+
+## Core Concepts
+
+### 1. Keep a Changelog Format
+
+```markdown
+# Changelog
+
+All notable changes to this project will be documented in this file.
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
+and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+## [Unreleased]
+
+### Added
+
+- New feature X
+
+## [1.2.0] - 2024-01-15
+
+### Added
+
+- User profile avatars
+- Dark mode support
+
+### Changed
+
+- Improved loading performance by 40%
+
+### Deprecated
+
+- Old authentication API (use v2)
+
+### Removed
+
+- Legacy payment gateway
+
+### Fixed
+
+- Login timeout issue (#123)
+
+### Security
+
+- Updated dependencies for CVE-2024-1234
+
+[Unreleased]: https://github.com/user/repo/compare/v1.2.0...HEAD
+[1.2.0]: https://github.com/user/repo/compare/v1.1.0...v1.2.0
+```
+
+### 2. Conventional Commits
+
+```
+<type>[optional scope]: <description>
+
+[optional body]
+
+[optional footer(s)]
+```
+
+| Type       | Description      | Changelog Section  |
+| ---------- | ---------------- | ------------------ |
+| `feat`     | New feature      | Added              |
+| `fix`      | Bug fix          | Fixed              |
+| `docs`     | Documentation    | (usually excluded) |
+| `style`    | Formatting       | (usually excluded) |
+| `refactor` | Code restructure | Changed            |
+| `perf`     | Performance      | Changed            |
+| `test`     | Tests            | (usually excluded) |
+| `chore`    | Maintenance      | (usually excluded) |
+| `ci`       | CI changes       | (usually excluded) |
+| `build`    | Build system     | (usually excluded) |
+| `revert`   | Revert commit    | Removed            |
+
+### 3. Semantic Versioning
+
+```
+MAJOR.MINOR.PATCH
+
+MAJOR: Breaking changes (feat! or BREAKING CHANGE)
+MINOR: New features (feat)
+PATCH: Bug fixes (fix)
+```
+
+## Implementation
+
+### Method 1: Conventional Changelog (Node.js)
+
+```bash
+# Install tools
+npm install -D @commitlint/cli @commitlint/config-conventional
+npm install -D husky
+npm install -D standard-version
+# or
+npm install -D semantic-release
+
+# Setup commitlint
+cat > commitlint.config.js << 'EOF'
+module.exports = {
+  extends: ['@commitlint/config-conventional'],
+  rules: {
+    'type-enum': [
+      2,
+      'always',
+      [
+        'feat',
+        'fix',
+        'docs',
+        'style',
+        'refactor',
+        'perf',
+        'test',
+        'chore',
+        'ci',
+        'build',
+        'revert',
+      ],
+    ],
+    'subject-case': [2, 'never', ['start-case', 'pascal-case', 'upper-case']],
+    'subject-max-length': [2, 'always', 72],
+  },
+};
+EOF
+
+# Setup husky
+npx husky init
+echo "npx --no -- commitlint --edit \$1" > .husky/commit-msg
+```
+
+### Method 2: standard-version Configuration
+
+```javascript
+// .versionrc.js
+module.exports = {
+  types: [
+    { type: "feat", section: "Features" },
+    { type: "fix", section: "Bug Fixes" },
+    { type: "perf", section: "Performance Improvements" },
+    { type: "revert", section: "Reverts" },
+    { type: "docs", section: "Documentation", hidden: true },
+    { type: "style", section: "Styles", hidden: true },
+    { type: "chore", section: "Miscellaneous", hidden: true },
+    { type: "refactor", section: "Code Refactoring", hidden: true },
+    { type: "test", section: "Tests", hidden: true },
+    { type: "build", section: "Build System", hidden: true },
+    { type: "ci", section: "CI/CD", hidden: true },
+  ],
+  commitUrlFormat: "{{host}}/{{owner}}/{{repository}}/commit/{{hash}}",
+  compareUrlFormat:
+    "{{host}}/{{owner}}/{{repository}}/compare/{{previousTag}}...{{currentTag}}",
+  issueUrlFormat: "{{host}}/{{owner}}/{{repository}}/issues/{{id}}",
+  userUrlFormat: "{{host}}/{{user}}",
+  releaseCommitMessageFormat: "chore(release): {{currentTag}}",
+  scripts: {
+    prebump: 'echo "Running prebump"',
+    postbump: 'echo "Running postbump"',
+    prechangelog: 'echo "Running prechangelog"',
+    postchangelog: 'echo "Running postchangelog"',
+  },
+};
+```
+
+```json
+// package.json scripts
+{
+  "scripts": {
+    "release": "standard-version",
+    "release:minor": "standard-version --release-as minor",
+    "release:major": "standard-version --release-as major",
+    "release:patch": "standard-version --release-as patch",
+    "release:dry": "standard-version --dry-run"
+  }
+}
+```
+
+### Method 3: semantic-release (Full Automation)
+
+```javascript
+// release.config.js
+module.exports = {
+  branches: [
+    "main",
+    { name: "beta", prerelease: true },
+    { name: "alpha", prerelease: true },
+  ],
+  plugins: [
+    "@semantic-release/commit-analyzer",
+    "@semantic-release/release-notes-generator",
+    [
+      "@semantic-release/changelog",
+      {
+        changelogFile: "CHANGELOG.md",
+      },
+    ],
+    [
+      "@semantic-release/npm",
+      {
+        npmPublish: true,
+      },
+    ],
+    [
+      "@semantic-release/github",
+      {
+        assets: ["dist/**/*.js", "dist/**/*.css"],
+      },
+    ],
+    [
+      "@semantic-release/git",
+      {
+        assets: ["CHANGELOG.md", "package.json"],
+        message:
+          "chore(release): ${nextRelease.version} [skip ci]\n\n${nextRelease.notes}",
+      },
+    ],
+  ],
+};
+```
+
+### Method 4: GitHub Actions Workflow
+
+```yaml
+# .github/workflows/release.yml
+name: Release
+
+on:
+  push:
+    branches: [main]
+  workflow_dispatch:
+    inputs:
+      release_type:
+        description: "Release type"
+        required: true
+        default: "patch"
+        type: choice
+        options:
+          - patch
+          - minor
+          - major
+
+permissions:
+  contents: write
+  pull-requests: write
+
+jobs:
+  release:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+          token: ${{ secrets.GITHUB_TOKEN }}
+
+      - uses: actions/setup-node@v4
+        with:
+          node-version: "20"
+          cache: "npm"
+
+      - run: npm ci
+
+      - name: Configure Git
+        run: |
+          git config user.name "github-actions[bot]"
+          git config user.email "github-actions[bot]@users.noreply.github.com"
+
+      - name: Run semantic-release
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
+        run: npx semantic-release
+
+  # Alternative: manual release with standard-version
+  manual-release:
+    if: github.event_name == 'workflow_dispatch'
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+
+      - uses: actions/setup-node@v4
+        with:
+          node-version: "20"
+
+      - run: npm ci
+
+      - name: Configure Git
+        run: |
+          git config user.name "github-actions[bot]"
+          git config user.email "github-actions[bot]@users.noreply.github.com"
+
+      - name: Bump version and generate changelog
+        run: npx standard-version --release-as ${{ inputs.release_type }}
+
+      - name: Push changes
+        run: git push --follow-tags origin main
+
+      - name: Create GitHub Release
+        uses: softprops/action-gh-release@v1
+        with:
+          tag_name: ${{ steps.version.outputs.tag }}
+          body_path: RELEASE_NOTES.md
+          generate_release_notes: true
+```
+
+### Method 5: git-cliff (Rust-based, Fast)
+
+```toml
+# cliff.toml
+[changelog]
+header = """
+# Changelog
+
+All notable changes to this project will be documented in this file.
+
+"""
+body = """
+{% if version %}\
+    ## [{{ version | trim_start_matches(pat="v") }}] - {{ timestamp | date(format="%Y-%m-%d") }}
+{% else %}\
+    ## [Unreleased]
+{% endif %}\
+{% for group, commits in commits | group_by(attribute="group") %}
+    ### {{ group | upper_first }}
+    {% for commit in commits %}
+        - {% if commit.scope %}**{{ commit.scope }}:** {% endif %}\
+            {{ commit.message | upper_first }}\
+            {% if commit.github.pr_number %} ([#{{ commit.github.pr_number }}](https://github.com/owner/repo/pull/{{ commit.github.pr_number }})){% endif %}\
+    {% endfor %}
+{% endfor %}
+"""
+footer = """
+{% for release in releases -%}
+    {% if release.version -%}
+        {% if release.previous.version -%}
+            [{{ release.version | trim_start_matches(pat="v") }}]: \
+                https://github.com/owner/repo/compare/{{ release.previous.version }}...{{ release.version }}
+        {% endif -%}
+    {% else -%}
+        [unreleased]: https://github.com/owner/repo/compare/{{ release.previous.version }}...HEAD
+    {% endif -%}
+{% endfor %}
+"""
+trim = true
+
+[git]
+conventional_commits = true
+filter_unconventional = true
+split_commits = false
+commit_parsers = [
+    { message = "^feat", group = "Features" },
+    { message = "^fix", group = "Bug Fixes" },
+    { message = "^doc", group = "Documentation" },
+    { message = "^perf", group = "Performance" },
+    { message = "^refactor", group = "Refactoring" },
+    { message = "^style", group = "Styling" },
+    { message = "^test", group = "Testing" },
+    { message = "^chore\\(release\\)", skip = true },
+    { message = "^chore", group = "Miscellaneous" },
+]
+filter_commits = false
+tag_pattern = "v[0-9]*"
+skip_tags = ""
+ignore_tags = ""
+topo_order = false
+sort_commits = "oldest"
+
+[github]
+owner = "owner"
+repo = "repo"
+```
+
+```bash
+# Generate changelog
+git cliff -o CHANGELOG.md
+
+# Generate for specific range
+git cliff v1.0.0..v2.0.0 -o RELEASE_NOTES.md
+
+# Preview without writing
+git cliff --unreleased --dry-run
+```
+
+### Method 6: Python (commitizen)
+
+```toml
+# pyproject.toml
+[tool.commitizen]
+name = "cz_conventional_commits"
+version = "1.0.0"
+version_files = [
+    "pyproject.toml:version",
+    "src/__init__.py:__version__",
+]
+tag_format = "v$version"
+update_changelog_on_bump = true
+changelog_incremental = true
+changelog_start_rev = "v0.1.0"
+
+[tool.commitizen.customize]
+message_template = "{{change_type}}{% if scope %}({{scope}}){% endif %}: {{message}}"
+schema = "<type>(<scope>): <subject>"
+schema_pattern = "^(feat|fix|docs|style|refactor|perf|test|chore)(\\(\\w+\\))?:\\s.*"
+bump_pattern = "^(feat|fix|perf|refactor)"
+bump_map = {"feat" = "MINOR", "fix" = "PATCH", "perf" = "PATCH", "refactor" = "PATCH"}
+```
+
+```bash
+# Install
+pip install commitizen
+
+# Create commit interactively
+cz commit
+
+# Bump version and update changelog
+cz bump --changelog
+
+# Check commits
+cz check --rev-range HEAD~5..HEAD
+```
+
+## Release Notes Templates
+
+### GitHub Release Template
+
+```markdown
+## What's Changed
+
+### 🚀 Features
+
+{{ range .Features }}
+
+- {{ .Title }} by @{{ .Author }} in #{{ .PR }}
+  {{ end }}
+
+### 🐛 Bug Fixes
+
+{{ range .Fixes }}
+
+- {{ .Title }} by @{{ .Author }} in #{{ .PR }}
+  {{ end }}
+
+### 📚 Documentation
+
+{{ range .Docs }}
+
+- {{ .Title }} by @{{ .Author }} in #{{ .PR }}
+  {{ end }}
+
+### 🔧 Maintenance
+
+{{ range .Chores }}
+
+- {{ .Title }} by @{{ .Author }} in #{{ .PR }}
+  {{ end }}
+
+## New Contributors
+
+{{ range .NewContributors }}
+
+- @{{ .Username }} made their first contribution in #{{ .PR }}
+  {{ end }}
+
+**Full Changelog**: https://github.com/owner/repo/compare/v{{ .Previous }}...v{{ .Current }}
+```
+
+### Internal Release Notes
+
+```markdown
+# Release v2.1.0 - January 15, 2024
+
+## Summary
+
+This release introduces dark mode support and improves checkout performance
+by 40%. It also includes important security updates.
+
+## Highlights
+
+### 🌙 Dark Mode
+
+Users can now switch to dark mode from settings. The preference is
+automatically saved and synced across devices.
+
+### ⚡ Performance
+
+- Checkout flow is 40% faster
+- Reduced bundle size by 15%
+
+## Breaking Changes
+
+None in this release.
+
+## Upgrade Guide
+
+No special steps required. Standard deployment process applies.
+
+## Known Issues
+
+- Dark mode may flicker on initial load (fix scheduled for v2.1.1)
+
+## Dependencies Updated
+
+| Package | From    | To      | Reason                   |
+| ------- | ------- | ------- | ------------------------ |
+| react   | 18.2.0  | 18.3.0  | Performance improvements |
+| lodash  | 4.17.20 | 4.17.21 | Security patch           |
+```
+
+## Commit Message Examples
+
+```bash
+# Feature with scope
+feat(auth): add OAuth2 support for Google login
+
+# Bug fix with issue reference
+fix(checkout): resolve race condition in payment processing
+
+Closes #123
+
+# Breaking change
+feat(api)!: change user endpoint response format
+
+BREAKING CHANGE: The user endpoint now returns `userId` instead of `id`.
+Migration guide: Update all API consumers to use the new field name.
+
+# Multiple paragraphs
+fix(database): handle connection timeouts gracefully
+
+Previously, connection timeouts would cause the entire request to fail
+without retry. This change implements exponential backoff with up to
+3 retries before failing.
+
+The timeout threshold has been increased from 5s to 10s based on p99
+latency analysis.
+
+Fixes #456
+Reviewed-by: @alice
+```
+
+## Best Practices
+
+### Do's
+
+- **Follow Conventional Commits** - Enables automation
+- **Write clear messages** - Future you will thank you
+- **Reference issues** - Link commits to tickets
+- **Use scopes consistently** - Define team conventions
+- **Automate releases** - Reduce manual errors
+
+### Don'ts
+
+- **Don't mix changes** - One logical change per commit
+- **Don't skip validation** - Use commitlint
+- **Don't manual edit** - Generated changelogs only
+- **Don't forget breaking changes** - Mark with `!` or footer
+- **Don't ignore CI** - Validate commits in pipeline