@quadslab.io/discord-mcp 2.0.0 → 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 +16 -12
- package/dist/cli.js.map +1 -1
- 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,67 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: script-summary
|
|
3
|
+
description: Get a quick summary of all build scripts and environments in QuadCode. Shows scripts grouped by type and environment assignments.
|
|
4
|
+
allowed-tools: mcp__quadcode__list_scripts, mcp__quadcode__list_environments, mcp__quadcode__review_scripts
|
|
5
|
+
user-invocable: true
|
|
6
|
+
argument-hint:
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# Script Summary Skill
|
|
10
|
+
|
|
11
|
+
Provide a quick overview of all build scripts and terminal environments in QuadCode.
|
|
12
|
+
|
|
13
|
+
## Process
|
|
14
|
+
|
|
15
|
+
1. **Get all scripts** using `mcp__quadcode__list_scripts`
|
|
16
|
+
|
|
17
|
+
2. **Get all environments** using `mcp__quadcode__list_environments`
|
|
18
|
+
|
|
19
|
+
3. **Display summary**:
|
|
20
|
+
|
|
21
|
+
### Scripts Overview
|
|
22
|
+
```
|
|
23
|
+
## Build Scripts (X total)
|
|
24
|
+
|
|
25
|
+
### With Environment
|
|
26
|
+
- Tauri Dev [VS 2022 x64] - npm run tauri dev
|
|
27
|
+
- Tauri Build [VS 2022 x64] - npm run tauri build
|
|
28
|
+
|
|
29
|
+
### Without Environment
|
|
30
|
+
- Test Frontend - npm test
|
|
31
|
+
- Lint - npm run lint
|
|
32
|
+
|
|
33
|
+
### By Platform
|
|
34
|
+
- Windows only: 2
|
|
35
|
+
- All platforms: 3
|
|
36
|
+
```
|
|
37
|
+
|
|
38
|
+
### Environments Overview
|
|
39
|
+
```
|
|
40
|
+
## Environments (X total)
|
|
41
|
+
|
|
42
|
+
### System Shells (X)
|
|
43
|
+
- CMD, PowerShell, Git Bash
|
|
44
|
+
|
|
45
|
+
### VS Native Tools (X)
|
|
46
|
+
- VS 2022 Community x64/x86
|
|
47
|
+
|
|
48
|
+
### Custom (X)
|
|
49
|
+
- Rust Nightly, Python ML
|
|
50
|
+
|
|
51
|
+
Default: PowerShell
|
|
52
|
+
```
|
|
53
|
+
|
|
54
|
+
4. **Highlight issues**:
|
|
55
|
+
- Scripts without environment that might need one (Rust/Tauri on Windows)
|
|
56
|
+
- Unavailable environments
|
|
57
|
+
- Missing VS tools if Rust/Tauri project detected
|
|
58
|
+
|
|
59
|
+
5. **Suggest actions**:
|
|
60
|
+
- Run `/detect-environments` if no VS tools found
|
|
61
|
+
- Run `/setup-scripts` if few scripts exist
|
|
62
|
+
- Run `/assign-environment` for scripts needing environments
|
|
63
|
+
|
|
64
|
+
## Output Style
|
|
65
|
+
|
|
66
|
+
Keep it concise - this is meant for a quick glance, not detailed review.
|
|
67
|
+
Use tables or bullet lists for easy scanning.
|
|
@@ -0,0 +1,78 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: setup-environment
|
|
3
|
+
description: Create a custom terminal environment with init commands and environment variables.
|
|
4
|
+
allowed-tools: mcp__quadcode__create_environment, mcp__quadcode__list_environments, mcp__quadcode__update_environment
|
|
5
|
+
user-invocable: true
|
|
6
|
+
argument-hint: <environment-name>
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# Setup Custom Environment Skill
|
|
10
|
+
|
|
11
|
+
Create a custom terminal environment in QuadCode with initialization commands and environment variables.
|
|
12
|
+
|
|
13
|
+
## When to Use
|
|
14
|
+
|
|
15
|
+
- Need a specialized development environment (e.g., Rust nightly, specific Python venv)
|
|
16
|
+
- Want to pre-configure environment variables for builds
|
|
17
|
+
- Need to run setup commands every time a terminal opens
|
|
18
|
+
- Want to combine multiple init steps into one environment
|
|
19
|
+
|
|
20
|
+
## Process
|
|
21
|
+
|
|
22
|
+
1. **If $ARGUMENTS provided**: Use it as the environment name
|
|
23
|
+
|
|
24
|
+
2. **Gather requirements** by asking user:
|
|
25
|
+
- What shell should it use? (cmd, powershell, bash)
|
|
26
|
+
- What init commands should run when terminal starts?
|
|
27
|
+
- What environment variables should be set?
|
|
28
|
+
- Brief description of the environment's purpose
|
|
29
|
+
|
|
30
|
+
3. **Create the environment** using `mcp__quadcode__create_environment`:
|
|
31
|
+
- `name`: Descriptive name
|
|
32
|
+
- `description`: What it's for
|
|
33
|
+
- `env_type`: Usually "custom"
|
|
34
|
+
- `shell`: cmd/powershell/bash/default
|
|
35
|
+
- `init_commands`: Array of commands to run on startup
|
|
36
|
+
- `env`: Key-value pairs of environment variables
|
|
37
|
+
|
|
38
|
+
4. **Confirm creation** and show the new environment
|
|
39
|
+
|
|
40
|
+
## Examples
|
|
41
|
+
|
|
42
|
+
### Rust Nightly Environment
|
|
43
|
+
```
|
|
44
|
+
Name: Rust Nightly
|
|
45
|
+
Shell: powershell
|
|
46
|
+
Init commands:
|
|
47
|
+
- rustup default nightly
|
|
48
|
+
Env vars:
|
|
49
|
+
- RUSTFLAGS=-C target-cpu=native
|
|
50
|
+
```
|
|
51
|
+
|
|
52
|
+
### Python Virtual Environment
|
|
53
|
+
```
|
|
54
|
+
Name: Python ML Env
|
|
55
|
+
Shell: bash
|
|
56
|
+
Init commands:
|
|
57
|
+
- source ~/venvs/ml/bin/activate
|
|
58
|
+
Env vars:
|
|
59
|
+
- PYTHONPATH=./src
|
|
60
|
+
```
|
|
61
|
+
|
|
62
|
+
### Custom CUDA Build Environment
|
|
63
|
+
```
|
|
64
|
+
Name: CUDA Build
|
|
65
|
+
Shell: cmd
|
|
66
|
+
Init commands:
|
|
67
|
+
- call "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build\vcvarsall.bat" x64
|
|
68
|
+
Env vars:
|
|
69
|
+
- CUDA_PATH=C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v12.6
|
|
70
|
+
- CUDA_HOME=C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v12.6
|
|
71
|
+
```
|
|
72
|
+
|
|
73
|
+
## After Creation
|
|
74
|
+
|
|
75
|
+
Inform the user they can:
|
|
76
|
+
- Assign this environment to scripts using `/assign-environment`
|
|
77
|
+
- Set it as default using `mcp__quadcode__set_default_environment`
|
|
78
|
+
- Edit it later in the Environments tab of Script Launcher
|
|
@@ -0,0 +1,123 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: setup-python
|
|
3
|
+
description: Detect Python project structure and create scripts with watchdog auto-restart for dev mode.
|
|
4
|
+
allowed-tools: mcp__quadcode__list_scripts, mcp__quadcode__create_script, mcp__quadcode__list_environments, mcp__quadcode__set_script_environment, Read, Glob, Grep
|
|
5
|
+
user-invocable: true
|
|
6
|
+
argument-hint: [entry-point]
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# Setup Python Scripts Skill
|
|
10
|
+
|
|
11
|
+
Detect Python project structure and create build/run scripts with watchdog file-watching for dev mode.
|
|
12
|
+
|
|
13
|
+
## Process
|
|
14
|
+
|
|
15
|
+
1. **Detect Python project** by looking for:
|
|
16
|
+
- `pyproject.toml` -> Modern Python project (check for framework in `[project.dependencies]`)
|
|
17
|
+
- `setup.py` or `setup.cfg` -> Legacy Python project
|
|
18
|
+
- `requirements.txt` -> Pip-based project
|
|
19
|
+
- `Pipfile` -> Pipenv project
|
|
20
|
+
- `poetry.lock` -> Poetry project
|
|
21
|
+
|
|
22
|
+
2. **Detect virtual environment** by checking for:
|
|
23
|
+
- `.venv/` or `venv/` or `env/` directories
|
|
24
|
+
- If found, use activation as a setup command:
|
|
25
|
+
- Windows: `.venv\Scripts\activate`
|
|
26
|
+
- Unix: `source .venv/bin/activate`
|
|
27
|
+
|
|
28
|
+
3. **Detect entry point** (use `$ARGUMENTS` if provided, otherwise auto-detect):
|
|
29
|
+
- `manage.py` -> Django project
|
|
30
|
+
- `app.py` -> Check for Flask/FastAPI imports
|
|
31
|
+
- `main.py` -> Check for FastAPI/general entry
|
|
32
|
+
- `run.py`, `server.py`, `wsgi.py`, `asgi.py` -> Web server entry
|
|
33
|
+
- `src/<package>/__main__.py` -> Package with __main__
|
|
34
|
+
- Fallback: first `.py` file with `if __name__` block in project root
|
|
35
|
+
|
|
36
|
+
4. **Detect framework** by reading the entry point and config files:
|
|
37
|
+
- **Django**: `manage.py` exists, imports `django`
|
|
38
|
+
- **Flask**: imports `flask`, has `app = Flask(...)`
|
|
39
|
+
- **FastAPI**: imports `fastapi`, has `app = FastAPI(...)`
|
|
40
|
+
- **Streamlit**: imports `streamlit`
|
|
41
|
+
- **General**: no framework detected
|
|
42
|
+
|
|
43
|
+
5. **Detect testing tools** by checking:
|
|
44
|
+
- `pytest` in dependencies or `pytest.ini` / `pyproject.toml [tool.pytest]` -> pytest
|
|
45
|
+
- `tests/` or `test/` directory exists -> likely has tests
|
|
46
|
+
- Fallback: `python -m unittest discover`
|
|
47
|
+
|
|
48
|
+
6. **Detect linting tools**:
|
|
49
|
+
- `ruff` in dependencies or `ruff.toml` -> `ruff check .`
|
|
50
|
+
- `flake8` in dependencies or `.flake8` -> `flake8`
|
|
51
|
+
- `pylint` in dependencies -> `pylint <package>`
|
|
52
|
+
- Fallback: suggest `ruff check .`
|
|
53
|
+
|
|
54
|
+
7. **Check existing scripts** using `mcp__quadcode__list_scripts` - skip any that already exist
|
|
55
|
+
|
|
56
|
+
8. **Create scripts** using `mcp__quadcode__create_script`:
|
|
57
|
+
|
|
58
|
+
### For Django Projects
|
|
59
|
+
| Script | Command | Description |
|
|
60
|
+
|--------|---------|-------------|
|
|
61
|
+
| Run Server | `python manage.py runserver` | Start Django dev server |
|
|
62
|
+
| Dev (Watchdog) | `watchmedo auto-restart --patterns="*.py;*.html;*.css" --recursive --signal SIGTERM -- python manage.py runserver` | Auto-restart on file changes |
|
|
63
|
+
| Migrate | `python manage.py migrate` | Run database migrations |
|
|
64
|
+
| Make Migrations | `python manage.py makemigrations` | Create new migrations |
|
|
65
|
+
| Test | `python manage.py test` or `pytest` | Run tests |
|
|
66
|
+
| Shell | `python manage.py shell` | Django interactive shell |
|
|
67
|
+
|
|
68
|
+
### For Flask Projects
|
|
69
|
+
| Script | Command | Description |
|
|
70
|
+
|--------|---------|-------------|
|
|
71
|
+
| Run | `python <entry_point>` | Start Flask app |
|
|
72
|
+
| Dev (Watchdog) | `watchmedo auto-restart --patterns="*.py;*.html;*.css" --recursive --signal SIGTERM -- python <entry_point>` | Auto-restart on file changes |
|
|
73
|
+
| Test | `pytest` | Run tests |
|
|
74
|
+
|
|
75
|
+
- Also set env var `FLASK_ENV=development` on dev scripts
|
|
76
|
+
|
|
77
|
+
### For FastAPI Projects
|
|
78
|
+
| Script | Command | Description |
|
|
79
|
+
|--------|---------|-------------|
|
|
80
|
+
| Run | `uvicorn <module>:app --host 0.0.0.0 --port 8000` | Start with uvicorn |
|
|
81
|
+
| Dev (Watchdog) | `uvicorn <module>:app --host 0.0.0.0 --port 8000 --reload` | Uvicorn's built-in reload (uses watchdog internally) |
|
|
82
|
+
| Test | `pytest` | Run tests |
|
|
83
|
+
|
|
84
|
+
- Note: FastAPI/uvicorn has built-in `--reload` which uses watchdog. Prefer this over manual watchmedo.
|
|
85
|
+
|
|
86
|
+
### For Streamlit Projects
|
|
87
|
+
| Script | Command | Description |
|
|
88
|
+
|--------|---------|-------------|
|
|
89
|
+
| Run | `streamlit run <entry_point>` | Start Streamlit app (has built-in file watching) |
|
|
90
|
+
| Test | `pytest` | Run tests |
|
|
91
|
+
|
|
92
|
+
### For General Python Projects
|
|
93
|
+
| Script | Command | Description |
|
|
94
|
+
|--------|---------|-------------|
|
|
95
|
+
| Run | `python <entry_point>` | Run the main script |
|
|
96
|
+
| Dev (Watchdog) | `watchmedo auto-restart --patterns="*.py" --recursive --signal SIGTERM -- python <entry_point>` | Auto-restart on file changes |
|
|
97
|
+
| Test | `pytest` or `python -m unittest discover` | Run tests |
|
|
98
|
+
| Install Deps | `pip install -r requirements.txt` or `pip install -e .` | Install dependencies |
|
|
99
|
+
|
|
100
|
+
### Common Scripts (all project types)
|
|
101
|
+
| Script | Command | Description |
|
|
102
|
+
|--------|---------|-------------|
|
|
103
|
+
| Lint | Detected linter command | Run linter |
|
|
104
|
+
| Format | `ruff format .` or `black .` | Format code |
|
|
105
|
+
| Install Deps | Package manager install command | Install/update dependencies |
|
|
106
|
+
|
|
107
|
+
9. **Set virtual environment activation** as `setup_commands` on all scripts if a venv was detected
|
|
108
|
+
|
|
109
|
+
10. **Report results**: List created scripts and note:
|
|
110
|
+
- If watchdog is not installed, tell user to run: `pip install watchdog`
|
|
111
|
+
- If no entry point was found, explain how to specify one: `/setup-python app.py`
|
|
112
|
+
|
|
113
|
+
## Override
|
|
114
|
+
|
|
115
|
+
If `$ARGUMENTS` provides an entry point file, use it directly instead of auto-detecting.
|
|
116
|
+
|
|
117
|
+
## Notes
|
|
118
|
+
|
|
119
|
+
- The `watchmedo` command comes from the `watchdog` Python package (`pip install watchdog`)
|
|
120
|
+
- For FastAPI, prefer uvicorn's `--reload` flag over watchmedo since it uses watchdog internally
|
|
121
|
+
- For Streamlit, file watching is built-in so no watchdog script is needed
|
|
122
|
+
- On Windows, use `--signal SIGTERM` is not available; omit the `--signal` flag
|
|
123
|
+
- The `--patterns` flag accepts semicolon-separated globs
|
|
@@ -0,0 +1,82 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: setup-scripts
|
|
3
|
+
description: Analyze the project and create appropriate build scripts for common tasks like build, test, dev server, etc.
|
|
4
|
+
allowed-tools: mcp__quadcode__list_scripts, mcp__quadcode__create_script, mcp__quadcode__review_scripts, mcp__quadcode__list_environments, mcp__quadcode__set_script_environment, Read, Glob
|
|
5
|
+
user-invocable: true
|
|
6
|
+
argument-hint: [project-type]
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# Setup Build Scripts Skill
|
|
10
|
+
|
|
11
|
+
Analyze the project and create useful build scripts in QuadCode.
|
|
12
|
+
|
|
13
|
+
## Process
|
|
14
|
+
|
|
15
|
+
1. **Detect project type** by looking for:
|
|
16
|
+
- `package.json` -> Node.js/npm project
|
|
17
|
+
- `Cargo.toml` -> Rust project
|
|
18
|
+
- `tauri.conf.json` -> Tauri project
|
|
19
|
+
- `pyproject.toml` or `requirements.txt` -> Python project
|
|
20
|
+
- `go.mod` -> Go project
|
|
21
|
+
|
|
22
|
+
2. **Check existing scripts** using `mcp__quadcode__list_scripts`
|
|
23
|
+
|
|
24
|
+
3. **Check available environments** using `mcp__quadcode__list_environments`
|
|
25
|
+
- If VS Native Tools environments exist, use them for Rust/Tauri builds
|
|
26
|
+
- This is important for Windows builds that need cl.exe, link.exe
|
|
27
|
+
|
|
28
|
+
4. **Create appropriate scripts** based on project type:
|
|
29
|
+
|
|
30
|
+
### For Tauri Projects (Windows)
|
|
31
|
+
- **Dev**: `npm run tauri dev` - Assign VS x64 environment
|
|
32
|
+
- **Build**: `npm run tauri build` - Assign VS x64 environment
|
|
33
|
+
- **Test Frontend**: `npm test`
|
|
34
|
+
- **Test Backend**: `cargo test` - Assign VS x64 environment
|
|
35
|
+
- **Lint**: `npm run lint && cargo clippy`
|
|
36
|
+
|
|
37
|
+
### For Tauri Projects (macOS/Linux)
|
|
38
|
+
- **Dev**: `npm run tauri dev`
|
|
39
|
+
- **Build**: `npm run tauri build`
|
|
40
|
+
- **Test**: `npm test && cargo test`
|
|
41
|
+
|
|
42
|
+
### For Node.js Projects
|
|
43
|
+
- **Dev**: `npm run dev` or `npm start`
|
|
44
|
+
- **Build**: `npm run build`
|
|
45
|
+
- **Test**: `npm test`
|
|
46
|
+
- **Lint**: `npm run lint`
|
|
47
|
+
|
|
48
|
+
### For Rust Projects
|
|
49
|
+
- **Build**: `cargo build` - Assign VS x64 env on Windows
|
|
50
|
+
- **Build Release**: `cargo build --release` - Assign VS x64 env on Windows
|
|
51
|
+
- **Test**: `cargo test`
|
|
52
|
+
- **Run**: `cargo run`
|
|
53
|
+
- **Check**: `cargo check && cargo clippy`
|
|
54
|
+
|
|
55
|
+
### For Python Projects
|
|
56
|
+
- **Run**: `python <detected entry point>` (looks for `main.py`, `app.py`, `manage.py`, etc.)
|
|
57
|
+
- **Dev (Watchdog)**: `watchmedo auto-restart --patterns="*.py" --recursive -- python <entry_point>` (auto-restart on file changes)
|
|
58
|
+
- **Test**: `pytest` or `python -m unittest discover`
|
|
59
|
+
- **Install Deps**: `pip install -r requirements.txt` or `pip install -e .`
|
|
60
|
+
- For comprehensive Python setup with framework detection (Django, Flask, FastAPI, Streamlit), venv activation, and watchdog dev scripts, suggest running `/setup-python`
|
|
61
|
+
|
|
62
|
+
5. **Use `mcp__quadcode__create_script`** for each script:
|
|
63
|
+
- name: Descriptive name
|
|
64
|
+
- command: The main command
|
|
65
|
+
- description: What it does
|
|
66
|
+
- setup_commands: Any prerequisite commands (optional, less needed with environments)
|
|
67
|
+
- env: Environment variables if needed (optional)
|
|
68
|
+
|
|
69
|
+
6. **Assign environments to scripts** using `mcp__quadcode__set_script_environment`:
|
|
70
|
+
- Rust/Tauri builds on Windows -> VS 2022 x64 environment
|
|
71
|
+
- This ensures vcvarsall.bat runs before builds
|
|
72
|
+
|
|
73
|
+
7. **Report created scripts** with usage instructions
|
|
74
|
+
|
|
75
|
+
## Override
|
|
76
|
+
|
|
77
|
+
If $ARGUMENTS specifies a project type, use that instead of auto-detection.
|
|
78
|
+
|
|
79
|
+
## Note on Environments
|
|
80
|
+
|
|
81
|
+
If no VS environments are detected, suggest running `/detect-environments` first.
|
|
82
|
+
This is especially important for Windows Rust/Tauri development.
|
|
@@ -0,0 +1,66 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: suggest-improvements
|
|
3
|
+
description: Analyze ideas and add verbiage suggestions for improvements - rewording for clarity, expanding vague ideas, or summarizing verbose ones. This is for TEXT improvements only, not implementation notes.
|
|
4
|
+
allowed-tools: mcp__quadcode__list_ideas, mcp__quadcode__add_suggestion, mcp__quadcode__get_idea
|
|
5
|
+
user-invocable: true
|
|
6
|
+
argument-hint: [type]
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# Suggest Improvements Skill
|
|
10
|
+
|
|
11
|
+
Analyze ideas and provide AI-powered suggestions to improve the **text/wording** of ideas.
|
|
12
|
+
|
|
13
|
+
## Important: Suggestions vs Notes
|
|
14
|
+
|
|
15
|
+
**This skill is for text/wording improvements only.**
|
|
16
|
+
- Suggestions = Better phrasing of the idea itself
|
|
17
|
+
- Notes = Implementation status, code references, observations
|
|
18
|
+
|
|
19
|
+
For implementation notes, use the `check-implemented` skill or `add_idea_note` directly.
|
|
20
|
+
|
|
21
|
+
## Suggestion Types
|
|
22
|
+
|
|
23
|
+
Use `mcp__quadcode__add_suggestion` with these types:
|
|
24
|
+
- `reword` - Clearer, more professional phrasing
|
|
25
|
+
- `expand` - Add detail to vague ideas
|
|
26
|
+
- `clarify` - Make ambiguous ideas more specific
|
|
27
|
+
- `summarize` - Condense verbose ideas
|
|
28
|
+
|
|
29
|
+
## Process
|
|
30
|
+
|
|
31
|
+
1. **Get all ideas** using `mcp__quadcode__list_ideas`
|
|
32
|
+
|
|
33
|
+
2. **Analyze each idea's text** for:
|
|
34
|
+
- **Vague ideas** (too short, unclear) -> suggest `expand` or `clarify`
|
|
35
|
+
- **Verbose ideas** (too long, rambling) -> suggest `summarize`
|
|
36
|
+
- **Casual tone** (slang, incomplete sentences) -> suggest `reword`
|
|
37
|
+
- **Clear ideas** -> skip or just note they're good
|
|
38
|
+
|
|
39
|
+
3. **Add suggestions** using `mcp__quadcode__add_suggestion`:
|
|
40
|
+
```
|
|
41
|
+
idea_id: [the idea's id]
|
|
42
|
+
suggestion_type: reword|expand|clarify|summarize
|
|
43
|
+
text: [your improved version of the idea text]
|
|
44
|
+
```
|
|
45
|
+
|
|
46
|
+
4. **Report summary**:
|
|
47
|
+
- Ideas analyzed
|
|
48
|
+
- Suggestions added by type
|
|
49
|
+
- Ideas that need no improvement
|
|
50
|
+
|
|
51
|
+
## Focus Mode
|
|
52
|
+
|
|
53
|
+
If $ARGUMENTS specifies a type, only add that type of suggestion:
|
|
54
|
+
- `/suggest-improvements reword` - Only rewording suggestions
|
|
55
|
+
- `/suggest-improvements expand` - Only expansion suggestions
|
|
56
|
+
- `/suggest-improvements clarify` - Only clarification suggestions
|
|
57
|
+
- `/suggest-improvements summarize` - Only summarization suggestions
|
|
58
|
+
|
|
59
|
+
## Quality Guidelines
|
|
60
|
+
|
|
61
|
+
- Preserve the original intent
|
|
62
|
+
- Make ideas actionable and specific
|
|
63
|
+
- Use professional but accessible language
|
|
64
|
+
- Keep expanded ideas concise (not over-detailed)
|
|
65
|
+
- Reference specific features/components when possible
|
|
66
|
+
- DO NOT add implementation status - that's what notes are for
|
|
@@ -0,0 +1,68 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: team-status
|
|
3
|
+
description: Show the status of active agent teams including members, progress, recent messages, and available work.
|
|
4
|
+
allowed-tools: mcp__quadcode__list_teams, mcp__quadcode__get_team, mcp__quadcode__get_team_progress, mcp__quadcode__get_team_messages, mcp__quadcode__get_team_unread_count, mcp__quadcode__get_available_plan_issues, mcp__quadcode__list_issues
|
|
5
|
+
user-invocable: true
|
|
6
|
+
argument-hint: [team ID or leave blank for all teams]
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# Team Status Skill
|
|
10
|
+
|
|
11
|
+
Display a comprehensive status overview for active agent teams.
|
|
12
|
+
|
|
13
|
+
## Process
|
|
14
|
+
|
|
15
|
+
1. **List teams**:
|
|
16
|
+
- If $ARGUMENTS is provided, treat it as a team ID and fetch with `mcp__quadcode__get_team`
|
|
17
|
+
- If no argument, list all teams with `mcp__quadcode__list_teams`
|
|
18
|
+
- Show active teams first, then completed/cancelled
|
|
19
|
+
|
|
20
|
+
2. **For each active team, show**:
|
|
21
|
+
- Team name, status, and creation time
|
|
22
|
+
- Member list with roles, statuses, and current assignments
|
|
23
|
+
- Progress stats from `mcp__quadcode__get_team_progress`
|
|
24
|
+
- Unread message count from `mcp__quadcode__get_team_unread_count`
|
|
25
|
+
|
|
26
|
+
3. **Show recent activity**:
|
|
27
|
+
- Get latest messages with `mcp__quadcode__get_team_messages`
|
|
28
|
+
- Display last 10 messages with sender, type, and content
|
|
29
|
+
- Highlight blockers and completion messages
|
|
30
|
+
|
|
31
|
+
4. **Show available work**:
|
|
32
|
+
- If team has a linked plan, call `mcp__quadcode__get_available_plan_issues`
|
|
33
|
+
- List issues that are unblocked and unassigned
|
|
34
|
+
- Suggest which idle teammates could pick them up
|
|
35
|
+
|
|
36
|
+
5. **Health check**:
|
|
37
|
+
- Flag teammates that may be stale (no heartbeat)
|
|
38
|
+
- Flag any blocked issues
|
|
39
|
+
- Suggest actions: resume stale agents, reassign work, etc.
|
|
40
|
+
|
|
41
|
+
## Output Format
|
|
42
|
+
|
|
43
|
+
Present as a structured dashboard:
|
|
44
|
+
```
|
|
45
|
+
Team: {name} [{status}]
|
|
46
|
+
Progress: {completed}/{total} issues ({percent}%)
|
|
47
|
+
Members: {active}/{total} active
|
|
48
|
+
|
|
49
|
+
Members:
|
|
50
|
+
Lead: {name} - {status} - Working on #{issue}
|
|
51
|
+
Worker1: {name} - idle
|
|
52
|
+
Worker2: {name} - working - #{issue}
|
|
53
|
+
|
|
54
|
+
Recent Activity:
|
|
55
|
+
[completion] Worker1: Finished implementing auth module
|
|
56
|
+
[status_update] Worker2: Starting work on #5
|
|
57
|
+
[blocker] Worker1: Need API docs for integration
|
|
58
|
+
|
|
59
|
+
Available Work: {count} issues ready
|
|
60
|
+
#6 - Implement search feature (todo)
|
|
61
|
+
#8 - Add unit tests (todo)
|
|
62
|
+
```
|
|
63
|
+
|
|
64
|
+
## Guidelines
|
|
65
|
+
|
|
66
|
+
- Show a clear summary, not raw data
|
|
67
|
+
- Highlight issues that need attention (stale agents, blockers)
|
|
68
|
+
- Suggest concrete next actions
|
|
@@ -0,0 +1,51 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: triage-issues
|
|
3
|
+
description: Help prioritize and triage issues - set priorities, update statuses, identify blockers, and prepare issues for work.
|
|
4
|
+
allowed-tools: mcp__quadcode__list_issues, mcp__quadcode__get_issue, mcp__quadcode__update_issue, mcp__quadcode__add_issue_label, mcp__quadcode__add_issue_comment, mcp__quadcode__close_issue, mcp__quadcode__list_issues_filtered, Read
|
|
5
|
+
user-invocable: true
|
|
6
|
+
argument-hint: [filter]
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# Triage Issues Skill
|
|
10
|
+
|
|
11
|
+
You are tasked with triaging issues in QuadCode - helping prioritize work, identify blockers, and prepare issues for implementation.
|
|
12
|
+
|
|
13
|
+
## Process
|
|
14
|
+
|
|
15
|
+
1. **Get all issues** using `mcp__quadcode__list_issues` or apply filter if provided
|
|
16
|
+
|
|
17
|
+
2. **Triage each open issue** by evaluating:
|
|
18
|
+
|
|
19
|
+
**Priority Assessment:**
|
|
20
|
+
- Is this blocking other work? → `critical`
|
|
21
|
+
- Does this affect core functionality? → `high`
|
|
22
|
+
- Is this a standard improvement? → `medium`
|
|
23
|
+
- Is this minor or cosmetic? → `low`
|
|
24
|
+
|
|
25
|
+
**Status Assessment:**
|
|
26
|
+
- Is this ready to work on? → `todo`
|
|
27
|
+
- Is it waiting on something? → `blocked` (add comment explaining what)
|
|
28
|
+
- Should it wait? → `backlog`
|
|
29
|
+
- Is it being worked on? → `in_progress`
|
|
30
|
+
|
|
31
|
+
3. **For blocked issues:**
|
|
32
|
+
- Add a comment explaining the blocker
|
|
33
|
+
- Consider if there are related issues that need to be done first
|
|
34
|
+
|
|
35
|
+
4. **Identify quick wins:**
|
|
36
|
+
- Issues that are low effort but high value
|
|
37
|
+
- Mark these with a `quick-win` label
|
|
38
|
+
|
|
39
|
+
5. **Report triage summary:**
|
|
40
|
+
- Issues ready for work (todo, prioritized)
|
|
41
|
+
- Blocked issues and their blockers
|
|
42
|
+
- Recommended next issue to tackle
|
|
43
|
+
- Any issues that could be closed (duplicates, won't fix)
|
|
44
|
+
|
|
45
|
+
## Optional Filter
|
|
46
|
+
|
|
47
|
+
If a filter is provided ($ARGUMENTS):
|
|
48
|
+
- `critical` - Only triage critical priority issues
|
|
49
|
+
- `blocked` - Focus on unblocking blocked issues
|
|
50
|
+
- `backlog` - Review backlog for promotion to todo
|
|
51
|
+
- `stale` - Find issues that haven't been updated recently
|
|
@@ -0,0 +1,102 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: update-plan-progress
|
|
3
|
+
description: Review work done and update plan step statuses accordingly
|
|
4
|
+
allowed-tools: mcp__quadcode__list_plans, mcp__quadcode__get_plan, mcp__quadcode__update_plan, mcp__quadcode__update_plan_step, Read, Glob, Grep
|
|
5
|
+
user-invocable: true
|
|
6
|
+
argument-hint: <plan-id or plan-title>
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# Update Plan Progress Skill
|
|
10
|
+
|
|
11
|
+
Review completed work and update plan step statuses to reflect actual progress.
|
|
12
|
+
|
|
13
|
+
## Process
|
|
14
|
+
|
|
15
|
+
1. **Find the plan**:
|
|
16
|
+
- If $ARGUMENTS provided, search for matching plan
|
|
17
|
+
- Otherwise list plans and ask user to select
|
|
18
|
+
- Fetch full plan details with steps
|
|
19
|
+
|
|
20
|
+
2. **For each pending/in_progress step**:
|
|
21
|
+
|
|
22
|
+
a. **Analyze what the step requires**:
|
|
23
|
+
- Parse the step title and description
|
|
24
|
+
- Check for **acceptance_criteria** - these define what "done" means
|
|
25
|
+
- Check for **target_files** - these tell you exactly which files to look at
|
|
26
|
+
- Identify files, features, or changes involved
|
|
27
|
+
|
|
28
|
+
b. **Check if work is done using verification strategy**:
|
|
29
|
+
If the step has a **verification_strategy**, use it as the primary check:
|
|
30
|
+
- `build`: Run the build command (if specified) or check for build artifacts
|
|
31
|
+
- `test`: Run the test command (if specified) or check for passing tests
|
|
32
|
+
- `grep_check`: Use `Grep` with the specified pattern to verify code exists
|
|
33
|
+
- `file_exists`: Use `Glob` to verify the specified files exist
|
|
34
|
+
- `manual_review`: Use `Read` to review the relevant files and assess
|
|
35
|
+
|
|
36
|
+
If no verification_strategy, fall back to general checks:
|
|
37
|
+
- Use `Glob` to find relevant files
|
|
38
|
+
- Use `Read` to verify implementation
|
|
39
|
+
- Use `Grep` to search for specific code patterns
|
|
40
|
+
|
|
41
|
+
c. **Check acceptance criteria**:
|
|
42
|
+
If the step has **acceptance_criteria**, verify each criterion:
|
|
43
|
+
- For each criterion, determine if it has been met
|
|
44
|
+
- A step is only `completed` if ALL criteria are satisfied
|
|
45
|
+
- Note which criteria are met and which are not in the step notes
|
|
46
|
+
|
|
47
|
+
d. **Check dependencies**:
|
|
48
|
+
If the step has **dependencies**, verify that all dependency steps are completed
|
|
49
|
+
before marking this step as anything other than `pending`
|
|
50
|
+
|
|
51
|
+
e. **Determine new status**:
|
|
52
|
+
- `completed` - Work is fully done, all acceptance criteria met, verification passes
|
|
53
|
+
- `in_progress` - Work is partially done (some criteria met, some not)
|
|
54
|
+
- `pending` - Work has not started or dependencies not yet met
|
|
55
|
+
- `skipped` - Step is no longer needed
|
|
56
|
+
|
|
57
|
+
3. **Update steps**:
|
|
58
|
+
Use `mcp__quadcode__update_plan_step` for each step that needs updating
|
|
59
|
+
- Update status
|
|
60
|
+
- Add notes about what was found/verified
|
|
61
|
+
- Include which acceptance criteria passed/failed if applicable
|
|
62
|
+
|
|
63
|
+
4. **Update plan status** if needed:
|
|
64
|
+
- All steps done → `completed`
|
|
65
|
+
- Some steps in progress → `in_progress`
|
|
66
|
+
- Plan approved but work started → `in_progress`
|
|
67
|
+
|
|
68
|
+
5. **Generate report**:
|
|
69
|
+
- Steps updated (with step types and effort levels if available)
|
|
70
|
+
- Current progress percentage
|
|
71
|
+
- Acceptance criteria summary (X of Y met per step)
|
|
72
|
+
- Remaining work summary grouped by step type
|
|
73
|
+
- Recommendations for next steps (considering dependencies)
|
|
74
|
+
|
|
75
|
+
## Verification Strategies
|
|
76
|
+
|
|
77
|
+
### Using enriched step data (preferred)
|
|
78
|
+
|
|
79
|
+
When steps have enrichment fields, use them for precise verification:
|
|
80
|
+
|
|
81
|
+
- **verification_strategy.method = "grep_check"**: Use `Grep` with `verification_strategy.pattern`
|
|
82
|
+
- **verification_strategy.method = "file_exists"**: Use `Glob` to check `target_files`
|
|
83
|
+
- **verification_strategy.method = "build"**: Run `verification_strategy.command` if specified
|
|
84
|
+
- **verification_strategy.method = "test"**: Run `verification_strategy.command` if specified
|
|
85
|
+
- **verification_strategy.method = "manual_review"**: Read `target_files` and check `acceptance_criteria`
|
|
86
|
+
- **code_context**: Use this to understand what patterns/functions to look for
|
|
87
|
+
|
|
88
|
+
### Fallback strategies (when no enrichment data)
|
|
89
|
+
|
|
90
|
+
For code implementation steps:
|
|
91
|
+
- Check if relevant files exist
|
|
92
|
+
- Verify functions/classes are defined
|
|
93
|
+
- Look for TODO comments indicating incomplete work
|
|
94
|
+
|
|
95
|
+
For testing steps:
|
|
96
|
+
- Check if test files exist
|
|
97
|
+
- Look for test functions
|
|
98
|
+
- Check for passing test indicators
|
|
99
|
+
|
|
100
|
+
For documentation steps:
|
|
101
|
+
- Check if docs exist
|
|
102
|
+
- Verify content is present
|