@cliangdev/flux-plugin 0.2.0-dev.dc5e2c4 → 0.2.0-dev.e8f7aab

package/commands/implement.md

@@ -53,8 +53,7 @@ The orchestrator resolves all refs to tasks, builds a dependency-ordered queue,
 
 ## Pre-checks
 
-1. Call `get_project_context` to ensure Flux is initialized
-2. Parse arguments and resolve to tasks:
+1. Parse arguments and resolve to tasks (if any tool returns `PROJECT_NOT_INITIALIZED` error, tell user: "Run `/flux` first to initialize the project." and exit):
    - No args: Query for next PENDING task with no blockers
    - PRD ref(s): Expand to all epics → all tasks
    - Epic ref(s): Expand to all tasks
@@ -62,8 +61,100 @@ The orchestrator resolves all refs to tasks, builds a dependency-ordered queue,
    - Mixed refs: Resolve each, deduplicate, merge
    - `tag:{name}`: Query PRDs by tag → expand all
 
+2. Git state check (REQUIRED before any implementation):
+   - Run `git status` to check for uncommitted changes
+   - If dirty working tree: Ask user whether to commit, stash, or abort
+   - Never proceed with uncommitted changes
+
 ## Workflow
 
+### Step 0: Git Branch Setup
+
+**Always start from latest main with a fresh branch.** This ensures clean PRs and avoids merge conflicts.
+
+#### 0.1 Ensure Clean State
+
+```bash
+# Check for uncommitted changes
+git status --porcelain
+```
+
+If output is non-empty, use AskUserQuestion:
+```json
+{
+  "questions": [{
+    "question": "You have uncommitted changes. How would you like to proceed?",
+    "header": "Git Status",
+    "options": [
+      {"label": "Commit them first", "description": "Stage and commit current changes before starting"},
+      {"label": "Stash them", "description": "Stash changes temporarily, restore after implementation"},
+      {"label": "Abort implementation", "description": "Stop here and handle changes manually"}
+    ],
+    "multiSelect": false
+  }]
+}
+```
+
+#### 0.2 Create Feature Branch from Latest Main
+
+```bash
+# Fetch latest and create branch
+git fetch origin main
+git checkout -b {branch-name} origin/main
+```
+
+#### 0.3 Branch Naming Convention
+
+| Scope | Branch Name | Example |
+|-------|-------------|---------|
+| `tag:xxx` | `feat/tag-{tag}` | `feat/tag-phase-3` |
+| Single PRD | `feat/{prd-ref}` | `feat/FLUX-P3` |
+| Multiple PRDs | `feat/{first-prd-ref}` | `feat/FLUX-P3` |
+| Single Epic | `feat/{epic-ref}` | `feat/FLUX-E14` |
+| Multiple Epics | `feat/{first-epic-ref}` | `feat/FLUX-E14` |
+| Single Task | `feat/{task-ref}` | `feat/FLUX-T31` |
+| Multiple Tasks | `feat/{first-task-ref}` | `feat/FLUX-T31` |
+| No args (next task) | `feat/{task-ref}` | `feat/FLUX-T42` |
+| Mixed refs | `feat/{highest-level-ref}` | `feat/FLUX-P3` (PRD > Epic > Task) |
+
+**Priority for mixed refs**: Use the highest-level entity (PRD > Epic > Task). If multiple of the same level, use the first one alphabetically.
+
+#### 0.4 Handle Existing Branch
+
+If the branch already exists:
+```bash
+# Check if branch exists
+git rev-parse --verify feat/FLUX-P3 2>/dev/null
+```
+
+If branch exists, use AskUserQuestion:
+```json
+{
+  "questions": [{
+    "question": "Branch 'feat/FLUX-P3' already exists. What would you like to do?",
+    "header": "Branch",
+    "options": [
+      {"label": "Continue on existing (Recommended)", "description": "Resume work on the existing branch"},
+      {"label": "Delete and recreate", "description": "Start fresh from latest main"},
+      {"label": "Use different name", "description": "Create a new branch with a different name"}
+    ],
+    "multiSelect": false
+  }]
+}
+```
+
+#### Example Output
+
+```
+Git Setup:
+✓ Working tree clean
+✓ Fetched origin/main
+✓ Created branch: feat/tag-phase-3
+  └── Based on: origin/main (abc1234)
+
+Ready to implement 3 PRDs (tag: phase-3)
+```
+
 ### Step 1: Gather Context
 
 Resolve all refs to a unified task list:
@@ -185,31 +276,87 @@ When spawning a coding subagent, provide this context:
 - Epic: {epic.ref} - {epic.title}
 - PRD: {prd.ref} (read if more context needed)
 
+## Project Skill (APPLY THESE PATTERNS)
+{skillContent || "No project-specific skill found. Use general best practices for this language."}
+
 ## Workflow
