m3tam3re/AGENTS
0
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: basecamp-project skill

Browse Source
This commit is contained in:
m3tm3re
2026-04-24 20:00:33 +02:00
parent 0ad41acb03
commit 6e0e847299
211 changed files with 46029 additions and 2592 deletions
Download Patch File Download Diff File Expand all files Collapse all files

247
skills/basecamp-project/SKILL.md Normal file
View File

@@ -0,0 +1,247 @@
---
name: basecamp-project
description: |
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
---
## Overview
Creates a Basecamp project from a markdown plan document via a human-in-the-loop workflow:
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.
## Prerequisites
- Basecamp CLI configured (`basecamp doctor` passes)
- Plans stored as markdown files in `docs/plans/`
- Basecamp skill available for API calls
## Core Workflow
### Step 1: List Plans
List all markdown files in `docs/plans/`:
```bash
ls -1 docs/plans/*.md
```
Present as numbered list for easy selection.
### Step 2: User Selects Plan
User picks a plan by number or filename. Validate the file exists before proceeding.
### Step 3: Parse Plan
Read the selected file and extract available fields:
| Field | Source | Required |
|-------|--------|----------|
| Project name | First heading (`# Title`) or frontmatter `title:` | Yes |
| Description | Frontmatter `description:` or second paragraph | Yes |
| Start date | Frontmatter `start:`, `starts:`, or natural mention | Yes |
| End date | Frontmatter `end:`, `due:`, `deadline:`, or natural mention | Yes |
| Milestones | Sections with dates (e.g., "## Phase 1: Discovery") | Yes |
| Tasks | Bulleted lists under milestones | Yes |
| Assignees | Task modifiers (`@person`, `--assignee`) or frontmatter `team:` | No |
| Documents | Links (`[ref](url)`) or frontmatter `attachments:` | No |
If frontmatter uses a non-standard structure, parse body content and use natural language cues.
### Step 4: Prompt for Missing Information
Prompt one field at a time, in this order:
1. **Project name** — if not found
2. **Start date** — if not found (use "When should this project begin?")
3. **End date** — if not found (use "When should this project be completed?")
4. **Team members** — if not found:
- First, fetch Basecamp people: `basecamp people list --json`
- Present as picker with names
- Fall back to free text if not found
5. **Assignees** — map tasks to team members (one prompt per unassigned task group)
6. **Milestone dates** — if milestones lack dates, prompt for each
For date fields, accept natural language (`"next Monday"`, `"May 15"`, `"2025-06-01"`).
### Step 5: Generate Draft
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" |

50
skills/brainstorming/SKILL.md
View File

