opencastle 0.32.4 → 0.32.5
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/cli/bootstrap.js +1 -1
- package/dist/cli/bootstrap.js.map +1 -1
- package/dist/cli/bootstrap.test.js +16 -0
- package/dist/cli/bootstrap.test.js.map +1 -1
- package/dist/cli/init.test.js +38 -0
- package/dist/cli/init.test.js.map +1 -1
- package/dist/cli/stack-config-update.test.js +18 -0
- package/dist/cli/stack-config-update.test.js.map +1 -1
- package/dist/cli/stack-config.d.ts.map +1 -1
- package/dist/cli/stack-config.js +1 -0
- package/dist/cli/stack-config.js.map +1 -1
- package/dist/cli/types.d.ts +1 -1
- package/dist/cli/types.d.ts.map +1 -1
- package/dist/orchestrator/plugins/index.d.ts.map +1 -1
- package/dist/orchestrator/plugins/index.js +4 -0
- package/dist/orchestrator/plugins/index.js.map +1 -1
- package/dist/orchestrator/plugins/notion/config.d.ts +3 -0
- package/dist/orchestrator/plugins/notion/config.d.ts.map +1 -0
- package/dist/orchestrator/plugins/notion/config.js +46 -0
- package/dist/orchestrator/plugins/notion/config.js.map +1 -0
- package/dist/orchestrator/plugins/trello/config.d.ts +3 -0
- package/dist/orchestrator/plugins/trello/config.d.ts.map +1 -0
- package/dist/orchestrator/plugins/trello/config.js +43 -0
- package/dist/orchestrator/plugins/trello/config.js.map +1 -0
- package/dist/orchestrator/plugins/types.d.ts +1 -1
- package/dist/orchestrator/plugins/types.d.ts.map +1 -1
- package/package.json +1 -1
- package/src/cli/bootstrap.test.ts +21 -0
- package/src/cli/bootstrap.ts +1 -1
- package/src/cli/init.test.ts +46 -0
- package/src/cli/stack-config-update.test.ts +20 -0
- package/src/cli/stack-config.ts +1 -0
- package/src/cli/types.ts +1 -1
- package/src/dashboard/node_modules/.vite/deps/_metadata.json +6 -6
- package/src/orchestrator/customizations/agents/skill-matrix.json +8 -4
- package/src/orchestrator/customizations/agents/skill-matrix.md +20 -0
- package/src/orchestrator/plugins/index.ts +4 -0
- package/src/orchestrator/plugins/notion/SKILL.md +205 -0
- package/src/orchestrator/plugins/notion/config.ts +47 -0
- package/src/orchestrator/plugins/trello/SKILL.md +151 -0
- package/src/orchestrator/plugins/trello/config.ts +44 -0
- package/src/orchestrator/plugins/types.ts +1 -1
|
@@ -0,0 +1,205 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: notion-knowledge-management
|
|
3
|
+
description: "Notion workspace patterns for knowledge capture, research documentation, architectural decisions, and spec management. Use when capturing research findings, writing specs, documenting decisions, or managing a team knowledge base."
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
<!-- ⚠️ This file is managed by OpenCastle. Edits will be overwritten on update. Customize in the .opencastle/ directory instead. -->
|
|
7
|
+
|
|
8
|
+
# Knowledge Management with Notion
|
|
9
|
+
|
|
10
|
+
Conventions for working with the team's Notion workspace via the official Notion MCP server. Covers page and database operations, research capture, decision documentation, and permission-aware workflows.
|
|
11
|
+
|
|
12
|
+
## MCP Server
|
|
13
|
+
|
|
14
|
+
| Field | Value |
|
|
15
|
+
|-------|-------|
|
|
16
|
+
| **Endpoint** | `https://mcp.notion.com/mcp` (HTTP, remote) |
|
|
17
|
+
| **Auth** | OAuth — users authenticate via Notion account when the MCP connection is established |
|
|
18
|
+
| **Type** | HTTP MCP (no local process to spawn) |
|
|
19
|
+
|
|
20
|
+
### Authentication
|
|
21
|
+
|
|
22
|
+
The Notion MCP server uses OAuth. When the MCP connection is first opened in your IDE, you will be prompted to authorise access to your Notion workspace. No API key or token is required in `.env`.
|
|
23
|
+
|
|
24
|
+
> **Scope:** The integration is granted access only to pages and databases explicitly shared with it. Before using MCP tools, ensure the relevant pages/databases are shared with the OpenCastle integration in Notion.
|
|
25
|
+
|
|
26
|
+
## Available MCP Tools
|
|
27
|
+
|
|
28
|
+
| Tool | Description |
|
|
29
|
+
|------|-------------|
|
|
30
|
+
| `search` | Search pages and databases across the workspace by keyword |
|
|
31
|
+
| `create_page` | Create a new page (standalone or inside a parent page/database) |
|
|
32
|
+
| `update_page` | Update page properties or archive a page |
|
|
33
|
+
| `append_block_children` | Append content blocks (paragraphs, headings, bullets, code) to a page |
|
|
34
|
+
| `query_database` | Query a Notion database with filters and sorts |
|
|
35
|
+
|
|
36
|
+
## Working with Pages and Databases
|
|
37
|
+
|
|
38
|
+
### Page Hierarchy Hygiene
|
|
39
|
+
|
|
40
|
+
Keep the workspace navigable by placing new pages in the right location:
|
|
41
|
+
|
|
42
|
+
```
|
|
43
|
+
Workspace root
|
|
44
|
+
├── Engineering/
|
|
45
|
+
│ ├── Architecture Decisions/ ← ADRs go here
|
|
46
|
+
│ ├── Specs/ ← Feature specs go here
|
|
47
|
+
│ └── Research/ ← Research notes go here
|
|
48
|
+
├── Team/
|
|
49
|
+
│ ├── Meeting Notes/ ← Meeting intelligence
|
|
50
|
+
│ └── Decisions Log/ ← Key team decisions
|
|
51
|
+
└── Project: <name>/ ← Per-project space
|
|
52
|
+
├── Roadmap
|
|
53
|
+
├── Known Issues
|
|
54
|
+
└── Release Notes/
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
- Always use `search` first to check if a page already exists before creating a new one.
|
|
58
|
+
- Create pages as children of the appropriate parent — never at the workspace root unless explicitly requested.
|
|
59
|
+
- Use databases (not flat pages) for collections that need filtering, sorting, or status tracking (e.g., ADRs, specs).
|
|
60
|
+
|
|
61
|
+
### Page Creation Pattern
|
|
62
|
+
|
|
63
|
+
When creating a page:
|
|
64
|
+
|
|
65
|
+
1. `search` for an existing page with a similar title to avoid duplicates
|
|
66
|
+
2. `create_page` with `parent` set to the correct parent page or database
|
|
67
|
+
3. `append_block_children` to add structured content
|
|
68
|
+
|
|
69
|
+
```json
|
|
70
|
+
// Example: Create a spec page
|
|
71
|
+
{
|
|
72
|
+
"parent": { "page_id": "<Engineering/Specs parent ID>" },
|
|
73
|
+
"properties": {
|
|
74
|
+
"title": [{ "type": "text", "text": { "content": "[Spec] Price Range Filter" } }]
|
|
75
|
+
}
|
|
76
|
+
}
|
|
77
|
+
```
|
|
78
|
+
|
|
79
|
+
## Capturing Research and Decisions
|
|
80
|
+
|
|
81
|
+
### Research Note Structure
|
|
82
|
+
|
|
83
|
+
Use this outline when capturing research findings:
|
|
84
|
+
|
|
85
|
+
```
|
|
86
|
+
# [Research] <Topic>
|
|
87
|
+
|
|
88
|
+
## Summary
|
|
89
|
+
One-paragraph overview of findings.
|
|
90
|
+
|
|
91
|
+
## Sources
|
|
92
|
+
- <URL or reference> — <why it is relevant>
|
|
93
|
+
|
|
94
|
+
## Key Findings
|
|
95
|
+
- Finding 1
|
|
96
|
+
- Finding 2
|
|
97
|
+
|
|
98
|
+
## Implications
|
|
99
|
+
How these findings affect the current task or architecture.
|
|
100
|
+
|
|
101
|
+
## Open Questions
|
|
102
|
+
- Question 1
|
|
103
|
+
```
|
|
104
|
+
|
|
105
|
+
### Architectural Decision Record (ADR) Structure
|
|
106
|
+
|
|
107
|
+
```
|
|
108
|
+
# ADR-NNN: <Short title>
|
|
109
|
+
|
|
110
|
+
**Status:** Proposed | Accepted | Deprecated | Superseded
|
|
111
|
+
**Date:** YYYY-MM-DD
|
|
112
|
+
|
|
113
|
+
## Context
|
|
114
|
+
What is the problem or decision to be made?
|
|
115
|
+
|
|
116
|
+
## Decision
|
|
117
|
+
What was decided?
|
|
118
|
+
|
|
119
|
+
## Consequences
|
|
120
|
+
What tradeoffs or follow-on work does this create?
|
|
121
|
+
|
|
122
|
+
## Alternatives Considered
|
|
123
|
+
- Option A — why rejected
|
|
124
|
+
- Option B — why rejected
|
|
125
|
+
```
|
|
126
|
+
|
|
127
|
+
### Spec-to-Implementation Link
|
|
128
|
+
|
|
129
|
+
When a spec page drives implementation, add an **Implementation** section at the bottom:
|
|
130
|
+
|
|
131
|
+
```
|
|
132
|
+
## Implementation
|
|
133
|
+
- **Branch:** `feat/price-range-filter`
|
|
134
|
+
- **PR:** <link>
|
|
135
|
+
- **Tracker:** <Linear/Jira/Trello card link>
|
|
136
|
+
- **Status:** In Progress / Done
|
|
137
|
+
```
|
|
138
|
+
|
|
139
|
+
This closes the loop between the knowledge base and the task tracker.
|
|
140
|
+
|
|
141
|
+
## Meeting Intelligence
|
|
142
|
+
|
|
143
|
+
When capturing meeting notes, use the following structure:
|
|
144
|
+
|
|
145
|
+
```
|
|
146
|
+
# Meeting: <Title> — YYYY-MM-DD
|
|
147
|
+
|
|
148
|
+
**Attendees:** Name1, Name2
|
|
149
|
+
**Type:** Planning / Review / Retrospective / Decision
|
|
150
|
+
|
|
151
|
+
## Summary
|
|
152
|
+
|
|
153
|
+
## Decisions Made
|
|
154
|
+
- Decision 1 (owner: Name)
|
|
155
|
+
|
|
156
|
+
## Action Items
|
|
157
|
+
- [ ] Action item (owner: Name, due: YYYY-MM-DD)
|
|
158
|
+
|
|
159
|
+
## Context / Discussion Notes
|
|
160
|
+
```
|
|
161
|
+
|
|
162
|
+
After the meeting, add action items to the task tracker.
|
|
163
|
+
|
|
164
|
+
## Permission-Aware Workflows
|
|
165
|
+
|
|
166
|
+
Notion access is page-scoped. Follow these rules to avoid permission errors:
|
|
167
|
+
|
|
168
|
+
1. **Before writing** — run `search` to verify you can see the target page. If it does not appear, the integration has not been granted access.
|
|
169
|
+
2. **Sharing** — ask the user to share the relevant page or database with the OpenCastle integration before running MCP tools against it.
|
|
170
|
+
3. **Databases vs pages** — use `query_database` only on pages that are databases. Use `append_block_children` to add content to regular pages.
|
|
171
|
+
4. **Archived pages** — `search` does not return archived pages. If a page is missing, it may have been archived. Ask the user to restore it.
|
|
172
|
+
|
|
173
|
+
## Database Query Patterns
|
|
174
|
+
|
|
175
|
+
### Filter by Status
|
|
176
|
+
|
|
177
|
+
```json
|
|
178
|
+
{
|
|
179
|
+
"filter": {
|
|
180
|
+
"property": "Status",
|
|
181
|
+
"select": { "equals": "In Progress" }
|
|
182
|
+
}
|
|
183
|
+
}
|
|
184
|
+
```
|
|
185
|
+
|
|
186
|
+
### Sort by Last Edited
|
|
187
|
+
|
|
188
|
+
```json
|
|
189
|
+
{
|
|
190
|
+
"sorts": [
|
|
191
|
+
{ "timestamp": "last_edited_time", "direction": "descending" }
|
|
192
|
+
]
|
|
193
|
+
}
|
|
194
|
+
```
|
|
195
|
+
|
|
196
|
+
## Agent Usage Guidelines
|
|
197
|
+
|
|
198
|
+
| Agent | Primary Use |
|
|
199
|
+
|-------|-------------|
|
|
200
|
+
| **Team Lead** | Create spec pages, capture decisions, link tracker issues to specs |
|
|
201
|
+
| **Researcher** | Capture research notes, query databases for prior art, document findings |
|
|
202
|
+
| **Documentation Writer** | Write and update documentation pages, maintain page hierarchy |
|
|
203
|
+
| **Architect** | Write ADRs, create technical specs, link specs to implementation PRs |
|
|
204
|
+
|
|
205
|
+
**Never** delete pages via MCP — use `update_page` with `archived: true` if a page needs to be removed, and confirm with the user first.
|
|
@@ -0,0 +1,47 @@
|
|
|
1
|
+
import type { PluginConfig } from '../types.js';
|
|
2
|
+
|
|
3
|
+
export const config: PluginConfig = {
|
|
4
|
+
id: 'notion',
|
|
5
|
+
name: 'Notion',
|
|
6
|
+
category: 'team',
|
|
7
|
+
subCategory: 'knowledge-management',
|
|
8
|
+
label: 'Notion',
|
|
9
|
+
hint: 'Workspace knowledge base and documentation hub',
|
|
10
|
+
skillName: 'notion-knowledge-management',
|
|
11
|
+
mcpServerKey: 'Notion',
|
|
12
|
+
mcpConfig: {
|
|
13
|
+
type: 'http',
|
|
14
|
+
url: 'https://mcp.notion.com/mcp',
|
|
15
|
+
},
|
|
16
|
+
authType: 'oauth',
|
|
17
|
+
envVars: [],
|
|
18
|
+
agentToolMap: {
|
|
19
|
+
'team-lead': [
|
|
20
|
+
'Notion/search',
|
|
21
|
+
'Notion/create_page',
|
|
22
|
+
'Notion/update_page',
|
|
23
|
+
'Notion/query_database',
|
|
24
|
+
'Notion/append_block_children',
|
|
25
|
+
],
|
|
26
|
+
'researcher': [
|
|
27
|
+
'Notion/search',
|
|
28
|
+
'Notion/create_page',
|
|
29
|
+
'Notion/append_block_children',
|
|
30
|
+
'Notion/query_database',
|
|
31
|
+
],
|
|
32
|
+
'documentation-writer': [
|
|
33
|
+
'Notion/search',
|
|
34
|
+
'Notion/create_page',
|
|
35
|
+
'Notion/update_page',
|
|
36
|
+
'Notion/append_block_children',
|
|
37
|
+
],
|
|
38
|
+
'architect': [
|
|
39
|
+
'Notion/search',
|
|
40
|
+
'Notion/create_page',
|
|
41
|
+
'Notion/update_page',
|
|
42
|
+
'Notion/query_database',
|
|
43
|
+
],
|
|
44
|
+
},
|
|
45
|
+
docsUrl: 'https://www.opencastle.dev/docs/plugins#notion',
|
|
46
|
+
officialDocs: 'https://developers.notion.com/docs/mcp',
|
|
47
|
+
};
|
|
@@ -0,0 +1,151 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: trello-task-management
|
|
3
|
+
description: "Trello board conventions for tracking feature work — board/list/card workflow, checklist-driven task breakdown, due dates, and when to use comments vs checklist items. Use when decomposing features into cards or resuming interrupted sessions."
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
<!-- ⚠️ This file is managed by OpenCastle. Edits will be overwritten on update. Customize in the .opencastle/ directory instead. -->
|
|
7
|
+
|
|
8
|
+
# Task Management with Trello
|
|
9
|
+
|
|
10
|
+
Conventions for tracking feature work on Trello boards via MCP tools. For project-specific board IDs and list IDs, see [tracker-config.md](../../.opencastle/project/tracker-config.md).
|
|
11
|
+
|
|
12
|
+
## MCP Server
|
|
13
|
+
|
|
14
|
+
| Field | Value |
|
|
15
|
+
|-------|-------|
|
|
16
|
+
| **Package** | [`@delorenj/mcp-server-trello`](https://www.npmjs.com/package/@delorenj/mcp-server-trello) |
|
|
17
|
+
| **Type** | stdio (spawned via `npx -y @delorenj/mcp-server-trello`) |
|
|
18
|
+
| **Auth** | API key + token via `TRELLO_API_KEY` and `TRELLO_TOKEN` env vars |
|
|
19
|
+
|
|
20
|
+
### Authentication
|
|
21
|
+
|
|
22
|
+
1. Get your API key at [trello.com/app-key](https://trello.com/app-key) → **API Key**
|
|
23
|
+
2. On the same page, click **"Generate a Token"** to get your token
|
|
24
|
+
3. Add both to your `.env` file:
|
|
25
|
+
|
|
26
|
+
```
|
|
27
|
+
TRELLO_API_KEY=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
|
|
28
|
+
TRELLO_TOKEN=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
|
|
29
|
+
```
|
|
30
|
+
|
|
31
|
+
## Available MCP Tools
|
|
32
|
+
|
|
33
|
+
| Tool | Description |
|
|
34
|
+
|------|-------------|
|
|
35
|
+
| `get_boards` | List all boards accessible to the authenticated user |
|
|
36
|
+
| `get_lists` | Get all lists on a board (by board ID) |
|
|
37
|
+
| `get_cards_by_list_id` | Get all cards in a specific list |
|
|
38
|
+
| `get_card_details` | Get full details of a single card |
|
|
39
|
+
| `create_card` | Create a new card in a list |
|
|
40
|
+
| `update_card` | Update card fields (name, description, due date, list) |
|
|
41
|
+
| `add_checklist_to_card` | Add a checklist with items to a card |
|
|
42
|
+
| `add_comment_to_card` | Post a comment on a card |
|
|
43
|
+
|
|
44
|
+
## Discovered Issues (Bug Tickets)
|
|
45
|
+
|
|
46
|
+
When an agent encounters a pre-existing bug or issue unrelated to the current task, it must be tracked:
|
|
47
|
+
|
|
48
|
+
1. **Check** existing cards on the board to see if it is already tracked
|
|
49
|
+
2. **If tracked** — skip it, continue with current work
|
|
50
|
+
3. **If NOT tracked:**
|
|
51
|
+
- **Unfixable limitation** — add to known issues with severity, evidence, and root cause
|
|
52
|
+
- **Fixable bug** — create a Trello card:
|
|
53
|
+
- **Name:** `[Bug] Short description of the symptom`
|
|
54
|
+
- **List:** `Backlog` (or the equivalent list in your project)
|
|
55
|
+
- **Description:** Include symptoms, reproduction steps, affected files, and any error messages
|
|
56
|
+
- **Due date:** Set only if it is blocking current work
|
|
57
|
+
|
|
58
|
+
## Card Naming
|
|
59
|
+
|
|
60
|
+
Use `[Area] Short description` format:
|
|
61
|
+
|
|
62
|
+
```
|
|
63
|
+
[Schema] Add priceRange field to place type
|
|
64
|
+
[DB] Add price_range column and migration
|
|
65
|
+
[UI] Build PriceRangeFilter component
|
|
66
|
+
[API] Add price filter endpoint
|
|
67
|
+
[Test] Unit tests for price filter
|
|
68
|
+
[Docs] Update data model documentation
|
|
69
|
+
```
|
|
70
|
+
|
|
71
|
+
**Area prefixes:** `[Schema]`, `[DB]`, `[Query]`, `[UI]`, `[Page]`, `[API]`, `[Auth]`, `[Test]`, `[Docs]`, `[Deploy]`, `[Data]`, `[Perf]`, `[Security]`, `[Bug]`
|
|
72
|
+
|
|
73
|
+
## Board and List Workflow
|
|
74
|
+
|
|
75
|
+
### Typical List Structure
|
|
76
|
+
|
|
77
|
+
```
|
|
78
|
+
Backlog → To Do → In Progress → In Review → Done
|
|
79
|
+
```
|
|
80
|
+
|
|
81
|
+
- **Backlog** — Captured but not yet planned
|
|
82
|
+
- **To Do** — Planned and ready to start
|
|
83
|
+
- **In Progress** — Actively being worked on
|
|
84
|
+
- **In Review** — PR open, awaiting review or merge
|
|
85
|
+
- **Done** — Completed and verified
|
|
86
|
+
|
|
87
|
+
### Agent-Driven Card Transitions (via MCP)
|
|
88
|
+
|
|
89
|
+
| From | To | When |
|
|
90
|
+
|------|----|------|
|
|
91
|
+
| Backlog / To Do | In Progress | Agent starts working on the card |
|
|
92
|
+
| In Progress | Done | Non-PR task is verified (docs, config) |
|
|
93
|
+
| Any | Backlog | Task is deferred |
|
|
94
|
+
|
|
95
|
+
## Checklist-Driven Task Breakdown
|
|
96
|
+
|
|
97
|
+
Use checklists for **subtask decomposition within a single card**. This keeps related work together without cluttering the board with micro-cards.
|
|
98
|
+
|
|
99
|
+
### When to Use a Checklist vs a Separate Card
|
|
100
|
+
|
|
101
|
+
| Use a **checklist item** when… | Use a **separate card** when… |
|
|
102
|
+
|-------------------------------|------------------------------|
|
|
103
|
+
| Steps are sequential and tightly coupled | Work can be assigned independently |
|
|
104
|
+
| Total effort fits in one session | Each step spans multiple sessions |
|
|
105
|
+
| Steps share the same assignee | Steps need different labels/due dates |
|
|
106
|
+
| Internal implementation details | Distinct deliverables that need review |
|
|
107
|
+
|
|
108
|
+
### Checklist Pattern for Feature Decomposition
|
|
109
|
+
|
|
110
|
+
```
|
|
111
|
+
Card: [Feature] Add price range filter
|
|
112
|
+
Checklist: Implementation Steps
|
|
113
|
+
☐ Add priceRange field to schema
|
|
114
|
+
☐ Create DB migration
|
|
115
|
+
☐ Update GROQ/API query
|
|
116
|
+
☐ Build UI component
|
|
117
|
+
☐ Wire into page
|
|
118
|
+
☐ Write unit tests
|
|
119
|
+
☐ Update documentation
|
|
120
|
+
```
|
|
121
|
+
|
|
122
|
+
## Due and Start Dates
|
|
123
|
+
|
|
124
|
+
Trello cards support both a **start date** and a **due date**.
|
|
125
|
+
|
|
126
|
+
- **Due date** — The deadline for the card to move to Done. Set for tasks on the critical path.
|
|
127
|
+
- **Start date** — When work is expected to begin. Useful for pipeline planning.
|
|
128
|
+
- **Due time** — Be explicit with time only for time-sensitive deliverables (e.g., scheduled releases).
|
|
129
|
+
- **Format:** Trello API uses ISO 8601: `2026-03-20T14:00:00.000Z`
|
|
130
|
+
|
|
131
|
+
## Comments vs Checklist Items
|
|
132
|
+
|
|
133
|
+
| Use **comments** for… | Use **checklist items** for… |
|
|
134
|
+
|-----------------------|------------------------------|
|
|
135
|
+
| Progress updates visible to the team | Actionable steps with completion state |
|
|
136
|
+
| Blocking issues or decisions | Pre-defined subtask decomposition |
|
|
137
|
+
| Links to PRs, builds, external docs | Typed acceptance criteria |
|
|
138
|
+
| Questions or async approvals | Implementation sub-steps |
|
|
139
|
+
| Post-implementation notes | QA verification steps |
|
|
140
|
+
|
|
141
|
+
**Rule of thumb:** If it needs to be *checked off*, it's a checklist item. If it needs to be *read*, it's a comment.
|
|
142
|
+
|
|
143
|
+
## Session Continuity
|
|
144
|
+
|
|
145
|
+
At the start of each work session:
|
|
146
|
+
|
|
147
|
+
1. `get_boards` — confirm the right board is active
|
|
148
|
+
2. `get_lists` — identify current list structure
|
|
149
|
+
3. `get_cards_by_list_id` for **In Progress** — find cards already in flight
|
|
150
|
+
4. Resume work on the relevant card, updating the checklist as steps complete
|
|
151
|
+
5. Move the card to the next list when the current phase is done
|
|
@@ -0,0 +1,44 @@
|
|
|
1
|
+
import type { PluginConfig } from '../types.js';
|
|
2
|
+
|
|
3
|
+
export const config: PluginConfig = {
|
|
4
|
+
id: 'trello',
|
|
5
|
+
name: 'Trello',
|
|
6
|
+
category: 'team',
|
|
7
|
+
subCategory: 'task-management',
|
|
8
|
+
label: 'Trello',
|
|
9
|
+
hint: 'Visual board task management via MCP',
|
|
10
|
+
skillName: 'trello-task-management',
|
|
11
|
+
mcpServerKey: 'Trello',
|
|
12
|
+
mcpConfig: {
|
|
13
|
+
type: 'stdio',
|
|
14
|
+
command: 'npx',
|
|
15
|
+
args: ['-y', '@delorenj/mcp-server-trello'],
|
|
16
|
+
envFile: '${workspaceFolder}/.env',
|
|
17
|
+
},
|
|
18
|
+
authType: 'env-token',
|
|
19
|
+
envVars: [
|
|
20
|
+
{
|
|
21
|
+
name: 'TRELLO_API_KEY',
|
|
22
|
+
hint: 'Create at trello.com/app-key -> API Key',
|
|
23
|
+
},
|
|
24
|
+
{
|
|
25
|
+
name: 'TRELLO_TOKEN',
|
|
26
|
+
hint: 'Generate at trello.com/app-key -> Token (click "Generate a Token")',
|
|
27
|
+
},
|
|
28
|
+
],
|
|
29
|
+
agentToolMap: {
|
|
30
|
+
'team-lead': [
|
|
31
|
+
'Trello/get_boards',
|
|
32
|
+
'Trello/get_lists',
|
|
33
|
+
'Trello/get_cards_by_list_id',
|
|
34
|
+
'Trello/get_card_details',
|
|
35
|
+
'Trello/create_card',
|
|
36
|
+
'Trello/update_card',
|
|
37
|
+
'Trello/add_checklist_to_card',
|
|
38
|
+
'Trello/add_comment_to_card',
|
|
39
|
+
],
|
|
40
|
+
},
|
|
41
|
+
docsUrl: 'https://www.opencastle.dev/docs/plugins#trello',
|
|
42
|
+
officialDocs: 'https://developer.atlassian.com/cloud/trello/',
|
|
43
|
+
mcpPackage: '@delorenj/mcp-server-trello',
|
|
44
|
+
};
|
|
@@ -13,7 +13,7 @@ export interface PluginConfig {
|
|
|
13
13
|
category: 'tech' | 'team';
|
|
14
14
|
|
|
15
15
|
/** Sub-category for grouping */
|
|
16
|
-
subCategory: 'cms' | 'database' | 'deployment' | 'framework' | 'codebase-tool' | 'task-management' | 'notifications' | 'testing' | 'e2e-testing' | 'design' | 'email';
|
|
16
|
+
subCategory: 'cms' | 'database' | 'deployment' | 'framework' | 'codebase-tool' | 'task-management' | 'knowledge-management' | 'notifications' | 'testing' | 'e2e-testing' | 'design' | 'email';
|
|
17
17
|
|
|
18
18
|
/** Label shown in the `npx opencastle init` multiselect */
|
|
19
19
|
label: string;
|