@quadslab.io/discord-mcp 2.0.1 → 2.1.0
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/.claude/.quadcode-version +1 -0
- package/.claude/settings.local.json +154 -0
- package/.claude/skills/architect/SKILL.md +111 -0
- package/.claude/skills/assign-environment/SKILL.md +71 -0
- package/.claude/skills/brainstorm/SKILL.md +114 -0
- package/.claude/skills/brainstorm-spec/SKILL.md +72 -0
- package/.claude/skills/check-implemented/SKILL.md +59 -0
- package/.claude/skills/check-issue-progress/SKILL.md +66 -0
- package/.claude/skills/create-rich-plan/SKILL.md +90 -0
- package/.claude/skills/decompose-spec/SKILL.md +32 -0
- package/.claude/skills/detect-environments/SKILL.md +61 -0
- package/.claude/skills/dispatch/SKILL.md +90 -0
- package/.claude/skills/estimate-complexity/SKILL.md +118 -0
- package/.claude/skills/expand-epic/SKILL.md +38 -0
- package/.claude/skills/find-duplicate-issues/SKILL.md +91 -0
- package/.claude/skills/find-duplicates/SKILL.md +77 -0
- package/.claude/skills/find-related-code/SKILL.md +145 -0
- package/.claude/skills/idea-summary/SKILL.md +57 -0
- package/.claude/skills/idea-to-prompt/SKILL.md +98 -0
- package/.claude/skills/ideas-maintenance/SKILL.md +98 -0
- package/.claude/skills/ideas-to-issues/SKILL.md +108 -0
- package/.claude/skills/issue-summary/SKILL.md +64 -0
- package/.claude/skills/issue-to-prompt/SKILL.md +98 -0
- package/.claude/skills/launch-team/SKILL.md +69 -0
- package/.claude/skills/list-environments/SKILL.md +60 -0
- package/.claude/skills/new-spec/SKILL.md +37 -0
- package/.claude/skills/organize-ideas/SKILL.md +47 -0
- package/.claude/skills/organize-issues/SKILL.md +56 -0
- package/.claude/skills/organize-plans/SKILL.md +47 -0
- package/.claude/skills/plan-from-idea/SKILL.md +102 -0
- package/.claude/skills/plan-summary/SKILL.md +53 -0
- package/.claude/skills/plan-to-issues/SKILL.md +63 -0
- package/.claude/skills/preview-promotion/SKILL.md +47 -0
- package/.claude/skills/review-spec/SKILL.md +53 -0
- package/.claude/skills/run-script/SKILL.md +43 -0
- package/.claude/skills/script-summary/SKILL.md +67 -0
- package/.claude/skills/setup-environment/SKILL.md +78 -0
- package/.claude/skills/setup-python/SKILL.md +123 -0
- package/.claude/skills/setup-scripts/SKILL.md +82 -0
- package/.claude/skills/suggest-improvements/SKILL.md +66 -0
- package/.claude/skills/team-status/SKILL.md +68 -0
- package/.claude/skills/triage-issues/SKILL.md +51 -0
- package/.claude/skills/update-plan-progress/SKILL.md +102 -0
- package/.claude/skills/verify-plan/SKILL.md +54 -0
- package/.claude/skills/weekly-digest/SKILL.md +149 -0
- package/.mcp.json +7 -0
- package/.quadcode/config.json +6 -0
- package/CHANGELOG.md +174 -174
- package/CLAUDE.md +40 -0
- package/LICENSE +21 -21
- package/README.md +678 -668
- package/assets/demo.svg +470 -0
- package/assets/social-preview.html +14 -0
- package/assets/social-preview.svg +98 -0
- package/dist/cli.js +8 -8
- package/dist/tools/threads.js +299 -0
- package/dist/tools/threads.js.map +1 -1
- package/dist/tools/utils.js +48 -3
- package/dist/tools/utils.js.map +1 -1
- package/package.json +58 -58
|
@@ -0,0 +1 @@
|
|
|
1
|
+
1.0.0
|
|
@@ -0,0 +1,154 @@
|
|
|
1
|
+
{
|
|
2
|
+
"env": {
|
|
3
|
+
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
|
|
4
|
+
},
|
|
5
|
+
"permissions": {
|
|
6
|
+
"allow": [
|
|
7
|
+
"mcp__quadcode__*",
|
|
8
|
+
"mcp__qwickcert__*",
|
|
9
|
+
"WebSearch",
|
|
10
|
+
"Bash(git:*)",
|
|
11
|
+
"Bash(git log:*)",
|
|
12
|
+
"Bash(git config:*)",
|
|
13
|
+
"Bash(gh:*)",
|
|
14
|
+
"Bash(npm run:*)",
|
|
15
|
+
"Bash(npm install:*)",
|
|
16
|
+
"Bash(npm ls:*)",
|
|
17
|
+
"Bash(npm test:*)",
|
|
18
|
+
"Bash(npm start:*)",
|
|
19
|
+
"Bash(npm outdated:*)",
|
|
20
|
+
"Bash(npm info:*)",
|
|
21
|
+
"Bash(npm init:*)",
|
|
22
|
+
"Bash(npm ci:*)",
|
|
23
|
+
"Bash(npx:*)",
|
|
24
|
+
"Bash(yarn:*)",
|
|
25
|
+
"Bash(pnpm:*)",
|
|
26
|
+
"Bash(bun:*)",
|
|
27
|
+
"Bash(node:*)",
|
|
28
|
+
"Bash(cargo build:*)",
|
|
29
|
+
"Bash(cargo check:*)",
|
|
30
|
+
"Bash(cargo test:*)",
|
|
31
|
+
"Bash(cargo clean:*)",
|
|
32
|
+
"Bash(cargo run:*)",
|
|
33
|
+
"Bash(cargo doc:*)",
|
|
34
|
+
"Bash(cargo metadata:*)",
|
|
35
|
+
"Bash(cargo clippy:*)",
|
|
36
|
+
"Bash(cargo fmt:*)",
|
|
37
|
+
"Bash(cargo bench:*)",
|
|
38
|
+
"Bash(cargo tree:*)",
|
|
39
|
+
"Bash(cargo update:*)",
|
|
40
|
+
"Bash(cargo add:*)",
|
|
41
|
+
"Bash(cargo remove:*)",
|
|
42
|
+
"Bash(rustfmt:*)",
|
|
43
|
+
"Bash(rustc:*)",
|
|
44
|
+
"Bash(python:*)",
|
|
45
|
+
"Bash(python3:*)",
|
|
46
|
+
"Bash(pip:*)",
|
|
47
|
+
"Bash(pip3:*)",
|
|
48
|
+
"Bash(uv:*)",
|
|
49
|
+
"Bash(poetry:*)",
|
|
50
|
+
"Bash(pytest:*)",
|
|
51
|
+
"Bash(ruff:*)",
|
|
52
|
+
"Bash(black:*)",
|
|
53
|
+
"Bash(mypy:*)",
|
|
54
|
+
"Bash(pylint:*)",
|
|
55
|
+
"Bash(flake8:*)",
|
|
56
|
+
"Bash(dotnet:*)",
|
|
57
|
+
"Bash(go:*)",
|
|
58
|
+
"Bash(deno:*)",
|
|
59
|
+
"Bash(java:*)",
|
|
60
|
+
"Bash(javac:*)",
|
|
61
|
+
"Bash(mvn:*)",
|
|
62
|
+
"Bash(gradle:*)",
|
|
63
|
+
"Bash(make:*)",
|
|
64
|
+
"Bash(cmake:*)",
|
|
65
|
+
"Bash(ls:*)",
|
|
66
|
+
"Bash(dir:*)",
|
|
67
|
+
"Bash(tree:*)",
|
|
68
|
+
"Bash(pwd)",
|
|
69
|
+
"Bash(cd:*)",
|
|
70
|
+
"Bash(which:*)",
|
|
71
|
+
"Bash(where:*)",
|
|
72
|
+
"Bash(cygpath:*)",
|
|
73
|
+
"Bash(realpath:*)",
|
|
74
|
+
"Bash(readlink:*)",
|
|
75
|
+
"Bash(file:*)",
|
|
76
|
+
"Bash(stat:*)",
|
|
77
|
+
"Bash(du:*)",
|
|
78
|
+
"Bash(df:*)",
|
|
79
|
+
"Bash(echo:*)",
|
|
80
|
+
"Bash(printf:*)",
|
|
81
|
+
"Bash(cat:*)",
|
|
82
|
+
"Bash(head:*)",
|
|
83
|
+
"Bash(tail:*)",
|
|
84
|
+
"Bash(wc:*)",
|
|
85
|
+
"Bash(sort:*)",
|
|
86
|
+
"Bash(uniq:*)",
|
|
87
|
+
"Bash(cut:*)",
|
|
88
|
+
"Bash(tr:*)",
|
|
89
|
+
"Bash(tee:*)",
|
|
90
|
+
"Bash(diff:*)",
|
|
91
|
+
"Bash(comm:*)",
|
|
92
|
+
"Bash(paste:*)",
|
|
93
|
+
"Bash(column:*)",
|
|
94
|
+
"Bash(fold:*)",
|
|
95
|
+
"Bash(fmt:*)",
|
|
96
|
+
"Bash(rev:*)",
|
|
97
|
+
"Bash(strings:*)",
|
|
98
|
+
"Bash(xxd:*)",
|
|
99
|
+
"Bash(base64:*)",
|
|
100
|
+
"Bash(md5sum:*)",
|
|
101
|
+
"Bash(sha256sum:*)",
|
|
102
|
+
"Bash(sha1sum:*)",
|
|
103
|
+
"Bash(grep:*)",
|
|
104
|
+
"Bash(rg:*)",
|
|
105
|
+
"Bash(find:*)",
|
|
106
|
+
"Bash(fd:*)",
|
|
107
|
+
"Bash(ag:*)",
|
|
108
|
+
"Bash(findstr:*)",
|
|
109
|
+
"Bash(xargs:*)",
|
|
110
|
+
"Bash(test:*)",
|
|
111
|
+
"Bash(true)",
|
|
112
|
+
"Bash(false)",
|
|
113
|
+
"Bash(date:*)",
|
|
114
|
+
"Bash(whoami)",
|
|
115
|
+
"Bash(hostname)",
|
|
116
|
+
"Bash(uname:*)",
|
|
117
|
+
"Bash(env)",
|
|
118
|
+
"Bash(printenv:*)",
|
|
119
|
+
"Bash(set:*)",
|
|
120
|
+
"Bash(export:*)",
|
|
121
|
+
"Bash(basename:*)",
|
|
122
|
+
"Bash(dirname:*)",
|
|
123
|
+
"Bash(expr:*)",
|
|
124
|
+
"Bash(seq:*)",
|
|
125
|
+
"Bash(yes:*)",
|
|
126
|
+
"Bash(timeout:*)",
|
|
127
|
+
"Bash(sleep:*)",
|
|
128
|
+
"Bash(nproc)",
|
|
129
|
+
"Bash(getconf:*)",
|
|
130
|
+
"Bash(id:*)",
|
|
131
|
+
"Bash(groups)",
|
|
132
|
+
"Bash(jq:*)",
|
|
133
|
+
"Bash(yq:*)",
|
|
134
|
+
"Bash(sqlite3:*)",
|
|
135
|
+
"Bash(mkdir:*)",
|
|
136
|
+
"Bash(cp:*)",
|
|
137
|
+
"Bash(copy:*)",
|
|
138
|
+
"Bash(mv:*)",
|
|
139
|
+
"Bash(touch:*)",
|
|
140
|
+
"Bash(ln:*)",
|
|
141
|
+
"Bash(mktemp:*)",
|
|
142
|
+
"Bash(xcopy:*)",
|
|
143
|
+
"Bash(tar:*)",
|
|
144
|
+
"Bash(zip:*)",
|
|
145
|
+
"Bash(unzip:*)",
|
|
146
|
+
"Bash(gzip:*)",
|
|
147
|
+
"Bash(gunzip:*)",
|
|
148
|
+
"Bash(claude:*)",
|
|
149
|
+
"Bash(claude mcp:*)",
|
|
150
|
+
"Bash(npm publish:*)",
|
|
151
|
+
"Bash(npm whoami:*)"
|
|
152
|
+
]
|
|
153
|
+
}
|
|
154
|
+
}
|
|
@@ -0,0 +1,111 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: architect
|
|
3
|
+
description: Auto-decompose a project or feature into epics, issues, sub-issues, and a comprehensive plan with dependencies
|
|
4
|
+
allowed-tools: mcp__quadcode__create_plan, mcp__quadcode__add_plan_step, mcp__quadcode__create_issue, mcp__quadcode__update_issue, mcp__quadcode__list_issues, mcp__quadcode__list_plans, mcp__quadcode__get_plan, mcp__quadcode__get_issue, mcp__quadcode__add_issue_comment, mcp__quadcode__create_issue_label, mcp__quadcode__list_issue_labels, mcp__quadcode__add_issue_label, mcp__quadcode__create_epic, mcp__quadcode__get_epic, mcp__quadcode__list_epics, mcp__quadcode__update_epic, Read, Glob, Grep
|
|
5
|
+
user-invocable: true
|
|
6
|
+
argument-hint: <project/feature description>
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# Project Architect Skill
|
|
10
|
+
|
|
11
|
+
Automatically decompose a project or feature into a complete work breakdown structure: a plan with hierarchical steps, epic issues with sub-issues, dependencies between issues, and all the metadata needed for multi-agent execution.
|
|
12
|
+
|
|
13
|
+
## Process
|
|
14
|
+
|
|
15
|
+
1. **Parse the request**:
|
|
16
|
+
- $ARGUMENTS describes what to build (e.g., "a SaaS platform for managing pet grooming appointments")
|
|
17
|
+
- If no argument, ask the user what they want to architect
|
|
18
|
+
|
|
19
|
+
2. **Research phase** (if existing codebase):
|
|
20
|
+
- Use `Glob` and `Read` to understand the current project structure
|
|
21
|
+
- Use `Grep` to find existing patterns, frameworks, conventions
|
|
22
|
+
- Identify tech stack and architectural patterns already in use
|
|
23
|
+
|
|
24
|
+
3. **System decomposition**:
|
|
25
|
+
Think through ALL the subsystems the project needs. For a typical web app, consider:
|
|
26
|
+
- **Core infrastructure**: Project setup, CI/CD, deployment, environments
|
|
27
|
+
- **Authentication & authorization**: Login, signup, roles, permissions, OAuth
|
|
28
|
+
- **Data layer**: Database schema, migrations, ORM setup, seed data
|
|
29
|
+
- **API layer**: REST/GraphQL endpoints, middleware, validation, error handling
|
|
30
|
+
- **Frontend**: Layout, routing, state management, component library
|
|
31
|
+
- **Business logic**: Domain-specific features the user described
|
|
32
|
+
- **Integrations**: Email, payments, file storage, third-party APIs
|
|
33
|
+
- **Observability**: Logging, monitoring, error tracking, analytics
|
|
34
|
+
- **Security**: Input sanitization, CSRF, rate limiting, secrets management
|
|
35
|
+
- **Testing**: Unit tests, integration tests, E2E tests
|
|
36
|
+
- **Documentation**: API docs, user guides, developer onboarding
|
|
37
|
+
|
|
38
|
+
The user likely only mentioned the business features. Your job is to identify EVERYTHING else needed for a production system.
|
|
39
|
+
|
|
40
|
+
4. **Create labels** for categorization:
|
|
41
|
+
Use `mcp__quadcode__list_issue_labels` to check existing labels.
|
|
42
|
+
Create any missing labels with `mcp__quadcode__create_issue_label`:
|
|
43
|
+
- `epic` (indigo #6366f1)
|
|
44
|
+
- `infrastructure` (gray #6b7280)
|
|
45
|
+
- `frontend` (blue #3b82f6)
|
|
46
|
+
- `backend` (green #22c55e)
|
|
47
|
+
- `auth` (purple #8b5cf6)
|
|
48
|
+
- `database` (orange #f97316)
|
|
49
|
+
- `testing` (yellow #eab308)
|
|
50
|
+
- `devops` (red #ef4444)
|
|
51
|
+
|
|
52
|
+
5. **Create the master plan**:
|
|
53
|
+
Use `mcp__quadcode__create_plan` with:
|
|
54
|
+
- A clear title (e.g., "Build Pet Grooming SaaS Platform")
|
|
55
|
+
- A comprehensive description covering scope, goals, and architecture
|
|
56
|
+
- Steps organized by phase, with dependencies
|
|
57
|
+
|
|
58
|
+
Add steps using `mcp__quadcode__add_plan_step` for each major phase.
|
|
59
|
+
|
|
60
|
+
6. **Create epics**:
|
|
61
|
+
For each major subsystem, create a standalone epic with `mcp__quadcode__create_epic`:
|
|
62
|
+
- Title: Clear subsystem name (e.g., "Authentication System")
|
|
63
|
+
- Description: Detailed description of what this epic covers
|
|
64
|
+
- Labels: relevant category label (e.g., `backend`, `frontend`)
|
|
65
|
+
- Priority: Based on dependency order (infrastructure = critical, nice-to-haves = low)
|
|
66
|
+
- Status: `open`
|
|
67
|
+
|
|
68
|
+
**IMPORTANT**: Save the returned epic ID — you MUST use it when creating child issues in the next step.
|
|
69
|
+
|
|
70
|
+
7. **Create issues under each epic**:
|
|
71
|
+
For each epic, create 3-8 actionable issues with `mcp__quadcode__create_issue`:
|
|
72
|
+
- **CRITICAL: ALWAYS set `epic_id` to the parent epic's ID** — this links the issue to its epic. Failing to do this creates orphaned issues that are not associated with any epic.
|
|
73
|
+
- Each issue should be completable in one agent session
|
|
74
|
+
- Include acceptance criteria using the `acceptance_criteria` parameter
|
|
75
|
+
- Set `blocked_by` with IDs of issues that must complete first
|
|
76
|
+
- Status: `backlog` if blocked, `todo` if ready
|
|
77
|
+
- Apply relevant labels
|
|
78
|
+
|
|
79
|
+
Example: If you created an epic with ID `abc-123`, every issue under it must include `epic_id: "abc-123"`.
|
|
80
|
+
|
|
81
|
+
**DO NOT** create issues without setting `epic_id`. If you accidentally create issues without it, immediately fix them with `mcp__quadcode__update_issue` to set the `epic_id`.
|
|
82
|
+
|
|
83
|
+
8. **Wire up dependencies**:
|
|
84
|
+
After all issues are created, update issues with `blocked_by` arrays:
|
|
85
|
+
- Infrastructure issues block everything
|
|
86
|
+
- Database schema blocks API endpoints
|
|
87
|
+
- API endpoints block frontend integration
|
|
88
|
+
- Core features block advanced features
|
|
89
|
+
- Everything blocks testing/docs
|
|
90
|
+
|
|
91
|
+
Use `mcp__quadcode__update_issue` to set blocked_by on each issue.
|
|
92
|
+
|
|
93
|
+
9. **Report the architecture**:
|
|
94
|
+
Present a summary showing:
|
|
95
|
+
- Total epics and sub-issues created
|
|
96
|
+
- Dependency graph (what blocks what)
|
|
97
|
+
- Recommended execution order
|
|
98
|
+
- Estimated total scope
|
|
99
|
+
- Which issues are ready to start immediately (no blockers)
|
|
100
|
+
|
|
101
|
+
## Guidelines
|
|
102
|
+
|
|
103
|
+
- **Be thorough**: Users underestimate scope. Include auth, error handling, testing, deployment.
|
|
104
|
+
- **Be practical**: Each sub-issue should be achievable by a single agent in one session.
|
|
105
|
+
- **Dependencies matter**: Issues with unmet blockers go to `backlog`. Issues ready to start go to `todo`.
|
|
106
|
+
- **Title format**: Epics use broad names ("Authentication System"), sub-issues use verb phrases ("Implement JWT token refresh endpoint").
|
|
107
|
+
- **Body format**: Include context, acceptance criteria as checkboxes, and any relevant file paths.
|
|
108
|
+
- **Priority mapping**: Critical = must-have infrastructure, High = core features, Medium = supporting features, Low = nice-to-have/polish.
|
|
109
|
+
- **Don't over-subdivide**: 3-8 sub-issues per epic is ideal. If you need more, create nested epics.
|
|
110
|
+
- **Label everything**: Every issue should have at least one category label.
|
|
111
|
+
- **ALWAYS link issues to epics**: Every issue created under an epic MUST have its `epic_id` set. Never create orphaned issues. If you realize you forgot to set `epic_id`, immediately use `update_issue` to fix it.
|
|
@@ -0,0 +1,71 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: assign-environment
|
|
3
|
+
description: Assign a terminal environment to a build script for proper shell and init commands.
|
|
4
|
+
allowed-tools: mcp__quadcode__list_scripts, mcp__quadcode__list_environments, mcp__quadcode__set_script_environment, mcp__quadcode__get_script
|
|
5
|
+
user-invocable: true
|
|
6
|
+
argument-hint: <script-name> [environment-name]
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# Assign Environment to Script Skill
|
|
10
|
+
|
|
11
|
+
Assign a terminal environment to a build script so it runs with the correct shell, init commands, and environment variables.
|
|
12
|
+
|
|
13
|
+
## When to Use
|
|
14
|
+
|
|
15
|
+
- Script needs Visual Studio native tools (cl.exe, link.exe)
|
|
16
|
+
- Script needs specific environment variables set
|
|
17
|
+
- Script should run in a particular shell (bash vs cmd)
|
|
18
|
+
- Script needs initialization commands before running
|
|
19
|
+
|
|
20
|
+
## Process
|
|
21
|
+
|
|
22
|
+
1. **Parse arguments**:
|
|
23
|
+
- First argument: script name to assign to
|
|
24
|
+
- Second argument (optional): environment name to assign
|
|
25
|
+
|
|
26
|
+
2. **Find the script**:
|
|
27
|
+
- Use `mcp__quadcode__list_scripts` to find by name
|
|
28
|
+
- Match case-insensitively
|
|
29
|
+
|
|
30
|
+
3. **If no environment specified**:
|
|
31
|
+
- Use `mcp__quadcode__list_environments` to show options
|
|
32
|
+
- Ask user which environment to assign
|
|
33
|
+
- Or ask if they want to clear the assignment (set to none)
|
|
34
|
+
|
|
35
|
+
4. **Assign the environment**:
|
|
36
|
+
- Use `mcp__quadcode__set_script_environment`
|
|
37
|
+
- Pass script ID and environment ID
|
|
38
|
+
|
|
39
|
+
5. **Confirm the assignment**:
|
|
40
|
+
- Show the updated script
|
|
41
|
+
- Explain what will happen when script runs
|
|
42
|
+
|
|
43
|
+
## Examples
|
|
44
|
+
|
|
45
|
+
```
|
|
46
|
+
/assign-environment "Tauri Build" "VS 2022 Community x64"
|
|
47
|
+
-> Assigns VS 2022 x64 environment to Tauri Build script
|
|
48
|
+
|
|
49
|
+
/assign-environment dev
|
|
50
|
+
-> Lists environments and asks which to assign to "dev" script
|
|
51
|
+
|
|
52
|
+
/assign-environment "Build" none
|
|
53
|
+
-> Clears environment assignment from "Build" script
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
## What Happens When Script Runs
|
|
57
|
+
|
|
58
|
+
When a script with an assigned environment runs:
|
|
59
|
+
1. Terminal opens with the environment's shell (cmd/powershell/bash)
|
|
60
|
+
2. Init commands execute (e.g., vcvarsall.bat)
|
|
61
|
+
3. Environment variables are set
|
|
62
|
+
4. Then the script's main command runs
|
|
63
|
+
|
|
64
|
+
## Common Assignments
|
|
65
|
+
|
|
66
|
+
| Script Type | Recommended Environment |
|
|
67
|
+
|------------|------------------------|
|
|
68
|
+
| Tauri/Rust builds on Windows | VS 2022 x64 |
|
|
69
|
+
| Node.js builds | Default (or PowerShell) |
|
|
70
|
+
| Python scripts | Custom Python venv |
|
|
71
|
+
| Cross-compilation | VS with specific arch |
|
|
@@ -0,0 +1,114 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: brainstorm
|
|
3
|
+
description: Generate related ideas around a topic or existing idea. Creates new ideas and tags them appropriately.
|
|
4
|
+
allowed-tools: mcp__quadcode__list_ideas, mcp__quadcode__get_idea, mcp__quadcode__create_idea, mcp__quadcode__add_tag, Read, Grep, Glob
|
|
5
|
+
user-invocable: true
|
|
6
|
+
argument-hint: [topic or idea-id]
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# Brainstorm Skill
|
|
10
|
+
|
|
11
|
+
Generate creative ideas related to a topic or expand on an existing idea.
|
|
12
|
+
|
|
13
|
+
## Process
|
|
14
|
+
|
|
15
|
+
1. **Determine brainstorm focus**:
|
|
16
|
+
- If an idea ID is provided ($ARGUMENTS as number): Expand on that idea
|
|
17
|
+
- If a topic is provided ($ARGUMENTS as text): Brainstorm around that topic
|
|
18
|
+
- If no argument: Ask user what to brainstorm about
|
|
19
|
+
|
|
20
|
+
2. **Gather context**:
|
|
21
|
+
- If expanding an idea, use `mcp__quadcode__get_idea` to understand it fully
|
|
22
|
+
- Review existing ideas with `mcp__quadcode__list_ideas` to avoid duplicates
|
|
23
|
+
- Search codebase with `Grep` and `Glob` to understand current capabilities
|
|
24
|
+
- Consider existing tags and categories
|
|
25
|
+
|
|
26
|
+
3. **Generate ideas** across multiple dimensions:
|
|
27
|
+
|
|
28
|
+
### For Feature Topics
|
|
29
|
+
- **Core functionality**: Direct implementations
|
|
30
|
+
- **Variations**: Different approaches to same goal
|
|
31
|
+
- **Enhancements**: Ways to make it better
|
|
32
|
+
- **Related features**: Complementary functionality
|
|
33
|
+
- **Edge cases**: Handle special scenarios
|
|
34
|
+
- **User experience**: How users interact with it
|
|
35
|
+
|
|
36
|
+
### For Problem Topics
|
|
37
|
+
- **Root causes**: Address underlying issues
|
|
38
|
+
- **Workarounds**: Quick fixes
|
|
39
|
+
- **Prevention**: Avoid the problem
|
|
40
|
+
- **Detection**: Know when it happens
|
|
41
|
+
- **Recovery**: Handle gracefully
|
|
42
|
+
|
|
43
|
+
### For Improvement Topics
|
|
44
|
+
- **Performance**: Make it faster
|
|
45
|
+
- **Usability**: Make it easier
|
|
46
|
+
- **Reliability**: Make it more robust
|
|
47
|
+
- **Maintainability**: Make it cleaner
|
|
48
|
+
- **Extensibility**: Make it more flexible
|
|
49
|
+
|
|
50
|
+
4. **Quality check each idea**:
|
|
51
|
+
- Is it actionable?
|
|
52
|
+
- Is it distinct from existing ideas?
|
|
53
|
+
- Is it relevant to the project?
|
|
54
|
+
- Is it clear and specific?
|
|
55
|
+
|
|
56
|
+
5. **Create ideas** using `mcp__quadcode__create_idea`:
|
|
57
|
+
- Write clear, actionable content
|
|
58
|
+
- Include brief rationale or benefit
|
|
59
|
+
|
|
60
|
+
6. **Tag new ideas** using `mcp__quadcode__add_tag`:
|
|
61
|
+
- Category tag (ui-window, mcp, etc.)
|
|
62
|
+
- `brainstormed` tag to track origin
|
|
63
|
+
- `related-to-[original-id]` if expanding an idea
|
|
64
|
+
- Any relevant priority or complexity tags
|
|
65
|
+
|
|
66
|
+
7. **Present results**:
|
|
67
|
+
|
|
68
|
+
```
|
|
69
|
+
## Brainstorm Results: [Topic/Idea]
|
|
70
|
+
|
|
71
|
+
### Context
|
|
72
|
+
[Brief description of what was brainstormed]
|
|
73
|
+
|
|
74
|
+
### New Ideas Created
|
|
75
|
+
|
|
76
|
+
#### Core Ideas
|
|
77
|
+
1. **Idea #X**: [content]
|
|
78
|
+
- Tags: [tags]
|
|
79
|
+
- Rationale: [why this idea]
|
|
80
|
+
|
|
81
|
+
2. **Idea #Y**: [content]
|
|
82
|
+
- Tags: [tags]
|
|
83
|
+
- Rationale: [why this idea]
|
|
84
|
+
|
|
85
|
+
#### Enhancement Ideas
|
|
86
|
+
[Similar format]
|
|
87
|
+
|
|
88
|
+
#### Alternative Approaches
|
|
89
|
+
[Similar format]
|
|
90
|
+
|
|
91
|
+
### Summary
|
|
92
|
+
- Total ideas generated: X
|
|
93
|
+
- Categories covered: [list]
|
|
94
|
+
- Recommended starting point: Idea #X
|
|
95
|
+
|
|
96
|
+
### Discarded Ideas
|
|
97
|
+
[Ideas considered but not created, with reasons]
|
|
98
|
+
```
|
|
99
|
+
|
|
100
|
+
## Brainstorm Modes
|
|
101
|
+
|
|
102
|
+
If mode specified in $ARGUMENTS:
|
|
103
|
+
- `quick` - Generate 3-5 focused ideas
|
|
104
|
+
- `deep` - Generate 10+ ideas with thorough analysis
|
|
105
|
+
- `wild` - Include unconventional/creative ideas
|
|
106
|
+
- `practical` - Focus only on immediately actionable ideas
|
|
107
|
+
|
|
108
|
+
## Notes
|
|
109
|
+
|
|
110
|
+
- Aim for quality over quantity
|
|
111
|
+
- Each idea should stand alone (don't require reading others)
|
|
112
|
+
- Reference existing ideas when relevant
|
|
113
|
+
- Consider technical feasibility but don't limit creativity
|
|
114
|
+
- Group related ideas with consistent tagging
|
|
@@ -0,0 +1,72 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Interactive brainstorm session to explore an idea and generate a spec document. Creates the spec collaboratively with the user.
|
|
3
|
+
argument-hint: <plan_id> [initial idea description]
|
|
4
|
+
allowed-tools: mcp__quadcode__get_plan, mcp__quadcode__update_plan, mcp__quadcode__add_plan_comment, Read, Glob, Grep
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Brainstorm Spec
|
|
8
|
+
|
|
9
|
+
An interactive brainstorming session to help the user develop their idea into a full specification document.
|
|
10
|
+
|
|
11
|
+
## Process
|
|
12
|
+
|
|
13
|
+
1. Get the plan by ID (first argument): `mcp__quadcode__get_plan`
|
|
14
|
+
2. Read the plan's `specType` (greenfield/feature/refactor) for context
|
|
15
|
+
3. If there's an initial idea description (remaining arguments after plan ID), use it as the starting point
|
|
16
|
+
4. If the plan is for a feature or refactor, explore the codebase first to understand existing architecture
|
|
17
|
+
|
|
18
|
+
## Brainstorm Flow
|
|
19
|
+
|
|
20
|
+
Start by acknowledging the idea and asking targeted questions to flesh it out. Guide the conversation through these areas:
|
|
21
|
+
|
|
22
|
+
### 1. Vision & Goals
|
|
23
|
+
- What problem does this solve?
|
|
24
|
+
- Who is the target user?
|
|
25
|
+
- What does success look like?
|
|
26
|
+
|
|
27
|
+
### 2. Core Requirements
|
|
28
|
+
- What are the must-have features?
|
|
29
|
+
- What are nice-to-haves?
|
|
30
|
+
- Any constraints (tech stack, timeline, budget)?
|
|
31
|
+
|
|
32
|
+
### 3. Technical Approach
|
|
33
|
+
- What architecture makes sense?
|
|
34
|
+
- What technologies/frameworks?
|
|
35
|
+
- How does this integrate with existing systems? (if feature/refactor)
|
|
36
|
+
|
|
37
|
+
### 4. Edge Cases & Risks
|
|
38
|
+
- What could go wrong?
|
|
39
|
+
- What are the hardest parts?
|
|
40
|
+
- Any security or performance concerns?
|
|
41
|
+
|
|
42
|
+
### 5. Scope Definition
|
|
43
|
+
- What's in scope vs out of scope?
|
|
44
|
+
- What's the MVP vs full vision?
|
|
45
|
+
|
|
46
|
+
## When the User is Ready
|
|
47
|
+
|
|
48
|
+
After the brainstorm conversation reaches a natural conclusion (or the user says they're ready), generate a comprehensive markdown spec document and save it:
|
|
49
|
+
|
|
50
|
+
1. Compile all discussed points into a structured spec with sections:
|
|
51
|
+
- Overview
|
|
52
|
+
- Goals & Success Criteria
|
|
53
|
+
- Requirements (Functional & Non-functional)
|
|
54
|
+
- Architecture & Design
|
|
55
|
+
- Data Model
|
|
56
|
+
- API Design
|
|
57
|
+
- Security
|
|
58
|
+
- Testing Strategy
|
|
59
|
+
- Open Questions (if any remain)
|
|
60
|
+
|
|
61
|
+
2. Save via `mcp__quadcode__update_plan` with `spec_content` set to the generated spec
|
|
62
|
+
3. Set status to `spec_review`
|
|
63
|
+
4. Tell the user their spec is saved and they can review it in the Plans UI
|
|
64
|
+
|
|
65
|
+
## Guidelines
|
|
66
|
+
|
|
67
|
+
- Be conversational and collaborative — this is a brainstorm, not an interrogation
|
|
68
|
+
- Ask 2-3 questions at a time, not a wall of questions
|
|
69
|
+
- Build on the user's answers, suggest ideas they might not have considered
|
|
70
|
+
- For feature/refactor plans, reference actual code and patterns from the codebase
|
|
71
|
+
- Don't generate the spec until the user indicates they're ready
|
|
72
|
+
- The spec should reflect THEIR vision, not yours — you're helping them articulate it
|
|
@@ -0,0 +1,59 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: check-implemented
|
|
3
|
+
description: Check if ideas have been implemented in the codebase. Use this to audit which ideas are complete, in progress, or still pending.
|
|
4
|
+
allowed-tools: mcp__quadcode__list_ideas, mcp__quadcode__add_tag, mcp__quadcode__add_idea_note, mcp__quadcode__update_idea, Read, Grep, Glob
|
|
5
|
+
user-invocable: true
|
|
6
|
+
argument-hint: [category]
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# Check Implemented Ideas Skill
|
|
10
|
+
|
|
11
|
+
You are tasked with checking which QuadCode ideas have been implemented in the codebase.
|
|
12
|
+
|
|
13
|
+
## Process
|
|
14
|
+
|
|
15
|
+
1. **Get all ideas** using `mcp__quadcode__list_ideas`
|
|
16
|
+
|
|
17
|
+
2. **For each idea**, search the codebase to determine if it's implemented:
|
|
18
|
+
- Use `Grep` to search for related keywords
|
|
19
|
+
- Use `Glob` to find relevant files
|
|
20
|
+
- Use `Read` to verify implementation
|
|
21
|
+
|
|
22
|
+
3. **Tag ideas appropriately**:
|
|
23
|
+
- Add `implemented` tag if fully implemented
|
|
24
|
+
- Add `in-progress` tag if partially implemented
|
|
25
|
+
- Add `not-started` tag if no implementation found
|
|
26
|
+
|
|
27
|
+
4. **Add implementation notes** using `mcp__quadcode__add_idea_note`:
|
|
28
|
+
- Set `author` to `"check-implemented"`
|
|
29
|
+
- For implemented ideas: Note where it's implemented (file paths)
|
|
30
|
+
- For in-progress: Note what's done and what remains
|
|
31
|
+
- For not-started: Note any relevant existing code that could help
|
|
32
|
+
|
|
33
|
+
Example:
|
|
34
|
+
```
|
|
35
|
+
mcp__quadcode__add_idea_note({
|
|
36
|
+
idea_id: "...",
|
|
37
|
+
body: "Implemented in src/lib/database.ts:123-150. Full CRUD operations complete.",
|
|
38
|
+
author: "check-implemented"
|
|
39
|
+
})
|
|
40
|
+
```
|
|
41
|
+
|
|
42
|
+
5. **Generate a report** showing:
|
|
43
|
+
- Implemented ideas count and list
|
|
44
|
+
- In-progress ideas count and list
|
|
45
|
+
- Not-started ideas count and list
|
|
46
|
+
- Implementation coverage percentage
|
|
47
|
+
|
|
48
|
+
## Category Filter
|
|
49
|
+
|
|
50
|
+
If a category is provided ($ARGUMENTS), only check ideas with that tag:
|
|
51
|
+
- `mcp` - Check MCP-related ideas
|
|
52
|
+
- `ui-window` - Check UI/window ideas
|
|
53
|
+
- `terminal` - Check terminal ideas
|
|
54
|
+
- etc.
|
|
55
|
+
|
|
56
|
+
## Notes vs Suggestions
|
|
57
|
+
|
|
58
|
+
- Use **notes** (`add_idea_note`) for implementation status, observations, and code references
|
|
59
|
+
- Use **suggestions** (`add_suggestion`) only for text/wording improvements to the idea content itself
|
|
@@ -0,0 +1,66 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: check-issue-progress
|
|
3
|
+
description: Check the codebase to see which issues have been resolved, partially implemented, or are still pending. Use this to audit issue completion status.
|
|
4
|
+
allowed-tools: mcp__quadcode__list_issues, mcp__quadcode__get_issue, mcp__quadcode__update_issue, mcp__quadcode__add_issue_comment, mcp__quadcode__close_issue, Read, Grep, Glob
|
|
5
|
+
user-invocable: true
|
|
6
|
+
argument-hint: [issue-id]
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# Check Issue Progress Skill
|
|
10
|
+
|
|
11
|
+
You are tasked with checking the codebase to determine which issues have been resolved or are in progress.
|
|
12
|
+
|
|
13
|
+
## Process
|
|
14
|
+
|
|
15
|
+
1. **Get issues to check**:
|
|
16
|
+
- If an issue ID is provided ($ARGUMENTS), check just that issue
|
|
17
|
+
- Otherwise, use `mcp__quadcode__list_issues` to get all open issues
|
|
18
|
+
|
|
19
|
+
2. **For each issue**, search the codebase to determine implementation status:
|
|
20
|
+
- Use `Grep` to search for related keywords, function names, or features
|
|
21
|
+
- Use `Glob` to find relevant files
|
|
22
|
+
- Use `Read` to verify implementation details
|
|
23
|
+
|
|
24
|
+
3. **Evaluate each issue:**
|
|
25
|
+
|
|
26
|
+
**Completed** (close with `close_issue`):
|
|
27
|
+
- Feature/fix is fully implemented
|
|
28
|
+
- Add comment noting where it was implemented (file paths, line numbers)
|
|
29
|
+
|
|
30
|
+
**In Progress** (update status to `in_progress`):
|
|
31
|
+
- Partial implementation found
|
|
32
|
+
- Add comment noting what's done and what remains
|
|
33
|
+
|
|
34
|
+
**Not Started** (keep as `todo` or `backlog`):
|
|
35
|
+
- No implementation found
|
|
36
|
+
- Add comment noting relevant existing code that could help
|
|
37
|
+
|
|
38
|
+
4. **Generate a progress report:**
|
|
39
|
+
- Completed issues (auto-closed)
|
|
40
|
+
- In-progress issues (with progress notes)
|
|
41
|
+
- Not started issues
|
|
42
|
+
- Overall completion percentage
|
|
43
|
+
|
|
44
|
+
## Search Strategies
|
|
45
|
+
|
|
46
|
+
For bugs: Search for error handling, fix comments, related error messages
|
|
47
|
+
For features: Search for feature keywords, UI components, API endpoints
|
|
48
|
+
For enhancements: Search for the feature being enhanced
|
|
49
|
+
|
|
50
|
+
## Output
|
|
51
|
+
|
|
52
|
+
Provide a clear summary:
|
|
53
|
+
```
|
|
54
|
+
## Issue Progress Report
|
|
55
|
+
|
|
56
|
+
### Completed (X issues)
|
|
57
|
+
- [Issue title] - Implemented in [file(s)]
|
|
58
|
+
|
|
59
|
+
### In Progress (X issues)
|
|
60
|
+
- [Issue title] - [what's done] / [what remains]
|
|
61
|
+
|
|
62
|
+
### Not Started (X issues)
|
|
63
|
+
- [Issue title] - [relevant existing code]
|
|
64
|
+
|
|
65
|
+
**Completion Rate:** X%
|
|
66
|
+
```
|