+++ /dev/null
-Help the user draft a well-structured issue for their project's
-issue tracker.
-
-## Process
-
-1. Ask the user to describe what they want in their own words.
-2. Ask clarifying questions (one at a time) to understand:
- - What is the problem or desired outcome?
- - What is the current behavior vs expected behavior?
- - Are there constraints or preferences?
-3. Draft a structured issue with:
- - Title: `type(scope): concise description`
- - Body:
- - **Context**: why this is needed (1-2 sentences)
- - **Goal**: what should change (concrete, testable)
- - **Acceptance criteria**: how to verify it's done
- - **Constraints** (if any): what NOT to do, what to preserve
-4. Present the draft to the user for review.
-5. If the user approves, submit using whatever tool is available
- (gh, glab, MCP), or output the formatted text for manual submission.
-
-## Principles
-
-- Intent-driven: describe WHAT and WHY, not HOW to implement.
-- Give implementation space: do not over-specify the approach.
-- One issue = one change. If the idea is too big, suggest splitting
- into multiple issues.
-- Include acceptance criteria so the implementer knows when it's done.
+++ /dev/null
-You are handling an issue from the project's issue tracker.
-Follow this SOP strictly.
-
-## Step 1: Understand
-
-- Fetch the issue content (title, body, labels, comments).
- Use whatever tool is available (gh, glab, MCP, or ask the user to provide).
-- Read the project's CLAUDE.md and understand the codebase structure.
-- Identify the scope: what files are likely affected, what tests exist.
-
-## Step 2: Assess Complexity
-
-Before writing any code, assess:
-- Is the issue clear enough to implement? If not, ask the user for clarification.
-- Are there multiple valid approaches? If yes, present them with trade-offs
- and let the user choose. Do NOT pick one silently.
-- Is this too large for a single context? If yes, suggest splitting into
- smaller issues before starting.
-
-## Step 3: Branch and Implement
-
-- Create a feature branch: `<type>/issue-<number>-<short-description>`
-- Implement the change following existing codebase patterns.
-- Write tests for the change (unless pure documentation).
-- Make small, focused commits using Conventional Commits format.
-
-## Step 4: Validate
-
-Before submitting:
-- All existing tests still pass.
-- New tests cover the changes.
-- Changes are limited to issue scope.
-- No unnecessary refactoring or additions.
-
-## Step 5: Submit
-
-- Push the branch and create a merge/pull request linking the issue.
-- Title: concise summary. Body: what changed and why.
-
-## Escape Hatch
-
-If at any point:
-- The issue is unclear → ask the user, do not guess.
-- The implementation risk is too high → explain the risk and stop.
-- The scope is larger than expected → suggest splitting into multiple issues.
+++ /dev/null
-Analyze the current project and generate a health report. Then guide
-the user through setting up CLAUDE.md if one doesn't exist.
-
-## Step 1: Project Analysis
-
-Scan the project root and report findings for each quality dimension.
-Do not assume any specific language or toolchain.
-
-### Build System
-Detect build files: CMakeLists.txt, Makefile, meson.build, package.json,
-pyproject.toml, setup.py, Cargo.toml, go.mod, build.gradle, pom.xml,
-or other build configuration.
-Report what was found, or note "no build system detected".
-
-### Testing
-Detect test directories: tests/, test/, __tests__/, spec/, or test
-files matching common patterns (*_test.*, test_*.*, *.spec.*, *_spec.*).
-Detect test runner config: pytest.ini, jest.config.*, .mocharc.*,
-CTestTestfile.cmake, Catch2/GoogleTest headers, etc.
-Report what was found.
-
-### Code Quality Tools
-Detect formatter/linter config: .clang-format, .clang-tidy, .eslintrc*,
-.prettierrc*, pyproject.toml [tool.ruff/black/flake8], rustfmt.toml,
-.editorconfig, .golangci.yml, or similar.
-Detect git hooks: .pre-commit-config.yaml, .husky/, .githooks/.
-Report what was found.
-
-### CI/CD
-Detect: .github/workflows/, .gitlab-ci.yml, Jenkinsfile, .circleci/,
-.travis.yml, bitbucket-pipelines.yml, or similar.
-Report what was found.
-
-### Documentation
-Check: README.md and CLAUDE.md existence. If they exist, note whether
-they have meaningful content beyond just a title.
-
-## Step 2: Report
-
-Present findings as a concise checklist:
-
-```
-Project Health Report: <project-name>
- Build system: ✓ CMake (CMakeLists.txt)
- Tests: ✓ tests/ directory, GoogleTest
- Code quality: ✓ .clang-format, .clang-tidy, pre-commit
- CI/CD: ✗ No CI configuration found
- README: ✓ Exists with content
- CLAUDE.md: ✗ Missing
-```
-
-For each ✗ item, provide a brief, actionable suggestion.
-Do NOT mandate specific tools — suggest based on what fits the project.
-
-## Step 3: CLAUDE.md Creation (if missing or inadequate)
-
-If CLAUDE.md doesn't exist or is just a placeholder, guide the user:
-
-1. Ask about the project's purpose (one sentence).
-2. Document detected build/test commands.
-3. Ask about key code conventions or architectural constraints.
-4. Generate a minimal CLAUDE.md (under 50 lines) following this structure:
-
-```markdown
-# <Project Name>
-
-<One-sentence project description.>
-
-## Quick Reference
-
-\```bash
-# Build
-<build command>
-
-# Test
-<test command>
-\```
-
-## Code Conventions
-
-- <Convention 1>
-- <Convention 2>
-
-## Constraints
-
-- <Things Claude should NOT do>
-- <Protected files/directories>
-- <Dependency rules>
-```
-
-Do NOT over-generate. A 20-line CLAUDE.md with accurate info is better
-than a 100-line one with guesses.
-
-## Step 4: Hooks Suggestion (optional)
-
-If a code formatter is detected, suggest a PostToolUse hook configuration
-that auto-formats after edits. Present the suggestion and let the user
-decide whether to add it to `.claude/settings.local.json`.
ln -sf "$SCRIPT_DIR/claude/CLAUDE.md" "$CLAUDE_DIR/CLAUDE.md"
echo " ✓ CLAUDE.md"
-# Symlink commands
-mkdir -p "$CLAUDE_DIR/commands"
-for cmd in "$SCRIPT_DIR"/claude/commands/xdev-*.md; do
- [ -f "$cmd" ] || continue
- ln -sf "$cmd" "$CLAUDE_DIR/commands/$(basename "$cmd")"
- echo " ✓ commands/$(basename "$cmd")"
-done
+# Install xdev plugin from devloop marketplace
+# Plugin includes: skills (xdev-implement, xdev-draft, xdev-setup)
+# hooks (commit validation, sensitive file protection)
+echo ""
+echo "Installing xdev plugin..."
+if command -v claude &>/dev/null; then
+ claude plugin marketplace add XinqiBao/devloop 2>/dev/null || true
+ claude plugin install xdev@devloop 2>/dev/null || true
+ echo " ✓ xdev@devloop plugin (skills + hooks)"
+else
+ echo " ⚠ claude CLI not found, skipping plugin install"
+fi
+echo ""
echo "Done. Claude Code xdev workflow installed."