-1. Auto-detect project type and apply matching skill
+1. Apply the project skill patterns above (if provided)
 2. Write tests for each [auto] criterion FIRST
-3. Implement until all tests pass
-4. For [manual] criteria, document verification steps
-5. Commit with message: "{task.ref}: {brief description}"
-6. Report back: COMPLETED or BLOCKED (with reason)
+3. Write tests for critical components (business logic, data transformations, error paths)
+4. Implement until all tests pass
+5. For [manual] criteria, document verification steps
+6. Commit with message: "{task.ref}: {brief description}"
+7. Report back: COMPLETED or BLOCKED (with reason)
+
+## Code Quality Requirements
+- Write clean, modular, testable code
+- Small focused functions with clear separation of concerns
+- Inject dependencies for testability
+- NO unnecessary comments - let code be self-documenting
+- Comments only for non-obvious "why", never for "what"
+- No commented-out code
 
 ## Files to Focus On
 {relevantFiles}
 ```
 
-## Skill Auto-Detection
+**Note:** The orchestrator MUST discover and include skill content before spawning. See "Skill Discovery & Application" section above.
+
+## Skill Discovery & Application
+
+Before spawning a coding subagent, discover and load relevant project skills.
+
+### Step 1: Detect Project Type
+
+Check for project indicator files:
+
+```bash
+ls -la | head -20
+```
+
+| File Found | Project Type |
+|------------|--------------|
+| `go.mod` | Go |
+| `tsconfig.json` | TypeScript |
+| `pom.xml` / `build.gradle` | Java/Spring |
+| `package.json` + react | React |
+| `Cargo.toml` | Rust |
+| `requirements.txt` / `pyproject.toml` | Python |
+
+### Step 2: Search for Matching Skills
+
+Check `.claude/skills/` for project-specific skills:
+
+```bash
+# List available skills
+ls .claude/skills/ 2>/dev/null || echo "No skills directory"
+```
+
+**Skill matching patterns:**
+
+| Project Type | Skill Search Patterns |
+|--------------|----------------------|
+| Go | `golang*`, `go-*`, `go_*` |
+| TypeScript | `typescript*`, `ts-*`, `ts_*` |
+| Java/Spring | `java*`, `spring*`, `springboot*` |
+| React | `react*`, `ui-*`, `frontend*` |
+| Rust | `rust*` |
+| Python | `python*`, `py-*` |
+
+### Step 3: Load Skill Content
+
+If a matching skill is found, read its content:
+
+```bash
+# Read skill content
+cat .claude/skills/{skill-name}/SKILL.md
+```
 
-The coding subagent detects project type and applies matching skills:
+### Step 4: Pass Skill to Subagent
 
-| Detection | Skill | Patterns Applied |
-|-----------|-------|------------------|
-| `pom.xml` | `springboot-patterns` | DDD, transactions, Java style |
-| `tsconfig.json` | `typescript-patterns` | Async/await, typed errors |
-| `package.json` + React | `ui-patterns` | Components, Tailwind, dark mode |
-| `go.mod` | Go patterns | Error handling, interfaces |
-| `Cargo.toml` | Rust patterns | Result types, ownership |
+Include the skill content in the coding subagent prompt (see template below).
 
-Detection happens at subagent spawn time by checking project root files.
+**Important:** If no matching skill is found, the subagent falls back to general best practices for that language.
 
 ## Status Management
 
@@ -313,3 +460,5 @@ Action needed: Resolve blockers, then run `/flux:implement FP-T45`
 - **Fail fast**: Report blockers immediately
 - **One commit per task**: Keep history clean
 - **TDD always**: Tests before implementation
+- **Test critical components**: Not just acceptance criteria - test business logic, transformations, error paths
+- **Clean code**: Modular, testable, self-documenting - no unnecessary comments

package/commands/linear.md

@@ -21,13 +21,14 @@ The `configure_linear` tool supports progressive discovery:
 
 ## Flow
 
-### Step 1: Verify Project
+### Step 1: Verify Project & Fetch Teams
 
-Call `get_project_context`.
+Call `configure_linear` with `{interactive: true}`.
 
-- If `initialized: false` → Tell user to run `/flux` first, then exit.
-- If `adapter.type === "linear"` and config exists → Already configured, show info and exit.
-- Otherwise → Continue to Step 2.
+- If error with `code: "PROJECT_NOT_INITIALIZED"` → Tell user to run `/flux` first, then exit.
+- If error about Linear API key → Show instructions (see Step 2 error handling).
+- If success with `step: "already_configured"` → Already configured, show info and exit.
+- Otherwise → Continue with team selection (response contains teams list).
 
 ### Step 2: Fetch Teams