feat: v3.0.0 architecture overhaul
- Rename marketplace to lm-claude-plugins - Move MCP servers to root with symlinks - Add 6 PR tools to Gitea MCP (list_pull_requests, get_pull_request, get_pr_diff, get_pr_comments, create_pr_review, add_pr_comment) - Add clarity-assist plugin (prompt optimization with ND accommodations) - Add git-flow plugin (workflow automation) - Add pr-review plugin (multi-agent review with confidence scoring) - Centralize configuration docs - Update all documentation for v3.0.0 BREAKING CHANGE: MCP server paths changed, marketplace renamed Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
137
plugins/clarity-assist/commands/clarify.md
Normal file
137
plugins/clarity-assist/commands/clarify.md
Normal file
@@ -0,0 +1,137 @@
|
||||
# /clarify - Full Prompt Optimization
|
||||
|
||||
## Purpose
|
||||
|
||||
Transform vague, incomplete, or ambiguous requests into clear, actionable specifications using the 4-D methodology with neurodivergent-friendly accommodations.
|
||||
|
||||
## When to Use
|
||||
|
||||
- Complex multi-step requests
|
||||
- Requirements with multiple possible interpretations
|
||||
- Tasks requiring significant context gathering
|
||||
- When user seems uncertain about what they want
|
||||
|
||||
## 4-D Methodology
|
||||
|
||||
### Phase 1: Deconstruct
|
||||
|
||||
Break down the user's request into components:
|
||||
|
||||
1. **Extract explicit requirements** - What was directly stated
|
||||
2. **Identify implicit assumptions** - What seems assumed but not stated
|
||||
3. **Note ambiguities** - Points that could go multiple ways
|
||||
4. **List dependencies** - External factors that might affect implementation
|
||||
|
||||
### Phase 2: Diagnose
|
||||
|
||||
Analyze gaps and potential issues:
|
||||
|
||||
1. **Missing information** - What do we need to know?
|
||||
2. **Conflicting requirements** - Do any stated goals contradict?
|
||||
3. **Scope boundaries** - What's in/out of scope?
|
||||
4. **Technical constraints** - Platform, language, architecture limits
|
||||
|
||||
### Phase 3: Develop
|
||||
|
||||
Gather clarifications through structured questioning:
|
||||
|
||||
**ND-Friendly Question Rules:**
|
||||
- Present 2-4 concrete options (never open-ended alone)
|
||||
- Include "Other" for custom responses
|
||||
- Ask 1-2 questions at a time maximum
|
||||
- Provide brief context for why you're asking
|
||||
- Check for conflicts with previous answers
|
||||
|
||||
**Example Format:**
|
||||
```
|
||||
To help me understand the scope better:
|
||||
|
||||
**How should errors be handled?**
|
||||
1. Silent logging (user sees nothing)
|
||||
2. Toast notifications (brief, dismissible)
|
||||
3. Modal dialogs (requires user action)
|
||||
4. Other
|
||||
|
||||
[Context: This affects both UX and how much error-handling code we need]
|
||||
```
|
||||
|
||||
### Phase 4: Deliver
|
||||
|
||||
Produce the refined specification:
|
||||
|
||||
```markdown
|
||||
## Clarified Request
|
||||
|
||||
### Summary
|
||||
[1-2 sentence description of what will be built]
|
||||
|
||||
### Scope
|
||||
**In Scope:**
|
||||
- [Item 1]
|
||||
- [Item 2]
|
||||
|
||||
**Out of Scope:**
|
||||
- [Item 1]
|
||||
|
||||
### Requirements
|
||||
|
||||
| # | Requirement | Priority | Notes |
|
||||
|---|-------------|----------|-------|
|
||||
| 1 | ... | Must | ... |
|
||||
| 2 | ... | Should | ... |
|
||||
|
||||
### Assumptions
|
||||
- [Assumption made based on conversation]
|
||||
|
||||
### Open Questions
|
||||
- [Any remaining ambiguities, if any]
|
||||
```
|
||||
|
||||
## Conflict Detection
|
||||
|
||||
Before each question, review previous answers for conflicts:
|
||||
|
||||
```
|
||||
[Internal check]
|
||||
Previous: User said "keep it simple"
|
||||
Current question about: Adding configuration options
|
||||
Potential conflict: More options = more complexity
|
||||
→ Acknowledge: "Earlier you mentioned keeping it simple. With that in mind..."
|
||||
```
|
||||
|
||||
## Escalation Protocol
|
||||
|
||||
If the request is particularly messy or the user seems overwhelmed:
|
||||
|
||||
1. Acknowledge the complexity
|
||||
2. Offer to start with just ONE aspect
|
||||
3. Build incrementally
|
||||
|
||||
```
|
||||
"This touches a lot of areas. Rather than tackle everything at once,
|
||||
let's start with [most critical piece]. Once that's clear, we can
|
||||
add the other parts. Sound good?"
|
||||
```
|
||||
|
||||
## Example Interaction
|
||||
|
||||
**User:** Make the app faster
|
||||
|
||||
**Clarify Response:**
|
||||
|
||||
```
|
||||
Let me help clarify what kind of performance improvements you're looking for.
|
||||
|
||||
**What type of slowness are you experiencing?**
|
||||
1. Initial page load takes too long
|
||||
2. Interactions feel sluggish (clicking, typing)
|
||||
3. API calls are slow
|
||||
4. All of the above
|
||||
5. Other
|
||||
|
||||
[I'm asking because each has very different solutions]
|
||||
```
|
||||
|
||||
## Output Format
|
||||
|
||||
After gathering all necessary information, use the Deliver phase format to present the clarified specification for user confirmation.
|
||||
84
plugins/clarity-assist/commands/quick-clarify.md
Normal file
84
plugins/clarity-assist/commands/quick-clarify.md
Normal file
@@ -0,0 +1,84 @@
|
||||
# /quick-clarify - Rapid Clarification Mode
|
||||
|
||||
## Purpose
|
||||
|
||||
Single-pass clarification for requests that are mostly clear but need minor disambiguation.
|
||||
|
||||
## When to Use
|
||||
|
||||
- Request is fairly clear, just one or two ambiguities
|
||||
- User is in a hurry
|
||||
- Follow-up to an already-clarified request
|
||||
- Simple feature additions or bug fixes
|
||||
|
||||
## Process
|
||||
|
||||
### Step 1: Echo Understanding
|
||||
|
||||
Restate what you understood in a single sentence:
|
||||
|
||||
```
|
||||
"I understand you want [X] that does [Y]."
|
||||
```
|
||||
|
||||
### Step 2: Quick Disambiguation
|
||||
|
||||
If needed, ask ONE multiple-choice question:
|
||||
|
||||
```
|
||||
**Just to confirm:** Should this [A] or [B]?
|
||||
1. [Option A with brief description]
|
||||
2. [Option B with brief description]
|
||||
3. Both
|
||||
4. Neither / Other approach
|
||||
```
|
||||
|
||||
### Step 3: Proceed or Confirm
|
||||
|
||||
If confident (>90%), proceed with a brief confirmation:
|
||||
|
||||
```
|
||||
"Got it. I'll implement [X with chosen option]. Starting now."
|
||||
```
|
||||
|
||||
If less confident, offer a micro-summary:
|
||||
|
||||
```
|
||||
"Quick summary before I start:
|
||||
- [Key point 1]
|
||||
- [Key point 2]
|
||||
- [Assumption made]
|
||||
|
||||
Proceed? (Or clarify anything)"
|
||||
```
|
||||
|
||||
## Example Interaction
|
||||
|
||||
**User:** Add a delete button to the user list
|
||||
|
||||
**Quick-Clarify Response:**
|
||||
|
||||
```
|
||||
I'll add a delete button to each row in the user list.
|
||||
|
||||
**Should deletion require confirmation?**
|
||||
1. Yes - show confirmation dialog (Recommended)
|
||||
2. No - delete immediately
|
||||
3. Soft delete - mark as deleted but keep data
|
||||
|
||||
[Asking because accidental deletions can be problematic]
|
||||
```
|
||||
|
||||
## Escalation to Full /clarify
|
||||
|
||||
If quick-clarify reveals complexity:
|
||||
|
||||
```
|
||||
"This is more involved than it first appeared - there are
|
||||
several decisions to make. Want me to switch to a more
|
||||
thorough clarification process? (Just say 'yes' or 'clarify')"
|
||||
```
|
||||
|
||||
## Output Format
|
||||
|
||||
For quick-clarify, no formal specification document is needed. Just proceed with the task after brief confirmation, documenting assumptions inline with the work.
|
||||
Reference in New Issue
Block a user