@@ -13,6 +13,7 @@ General-purpose ideation for any domain: business decisions, personal projects,
### 1. Understand Context
Start by understanding the situation:
- What's the situation? What triggered this thinking?
- What's the current state vs desired state?
@@ -21,6 +22,7 @@ Start by understanding the situation:
### 2. Clarify the Outcome
Before exploring solutions, clarify what success looks like:
- What would a good outcome enable?
- What would you be able to do that you can't now?
- Are there constraints on what "good" means?
@@ -28,6 +30,7 @@ Before exploring solutions, clarify what success looks like:
### 3. Explore Constraints
Map the boundaries before generating options:
- **Time**: Deadlines, urgency, available hours
- **Resources**: Budget, people, skills, tools
- **External**: Dependencies, stakeholders, regulations
@@ -55,6 +58,7 @@ Lead with your recommendation but present alternatives fairly.
### 5. Validate Incrementally
Present thinking in 200-300 word sections. After each section, check:
- "Does this capture it correctly?"
- "Anything I'm missing?"
- "Should we go deeper on any aspect?"
@@ -109,6 +113,7 @@ tags: #brainstorm #{{framework_tag}}
```
**Framework tags** (use in `tags:` frontmatter):
- `#pros-cons` - Pros/Cons analysis
- `#swot` - Strategic SWOT assessment
- `#5-whys` - Root cause analysis
@@ -117,6 +122,7 @@ tags: #brainstorm #{{framework_tag}}
- `#constraint-mapping` - Boundary analysis
**Status tags** (use in `status:` frontmatter):
- `draft` - Initial capture
- `final` - Decision made
- `archived` - No longer active
@@ -138,27 +144,27 @@ For a better editing experience, create a template in Obsidian:
## Key Principles
| Principle | Why |
|-----------|-----|
| **One question at a time** | Avoids overwhelming, gets better answers |
| **Multiple choice preferred** | Easier to respond, clarifies options |
| **Domain-agnostic** | Works for any topic, not just technical |
| **YAGNI ruthlessly** | Remove unnecessary scope from all explorations |
| **Recommendation-first** | Always lead with your suggested approach |
| **Flexible** | Go back and clarify when needed |
| Principle | Why |
| ----------------------------- | ---------------------------------------------- |
| **One question at a time** | Avoids overwhelming, gets better answers |
| **Multiple choice preferred** | Easier to respond, clarifies options |
| **Domain-agnostic** | Works for any topic, not just technical |
| **YAGNI ruthlessly** | Remove unnecessary scope from all explorations |
| **Recommendation-first** | Always lead with your suggested approach |
| **Flexible** | Go back and clarify when needed |
## When to Use Frameworks
For structured analysis, consult [references/thinking-frameworks.md](references/thinking-frameworks.md):
| Situation | Framework |
|-----------|-----------|
| Binary decision (A or B, yes or no) | Pros/Cons |
| Strategic assessment | SWOT |
| Finding root cause | 5 Whys |
| Prioritizing many ideas | How-Now-Wow Matrix |
| Comprehensive exploration | Starbursting (6 Questions) |
| Understanding boundaries | Constraint Mapping |
| Situation | Framework |
| ----------------------------------- | -------------------------- |
| Binary decision (A or B, yes or no) | Pros/Cons |
| Strategic assessment | SWOT |
| Finding root cause | 5 Whys |
| Prioritizing many ideas | How-Now-Wow Matrix |
| Comprehensive exploration | Starbursting (6 Questions) |
| Understanding boundaries | Constraint Mapping |
**Only suggest frameworks when they add value.** Many brainstorms work fine with conversational exploration alone.
@@ -167,7 +173,7 @@ For structured analysis, consult [references/thinking-frameworks.md](references/
```
User: "I'm not sure how to approach launching my new course"
AI: "Let me help you think through this. First, what kind of course is it
AI: "Let me help you think through this. First, what kind of course is it
and who's the target audience?"
User: "NixOS course for developers who want to learn Nix"
@@ -192,10 +198,10 @@ c) Flexible, no deadline"
After brainstorming, common next steps:
| Output | Next Skill | Trigger |
|--------|------------|---------|
| Project decision | plan-writing | "Create a project plan for this" |
| Task identified | task-management | "Add this to my tasks" |
| Work project | basecamp | "Set this up in Basecamp" |
| Output | Next Skill | Trigger |
| ---------------- | ---------------- | -------------------------------- |
| Project decision | plan-writing | "Create a project plan for this" |
| Task identified | task-management | "Add this to my tasks" |
| Work project | basecamp-project | "Set this up in Basecamp" |
All handoffs can reference the Obsidian brainstorm note via WikiLinks or file paths.

10
skills/grill-me/SKILL.md Normal file
View File

@@ -0,0 +1,10 @@
---
name: grill-me
description: Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
---
Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
Ask the questions one at a time.
If a question can be answered by exploring the codebase, explore the codebase instead.

159
skills/plan-writing/SKILL.md Normal file
View File

@@ -0,0 +1,159 @@
---
name: plan-writing
description: Use when you have a spec or requirements for a multi-step task, before touching code
---
# Writing Plans
## Overview
Write comprehensive implementation plans assuming the engineer has zero context for our codebase and questionable taste. Document everything they need to know: which files to touch for each task, code, testing, docs they might need to check, how to test it. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD. Frequent commits.
Assume they are a skilled developer, but know almost nothing about our toolset or problem domain. Assume they don't know good test design very well.
**Announce at start:** "I'm using the plan-writing skill to create the implementation plan."
**Context:** This should be run in a dedicated worktree (created by brainstorming skill).
**Save plans to:** `docs/plans/YYYY-MM-DD-<feature-name>.md`
- (User preferences for plan location override this default)
## Scope Check
If the spec covers multiple independent subsystems, it should have been broken into sub-project specs during brainstorming. If it wasn't, suggest breaking this into separate plans — one per subsystem. Each plan should produce working, testable software on its own.
## File Structure
Before defining tasks, map out which files will be created or modified and what each one is responsible for. This is where decomposition decisions get locked in.
- Design units with clear boundaries and well-defined interfaces. Each file should have one clear responsibility.
- You reason best about code you can hold in context at once, and your edits are more reliable when files are focused. Prefer smaller, focused files over large ones that do too much.
- Files that change together should live together. Split by responsibility, not by technical layer.
- In existing codebases, follow established patterns. If the codebase uses large files, don't unilaterally restructure - but if a file you're modifying has grown unwieldy, including a split in the plan is reasonable.
This structure informs the task decomposition. Each task should produce self-contained changes that make sense independently.
## Bite-Sized Task Granularity
**Each step is one action (2-5 minutes):**
- "Write the failing test" - step
- "Run it to make sure it fails" - step
- "Implement the minimal code to make the test pass" - step
- "Run the tests and make sure they pass" - step
- "Commit" - step
## Plan Document Header
**Every plan MUST start with this header:**
```markdown
# [Feature Name] Implementation Plan
> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
**Goal:** [One sentence describing what this builds]
**Architecture:** [2-3 sentences about approach]
**Tech Stack:** [Key technologies/libraries]
---
```
## Task Structure
````markdown
### Task N: [Component Name]
**Files:**
- Create: `exact/path/to/file.py`
- Modify: `exact/path/to/existing.py:123-145`
- Test: `tests/exact/path/to/test.py`
- [ ] **Step 1: Write the failing test**
```python
def test_specific_behavior():
result = function(input)
assert result == expected
```
- [ ] **Step 2: Run test to verify it fails**
Run: `pytest tests/path/test.py::test_name -v`
Expected: FAIL with "function not defined"
- [ ] **Step 3: Write minimal implementation**
```python
def function(input):
return expected
```
- [ ] **Step 4: Run test to verify it passes**
Run: `pytest tests/path/test.py::test_name -v`
Expected: PASS
- [ ] **Step 5: Commit**
```bash
git add tests/path/test.py src/path/file.py
git commit -m "feat: add specific feature"
```
````
## No Placeholders
Every step must contain the actual content an engineer needs. These are **plan failures** — never write them:
- "TBD", "TODO", "implement later", "fill in details"
- "Add appropriate error handling" / "add validation" / "handle edge cases"
- "Write tests for the above" (without actual test code)
- "Similar to Task N" (repeat the code — the engineer may be reading tasks out of order)
- Steps that describe what to do without showing how (code blocks required for code steps)
- References to types, functions, or methods not defined in any task
## Remember
- Exact file paths always
- Complete code in every step — if a step changes code, show the code
- Exact commands with expected output
- DRY, YAGNI, TDD, frequent commits
## Self-Review
After writing the complete plan, look at the spec with fresh eyes and check the plan against it. This is a checklist you run yourself — not a subagent dispatch.
**1. Spec coverage:** Skim each section/requirement in the spec. Can you point to a task that implements it? List any gaps.
**2. Placeholder scan:** Search your plan for red flags — any of the patterns from the "No Placeholders" section above. Fix them.
**3. Type consistency:** Do the types, method signatures, and property names you used in later tasks match what you defined in earlier tasks? A function called `clearLayers()` in Task 3 but `clearFullLayers()` in Task 7 is a bug.
If you find issues, fix them inline. No need to re-review — just fix and move on. If you find a spec requirement with no task, add the task.
## Execution Handoff
After saving the plan, offer execution choice:
**"Plan complete and saved to `docs/plans/<filename>.md`. Two execution options:**
**1. Subagent-Driven (recommended)** - I dispatch a fresh subagent per task, review between tasks, fast iteration
**2. Inline Execution** - Execute tasks in this session using executing-plans, batch execution with checkpoints
**Which approach?"**
**If Subagent-Driven chosen:**
- **REQUIRED SUB-SKILL:** Use superpowers:subagent-driven-development
- Fresh subagent per task + two-stage review
**If Inline Execution chosen:**
- **REQUIRED SUB-SKILL:** Use superpowers:executing-plans
- Batch execution with checkpoints for review