[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CYBEW8DDBXW62Q2CA29BPR":3,"skill-same:01M6CYBEW8DDBXW62Q2CA29BPR":50},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":25,"linkOnly":26,"markdownContent":27,"markdownBody":28,"frontMatter":29,"refName":30,"commitSha":31,"skillDirectory":32,"forksCount":13,"repositoryHtmlUrl":33,"repositoryHomepageUrl":6,"ownerHtmlUrl":34,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":35,"install":36,"resources":49},"01M6CYBEW8DDBXW62Q2CA29BPR","workflows-plan",null,"Transform feature descriptions into well-structured project plans following conventions","The-Rabak\u002Fnaysmith","The-Rabak","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F44833742?v=4","01M6CY211HB58Y8JNWWEV9FGN1","01M6CY8HJW3TE1AQW1F13PHYB2",0,"GPL-2.0","https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fnaysmith\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fworkflows-plan\u002FSKILL.md",[],[18,19,20,21,22,23,24],"workflows","plan","workflows plan","conventions","following conventions","structured","project","2026-11-10 10:12:30",false,"---\nname: workflows-plan\ndescription: Transform feature descriptions into well-structured project plans following conventions\n---\n\n## Arguments\n[feature description, bug report, or improvement idea]\n\n# Create a plan for a new feature or bug fix\n\n## Introduction\n\n**Note: The current year is 2026.** Use this when dating plans and searching for recent documentation.\n\nTransform feature descriptions, bug reports, or improvement ideas into well-structured markdown files issues that follow project conventions and best practices. This command provides flexible detail levels to match your needs.\n\n## Feature Description\n\n\u003Cfeature_description> #$ARGUMENTS \u003C\u002Ffeature_description>\n\n**If the feature description above is empty, ask the user:** \"What would you like to plan? Please describe the feature, bug fix, or improvement you have in mind.\"\n\nDo not proceed until you have a clear feature description from the user.\n\n### 0. Idea Refinement\n\n**Check if arguments contain a plan or spec file:**\n\nIf the feature description (`#$ARGUMENTS`) is or contains a path to a `.md` file (e.g., `docs\u002Fplans\u002Fsome-plan.md`, `spec.md`, `~\u002Fnotes\u002Ffeature-plan.md`):\n\n1. Read the file\n2. Announce: \"Found existing plan\u002Fspec: `[file path]`. Using as foundation.\"\n3. Extract: title, problem statement, proposed approach, acceptance criteria, implementation phases, and any existing tasks\n4. **Skip idea refinement questions** — the plan already defines WHAT to build\n5. **Skip brainstorm check** — an explicit plan supersedes brainstorm discovery\n6. Proceed to Step 0.5 to gather any additional project inputs, then to research to validate and enrich the existing plan\n7. In Step 2 (Issue Planning), **build upon the existing plan structure** — preserve its sections, fill gaps, add execution-readiness fields (Files, Depends on, Success criteria, Test command) to any tasks that lack them, and enrich with research findings. Do NOT discard or rewrite sections that are already well-defined.\n\n**If arguments are NOT a file path, check for brainstorm output:**\n\nBefore asking questions, look for recent brainstorm documents in `docs\u002Fbrainstorms\u002F` that match this feature:\n\n```bash\nls -la docs\u002Fbrainstorms\u002F*.md 2>\u002Fdev\u002Fnull | head -10\n```\n\n**Relevance criteria:** A brainstorm is relevant if:\n- The topic (from filename or YAML frontmatter) semantically matches the feature description\n- Created within the last 14 days\n- If multiple candidates match, use the most recent one\n\n**If a relevant brainstorm exists:**\n1. Read the brainstorm document\n2. Announce: \"Found brainstorm from [date]: [topic]. Using as context for planning.\"\n3. Extract key decisions, chosen approach, and open questions\n4. **Skip the idea refinement questions below** - the brainstorm already answered WHAT to build\n5. Use brainstorm decisions as input to the research phase\n\n**If multiple brainstorms could match:**\nUse **AskUserQuestion tool** to ask which brainstorm to use, or whether to proceed without one.\n\n**If no brainstorm found (or not relevant), run idea refinement:**\n\nRefine the idea through collaborative dialogue using the **AskUserQuestion tool**:\n\n- Ask questions one at a time to understand the idea fully\n- Prefer multiple choice questions when natural options exist\n- Focus on understanding: purpose, constraints and success criteria\n- Continue until the idea is clear OR user says \"proceed\"\n\n**Gather signals for research decision.** During refinement, note:\n\n- **User's familiarity**: Do they know the codebase patterns? Are they pointing to examples?\n- **User's intent**: Speed vs thoroughness? Exploration vs execution?\n- **Topic risk**: Security, payments, external APIs warrant more caution\n- **Uncertainty level**: Is the approach clear or open-ended?\n\n**Skip option:** If the feature description is already detailed, offer:\n\"Your description is clear. Should I proceed with research, or would you like to refine it further?\"\n\n### 0.5 Gather Project Inputs\n\nUse the **AskUserQuestion tool** to collect structured project inputs. Ask these 4 questions in sequence:\n\n**Question 1:** \"Do you have any project management tickets related to this feature?\"\n- Options: `[\"None\", \"Enter URLs\"]`\n- If \"Enter URLs\": Ask user to paste ticket URLs (comma-separated)\n\n**Question 2:** \"Do you have any wiki or documentation pages related to this feature?\"\n- Options: `[\"None\", \"Enter URLs\"]`\n- If \"Enter URLs\": Ask user to paste documentation URLs (comma-separated)\n\n**Question 3:** \"Do you have any Figma designs related to this feature?\"\n- Options: `[\"None\", \"Enter URLs\"]`\n- If \"Enter URLs\": Ask user to paste Figma design URLs (comma-separated)\n\n**Question 4:** \"Do you have any existing plan, spec, or requirements documents (.md files) to build from?\"\n- Options: `[\"None\", \"Enter file paths\"]`\n- If \"Enter file paths\": Ask user to paste file paths (comma-separated, relative or absolute)\n\n**Processing inputs:**\n\nFor any non-empty inputs, launch **parallel subagents** to fetch and summarize each document:\n\n- Use the fetch-and-summarize skill to: ticket_urls → Extract ticket title, description, acceptance criteria, status\n- Use the fetch-and-summarize skill to: doc_urls → Extract key decisions, requirements, technical context\n- Use the fetch-and-summarize skill to: figma_urls → Extract design intent, component structure, interaction patterns\n- Use the read-and-extract skill to: plan_file_paths → Read each `.md` file, extract structure (title, problem statement, approach, tasks, acceptance criteria, open questions). Identify which sections are well-defined vs need enrichment.\n\n**Handle `MANUAL_INPUT_NEEDED`:** If a subagent cannot access a URL (authentication required, private resource), use the **AskUserQuestion tool** to ask: \"I couldn't access [URL]. Could you paste the relevant content from this document?\"\n\n**Consolidate into `project_context` block:**\n\n```markdown\n## Project Context (from structured inputs)\n\n### Project Tickets\n- [TICKET-123](url): Summary of ticket...\n\n### Documentation\n- [Doc Title](url): Key decisions and requirements...\n\n### Figma Designs\n- [Design Name](url): Design intent and component overview...\n\n### Existing Plans \u002F Specs\n- [filename.md](path): Structure summary, well-defined sections, gaps to fill...\n```\n\n**Store source URLs\u002Fpaths in plan frontmatter** under `source_docs:`:\n\n```yaml\nsource_docs:\n  tickets:\n    - https:\u002F\u002Ftracker.example.com\u002FTICKET-123\n  docs:\n    - https:\u002F\u002Fwiki.example.com\u002Fpages\u002Fdoc-id\n  figma:\n    - https:\u002F\u002Ffigma.com\u002Ffile\u002Fabc123\n  plans:\n    - docs\u002Fspecs\u002Fexisting-feature-spec.md\n```\n\nIf all three inputs are \"None\", skip this step and proceed.\n\n## Main Tasks\n\n### 1. Local Research (Always Runs - Parallel)\n\n\u003Cthinking>\nFirst, I need to understand the project's conventions, existing patterns, and any documented learnings. This is fast and local - it informs whether external research is needed.\n\u003C\u002Fthinking>\n\nRun these agents **in parallel** to gather local context:\n\n- Use the repo-research-analyst skill to: feature_description\n- Use the learnings-researcher skill to: feature_description\n\n**What to look for:**\n- **Repo research:** existing patterns, CLAUDE.md guidance, technology familiarity, pattern consistency\n- **Learnings:** documented solutions in `docs\u002Fsolutions\u002F` that might apply (gotchas, patterns, lessons learned)\n\nThese findings inform the next step.\n\n### 1.5. Research Decision\n\nBased on signals from Step 0 and findings from Step 1, decide on external research.\n\n**High-risk topics → always research.** Security, payments, external APIs, data privacy. The cost of missing something is too high. This takes precedence over speed signals.\n\n**Strong local context → skip external research.** Codebase has good patterns, CLAUDE.md has guidance, user knows what they want. External research adds little value.\n\n**Uncertainty or unfamiliar territory → research.** User is exploring, codebase has no examples, new technology. External perspective is valuable.\n\n**Announce the decision and proceed.** Brief explanation, then continue. User can redirect if needed.\n\nExamples:\n- \"Your codebase has solid patterns for this. Proceeding without external research.\"\n- \"This involves payment processing, so I'll research current best practices first.\"\n\n### 1.5b. External Research (Conditional)\n\n**Only run if Step 1.5 indicates external research is valuable.**\n\nRun these agents in parallel:\n\n- Use the best-practices-researcher skill to: feature_description\n- Use the framework-docs-researcher skill to: feature_description\n\n### 1.6. Consolidate Research\n\nAfter all research steps complete, consolidate findings:\n\n- Document relevant file paths from repo research (e.g., `app\u002FServices\u002FExampleService.php:42`)\n- **Include relevant institutional learnings** from `docs\u002Fsolutions\u002F` (key insights, gotchas to avoid)\n- **Include project context** from structured inputs (project tickets, documentation, Figma designs)\n- Note external documentation URLs and best practices (if external research was done)\n- List related issues or PRs discovered\n- Capture CLAUDE.md conventions\n\n**Optional validation:** Briefly summarize findings and ask if anything looks off or missing before proceeding to planning.\n\n### 2. Issue Planning & Structure\n\n\u003Cthinking>\nThink like a product manager - what would make this issue clear and actionable? Consider multiple perspectives\n\u003C\u002Fthinking>\n\n**Title & Categorization:**\n\n- [ ] Draft clear, searchable issue title using conventional format (e.g., `feat: Add user authentication`, `fix: Cart total calculation`)\n- [ ] Determine issue type: enhancement, bug, refactor\n- [ ] Convert title to filename: add today's date prefix, strip prefix colon, kebab-case, add `-plan` suffix\n  - Example: `feat: Add User Authentication` → `2026-01-21-feat-add-user-authentication-plan.md`\n  - Keep it descriptive (3-5 words after prefix) so plans are findable by context\n\n**Stakeholder Analysis:**\n\n- [ ] Identify who will be affected by this issue (end users, developers, operations)\n- [ ] Consider implementation complexity and required expertise\n\n**Content Planning:**\n\n- [ ] Choose appropriate detail level based on issue complexity and audience\n- [ ] List all necessary sections for the chosen template\n- [ ] Gather supporting materials (error logs, screenshots, design mockups)\n- [ ] Prepare code examples or reproduction steps if applicable, name the mock filenames in the lists\n\n**Execution Readiness:**\n\nFor plans that will be executed via `\u002Fworkflows-work`, ensure each implementation task includes:\n- **Files:** List of files to create or modify\n- **Depends on:** Which other tasks must complete first (or \"None\")\n- **Success criteria:** Testable checkboxes that define \"done\"\n- **Test command:** The exact command to verify the task is complete\n\nThis structured format enables the `\u002Fworkflows-work` orchestrator to delegate each task to a focused subagent with clear scope and termination criteria. Plans without this structure will be flagged for refinement before execution begins.\n\n### 3. SpecFlow Analysis\n\nAfter planning the issue structure, run SpecFlow Analyzer to validate and refine the feature specification:\n\n- Use the spec-flow-analyzer skill to: feature_description, research_findings\n\n**SpecFlow Analyzer Output:**\n\n- [ ] Review SpecFlow analysis results\n- [ ] Incorporate any identified gaps or edge cases into the issue\n- [ ] Update acceptance criteria based on SpecFlow findings\n\n### 4. Choose Implementation Detail Level\n\n**Important for `\u002Fworkflows-work` compatibility:** All detail levels can be executed, but the MORE and A LOT levels produce plans with structured execution chunks (per-task success criteria, test commands, file lists) that enable the subagent orchestration model in `\u002Fworkflows-work`. MINIMAL plans work but may require the orchestrator to decompose tasks further before delegating to subagents.\n\nSelect how comprehensive you want the issue to be, simpler is mostly better.\n\n#### ? MINIMAL (Quick Issue)\n\n**Best for:** Simple bugs, small improvements, clear features\n\n**Includes:**\n\n- Problem statement or feature description\n- Basic acceptance criteria\n- Essential context only\n\n**Note:** MINIMAL plans may need to be enriched with per-task success criteria before running `\u002Fworkflows-work`. The orchestrator can handle this decomposition automatically, but providing structured tasks up front leads to more predictable execution.\n\n**Structure:**\n\n````markdown\n---\ntitle: [Issue Title]\ntype: [feat|fix|refactor]\nstatus: active\ndate: YYYY-MM-DD\nsource_docs:\n  tickets: []\n  docs: []\n  figma: []\n  plans: []\n---\n\n# [Issue Title]\n\n[Brief problem\u002Ffeature description]\n\n## Acceptance Criteria\n\n- [ ] Core requirement 1\n- [ ] Core requirement 2\n\n## Context\n\n[Any critical information]\n\n## MVP\n\n### ExampleController.php\n\n```php\n\u002F\u002F app\u002FHttp\u002FControllers\u002FExampleController.php\nclass ExampleController extends Controller\n{\n    public function __construct()\n    {\n        $this->name = 'example';\n    }\n}\n```\n\n## References\n\n- Related issue: #[issue_number]\n- Documentation: [relevant_docs_url]\n````\n\n#### ? MORE (Standard Issue)\n\n**Best for:** Most features, complex bugs, team collaboration\n\n**Includes everything from MINIMAL plus:**\n\n- Detailed background and motivation\n- Technical considerations\n- Success metrics\n- Dependencies and risks\n- Basic implementation suggestions\n\n**Structure:**\n\n```markdown\n---\ntitle: [Issue Title]\ntype: [feat|fix|refactor]\nstatus: active\ndate: YYYY-MM-DD\nsource_docs:\n  tickets: []\n  docs: []\n  figma: []\n  plans: []\n---\n\n# [Issue Title]\n\n## Overview\n\n[Comprehensive description]\n\n## Problem Statement \u002F Motivation\n\n[Why this matters]\n\n## Proposed Solution\n\n[High-level approach]\n\n## Technical Considerations\n\n- Architecture impacts\n- Performance implications\n- Security considerations\n\n## Implementation Phases\n\n#### Phase 1: [Phase Name]\n\n##### Task 1.1: [Task Name]\n**Files:** `path\u002Fto\u002Ffile1.php`, `path\u002Fto\u002Ffile2.php`\n**Depends on:** None\n**Success criteria:**\n- [ ] Criterion 1\n- [ ] Criterion 2\n**Test command:** `\u003Cproject-appropriate test command>`\n\n##### Task 1.2: [Task Name]\n**Files:** `path\u002Fto\u002Ffile3.php`\n**Depends on:** Task 1.1\n**Success criteria:**\n- [ ] Criterion 1\n- [ ] Criterion 2\n**Test command:** `\u003Cproject-appropriate test command>`\n\n#### Phase 2: [Phase Name]\n\n##### Task 2.1: [Task Name]\n**Files:** `path\u002Fto\u002Ffile4.php`\n**Depends on:** Task 1.2\n**Success criteria:**\n- [ ] Criterion 1\n- [ ] Criterion 2\n**Test command:** `\u003Cproject-appropriate test command>`\n\n## Acceptance Criteria\n\n- [ ] Detailed requirement 1\n- [ ] Detailed requirement 2\n- [ ] Testing requirements\n\n## Success Metrics\n\n[How we measure success]\n\n## Dependencies & Risks\n\n[What could block or complicate this]\n\n## References & Research\n\n- Similar implementations: [file_path:line_number]\n- Best practices: [documentation_url]\n- Related PRs: #[pr_number]\n```\n\n#### ? A LOT (Comprehensive Issue)\n\n**Best for:** Major features, architectural changes, complex integrations\n\n**Includes everything from MORE plus:**\n\n- Detailed implementation plan with phases\n- Alternative approaches considered\n- Extensive technical specifications\n- Resource requirements and timeline\n- Future considerations and extensibility\n- Risk mitigation strategies\n- Documentation requirements\n\n**Structure:**\n\n```markdown\n---\ntitle: [Issue Title]\ntype: [feat|fix|refactor]\nstatus: active\ndate: YYYY-MM-DD\nsource_docs:\n  tickets: []\n  docs: []\n  figma: []\n  plans: []\n---\n\n# [Issue Title]\n\n## Overview\n\n[Executive summary]\n\n## Problem Statement\n\n[Detailed problem analysis]\n\n## Proposed Solution\n\n[Comprehensive solution design]\n\n## Technical Approach\n\n### Architecture\n\n[Detailed technical design]\n\n### Implementation Phases\n\n#### Phase 1: [Foundation]\n\n##### Task 1.1: [Task Name]\n**Files:** `path\u002Fto\u002Ffile1.php`, `path\u002Fto\u002Ffile2.php`\n**Depends on:** None\n**Success criteria:**\n- [ ] Criterion 1\n- [ ] Criterion 2\n**Test command:** `\u003Cproject-appropriate test command>`\n\n##### Task 1.2: [Task Name]\n**Files:** `path\u002Fto\u002Ffile3.php`\n**Depends on:** Task 1.1\n**Success criteria:**\n- [ ] Criterion 1\n- [ ] Criterion 2\n**Test command:** `\u003Cproject-appropriate test command>`\n\n#### Phase 2: [Core Implementation]\n\n##### Task 2.1: [Task Name]\n**Files:** `path\u002Fto\u002Ffile4.php`, `path\u002Fto\u002Ffile5.php`\n**Depends on:** Task 1.2\n**Success criteria:**\n- [ ] Criterion 1\n- [ ] Criterion 2\n**Test command:** `\u003Cproject-appropriate test command>`\n\n##### Task 2.2: [Task Name]\n**Files:** `path\u002Fto\u002Ffile6.php`\n**Depends on:** Task 2.1\n**Success criteria:**\n- [ ] Criterion 1\n- [ ] Criterion 2\n**Test command:** `\u003Cproject-appropriate test command>`\n\n#### Phase 3: [Polish & Optimization]\n\n##### Task 3.1: [Task Name]\n**Files:** `path\u002Fto\u002Ffile7.php`\n**Depends on:** Task 2.2\n**Success criteria:**\n- [ ] Criterion 1\n- [ ] Criterion 2\n**Test command:** `\u003Cproject-appropriate test command>`\n\n## Alternative Approaches Considered\n\n[Other solutions evaluated and why rejected]\n\n## Acceptance Criteria\n\n### Functional Requirements\n\n- [ ] Detailed functional criteria\n\n### Non-Functional Requirements\n\n- [ ] Performance targets\n- [ ] Security requirements\n- [ ] Accessibility standards\n\n### Quality Gates\n\n- [ ] Test coverage requirements\n- [ ] Documentation completeness\n- [ ] Code review approval\n\n## Success Metrics\n\n[Detailed KPIs and measurement methods]\n\n## Dependencies & Prerequisites\n\n[Detailed dependency analysis]\n\n## Risk Analysis & Mitigation\n\n[Comprehensive risk assessment]\n\n## Resource Requirements\n\n[Team, time, infrastructure needs]\n\n## Future Considerations\n\n[Extensibility and long-term vision]\n\n## Documentation Plan\n\n[What docs need updating]\n\n## References & Research\n\n### Internal References\n\n- Architecture decisions: [file_path:line_number]\n- Similar features: [file_path:line_number]\n- Configuration: [file_path:line_number]\n\n### External References\n\n- Framework documentation: [url]\n- Best practices guide: [url]\n- Industry standards: [url]\n\n### Related Work\n\n- Previous PRs: #[pr_numbers]\n- Related issues: #[issue_numbers]\n- Design documents: [links]\n```\n\n### 5. Issue Creation & Formatting\n\n\u003Cthinking>\nApply best practices for clarity and actionability, making the issue easy to scan and understand\n\u003C\u002Fthinking>\n\n**Content Formatting:**\n\n- [ ] Use clear, descriptive headings with proper hierarchy (##, ###)\n- [ ] Include code examples in triple backticks with language syntax highlighting\n- [ ] Add screenshots\u002Fmockups if UI-related (drag & drop or use image hosting)\n- [ ] Use task lists (- [ ]) for trackable items that can be checked off\n- [ ] Add collapsible sections for lengthy logs or optional details using `\u003Cdetails>` tags\n- [ ] Apply appropriate emoji for visual scanning (? bug, ✨ feature, ? docs, ♻️ refactor)\n\n**Cross-Referencing:**\n\n- [ ] Link to related issues\u002FPRs using #number format\n- [ ] Reference specific commits with SHA hashes when relevant\n- [ ] Link to code using permalink features (branch + commit SHA for permanent links)\n- [ ] Mention relevant team members with @username if needed\n- [ ] Add links to external resources with descriptive text\n\n**Code & Examples:**\n\n````markdown\n# Good example with syntax highlighting and line references\n\n\n```php\n\u002F\u002F app\u002FServices\u002FUserService.php:42\npublic function processUser(User $user): array\n{\n    \u002F\u002F Implementation here\n}\n```\n\n# Collapsible error logs\n\n\u003Cdetails>\n\u003Csummary>Full error stacktrace\u003C\u002Fsummary>\n\n`Error details here...`\n\n\u003C\u002Fdetails>\n````\n\n**AI-Era Considerations:**\n\n- [ ] Account for accelerated development with AI pair programming\n- [ ] Include prompts or instructions that worked well during research\n- [ ] Note which AI tools were used for initial exploration (Claude, Copilot, etc.)\n- [ ] Emphasize comprehensive testing given rapid implementation\n- [ ] Document any AI-generated code that needs human review\n\n### 6. Final Review & Submission\n\n**Pre-submission Checklist:**\n\n- [ ] Title is searchable and descriptive\n- [ ] Labels accurately categorize the issue\n- [ ] All template sections are complete\n- [ ] Links and references are working\n- [ ] Acceptance criteria are measurable\n- [ ] Add names of files in pseudo code examples and todo lists\n- [ ] Add an ERD mermaid diagram if applicable for new model changes\n\n## Directory Setup & Gitignore\n\nBefore writing the plan file, ensure the output directory and gitignore rules exist:\n\n```bash\n# Create docs\u002Fplans\u002F directory if it doesn't exist\nmkdir -p docs\u002Fplans\n\n# Ensure docs\u002Fplans\u002F and docs\u002Fbrainstorms\u002F are in .gitignore (but NOT docs\u002Fsolutions\u002F)\nif [ -f .gitignore ]; then\n  grep -qxF 'docs\u002Fplans\u002F' .gitignore || echo 'docs\u002Fplans\u002F' >> .gitignore\n  grep -qxF 'docs\u002Fbrainstorms\u002F' .gitignore || echo 'docs\u002Fbrainstorms\u002F' >> .gitignore\nelse\n  printf 'docs\u002Fplans\u002F\\ndocs\u002Fbrainstorms\u002F\\n' > .gitignore\nfi\n```\n\n**IMPORTANT:** `docs\u002Fsolutions\u002F` must NOT be added to .gitignore -- it contains committed institutional knowledge.\n\n## Output Format\n\n**Filename:** Use the date and kebab-case filename from Step 2 Title & Categorization.\n\n```\ndocs\u002Fplans\u002FYYYY-MM-DD-\u003Ctype>-\u003Cdescriptive-name>-plan.md\n```\n\nExamples:\n- ✅ `docs\u002Fplans\u002F2026-01-15-feat-user-authentication-flow-plan.md`\n- ✅ `docs\u002Fplans\u002F2026-02-03-fix-checkout-race-condition-plan.md`\n- ✅ `docs\u002Fplans\u002F2026-03-10-refactor-api-client-extraction-plan.md`\n- ❌ `docs\u002Fplans\u002F2026-01-15-feat-thing-plan.md` (not descriptive - what \"thing\"?)\n- ❌ `docs\u002Fplans\u002F2026-01-15-feat-new-feature-plan.md` (too vague - what feature?)\n- ❌ `docs\u002Fplans\u002F2026-01-15-feat: user auth-plan.md` (invalid characters - colon and space)\n- ❌ `docs\u002Fplans\u002Ffeat-user-auth-plan.md` (missing date prefix)\n\n## Post-Generation Options\n\nAfter writing the plan file, use the **AskUserQuestion tool** to present these options:\n\n**Question:** \"Plan ready at `docs\u002Fplans\u002FYYYY-MM-DD-\u003Ctype>-\u003Cname>-plan.md`. What would you like to do next?\"\n\n**Options:**\n1. **Open plan in editor** - Open the plan file for review\n2. **Run `\u002Fdeepen-plan`** - Enhance each section with parallel research agents (best practices, performance, UI)\n3. **Run `\u002Ftechnical_review`** - Technical feedback from code-focused reviewers (Rabak Laravel, Rabak Vue, Simplicity)\n4. **Review and refine** - Improve the document through structured self-review\n5. **Start `\u002Fworkflows-work`** - Begin implementing this plan locally\n6. **Start `\u002Fworkflows-work` on remote** - Begin implementing in Claude Code on the web (use `&` to run in background)\n7. **Create Issue** - Create issue in project tracker\n\nBased on selection:\n- **Open plan in editor** → Run `open docs\u002Fplans\u002F\u003Cplan_filename>.md` to open the file in the user's default editor\n- **`\u002Fdeepen-plan`** → Call the \u002Fdeepen-plan command with the plan file path to enhance with research\n- **`\u002Ftechnical_review`** → Call the \u002Ftechnical_review command with the plan file path\n- **Review and refine** → Load `document-review` skill.\n- **`\u002Fworkflows-work`** → Call the \u002Fworkflows-work command with the plan file path\n- **`\u002Fworkflows-work` on remote** → Run `\u002Fworkflows-work docs\u002Fplans\u002F\u003Cplan_filename>.md &` to start work in background for Claude Code web\n- **Create Issue** → See \"Issue Creation\" section below\n- **Other** (automatically provided) → Accept free text for rework or specific changes\n\n**Note:** If running `\u002Fworkflows-plan` with ultrathink enabled, automatically run `\u002Fdeepen-plan` after plan creation for maximum depth and grounding.\n\nLoop back to options after Simplify or Other changes until user selects `\u002Fworkflows-work` or `\u002Ftechnical_review`.\n\n## Issue Creation\n\nWhen user selects \"Create Issue\":\n\n1. **Save the plan as a tracker-ready description:**\n\n   The plan file is already in markdown format. Inform the user:\n   - \"Plan saved at `[plan_path]`. You can create a ticket using the plan content.\"\n   - Copy the plan content to clipboard if possible, or point to the file path\n\n2. **After creation:**\n   - Ask if they want to proceed to `\u002Fworkflows-work` or `\u002Ftechnical_review`\n\nNEVER CODE! Just research and write the plan.\n","## Arguments\n[feature description, bug report, or improvement idea]\n\n# Create a plan for a new feature or bug fix\n\n## Introduction\n\n**Note: The current year is 2026.** Use this when dating plans and searching for recent documentation.\n\nTransform feature descriptions, bug reports, or improvement ideas into well-structured markdown files issues that follow project conventions and best practices. This command provides flexible detail levels to match your needs.\n\n## Feature Description\n\n\u003Cfeature_description> #$ARGUMENTS \u003C\u002Ffeature_description>\n\n**If the feature description above is empty, ask the user:** \"What would you like to plan? Please describe the feature, bug fix, or improvement you have in mind.\"\n\nDo not proceed until you have a clear feature description from the user.\n\n### 0. Idea Refinement\n\n**Check if arguments contain a plan or spec file:**\n\nIf the feature description (`#$ARGUMENTS`) is or contains a path to a `.md` file (e.g., `docs\u002Fplans\u002Fsome-plan.md`, `spec.md`, `~\u002Fnotes\u002Ffeature-plan.md`):\n\n1. Read the file\n2. Announce: \"Found existing plan\u002Fspec: `[file path]`. Using as foundation.\"\n3. Extract: title, problem statement, proposed approach, acceptance criteria, implementation phases, and any existing tasks\n4. **Skip idea refinement questions** — the plan already defines WHAT to build\n5. **Skip brainstorm check** — an explicit plan supersedes brainstorm discovery\n6. Proceed to Step 0.5 to gather any additional project inputs, then to research to validate and enrich the existing plan\n7. In Step 2 (Issue Planning), **build upon the existing plan structure** — preserve its sections, fill gaps, add execution-readiness fields (Files, Depends on, Success criteria, Test command) to any tasks that lack them, and enrich with research findings. Do NOT discard or rewrite sections that are already well-defined.\n\n**If arguments are NOT a file path, check for brainstorm output:**\n\nBefore asking questions, look for recent brainstorm documents in `docs\u002Fbrainstorms\u002F` that match this feature:\n\n```bash\nls -la docs\u002Fbrainstorms\u002F*.md 2>\u002Fdev\u002Fnull | head -10\n```\n\n**Relevance criteria:** A brainstorm is relevant if:\n- The topic (from filename or YAML frontmatter) semantically matches the feature description\n- Created within the last 14 days\n- If multiple candidates match, use the most recent one\n\n**If a relevant brainstorm exists:**\n1. Read the brainstorm document\n2. Announce: \"Found brainstorm from [date]: [topic]. Using as context for planning.\"\n3. Extract key decisions, chosen approach, and open questions\n4. **Skip the idea refinement questions below** - the brainstorm already answered WHAT to build\n5. Use brainstorm decisions as input to the research phase\n\n**If multiple brainstorms could match:**\nUse **AskUserQuestion tool** to ask which brainstorm to use, or whether to proceed without one.\n\n**If no brainstorm found (or not relevant), run idea refinement:**\n\nRefine the idea through collaborative dialogue using the **AskUserQuestion tool**:\n\n- Ask questions one at a time to understand the idea fully\n- Prefer multiple choice questions when natural options exist\n- Focus on understanding: purpose, constraints and success criteria\n- Continue until the idea is clear OR user says \"proceed\"\n\n**Gather signals for research decision.** During refinement, note:\n\n- **User's familiarity**: Do they know the codebase patterns? Are they pointing to examples?\n- **User's intent**: Speed vs thoroughness? Exploration vs execution?\n- **Topic risk**: Security, payments, external APIs warrant more caution\n- **Uncertainty level**: Is the approach clear or open-ended?\n\n**Skip option:** If the feature description is already detailed, offer:\n\"Your description is clear. Should I proceed with research, or would you like to refine it further?\"\n\n### 0.5 Gather Project Inputs\n\nUse the **AskUserQuestion tool** to collect structured project inputs. Ask these 4 questions in sequence:\n\n**Question 1:** \"Do you have any project management tickets related to this feature?\"\n- Options: `[\"None\", \"Enter URLs\"]`\n- If \"Enter URLs\": Ask user to paste ticket URLs (comma-separated)\n\n**Question 2:** \"Do you have any wiki or documentation pages related to this feature?\"\n- Options: `[\"None\", \"Enter URLs\"]`\n- If \"Enter URLs\": Ask user to paste documentation URLs (comma-separated)\n\n**Question 3:** \"Do you have any Figma designs related to this feature?\"\n- Options: `[\"None\", \"Enter URLs\"]`\n- If \"Enter URLs\": Ask user to paste Figma design URLs (comma-separated)\n\n**Question 4:** \"Do you have any existing plan, spec, or requirements documents (.md files) to build from?\"\n- Options: `[\"None\", \"Enter file paths\"]`\n- If \"Enter file paths\": Ask user to paste file paths (comma-separated, relative or absolute)\n\n**Processing inputs:**\n\nFor any non-empty inputs, launch **parallel subagents** to fetch and summarize each document:\n\n- Use the fetch-and-summarize skill to: ticket_urls → Extract ticket title, description, acceptance criteria, status\n- Use the fetch-and-summarize skill to: doc_urls → Extract key decisions, requirements, technical context\n- Use the fetch-and-summarize skill to: figma_urls → Extract design intent, component structure, interaction patterns\n- Use the read-and-extract skill to: plan_file_paths → Read each `.md` file, extract structure (title, problem statement, approach, tasks, acceptance criteria, open questions). Identify which sections are well-defined vs need enrichment.\n\n**Handle `MANUAL_INPUT_NEEDED`:** If a subagent cannot access a URL (authentication required, private resource), use the **AskUserQuestion tool** to ask: \"I couldn't access [URL]. Could you paste the relevant content from this document?\"\n\n**Consolidate into `project_context` block:**\n\n```markdown\n## Project Context (from structured inputs)\n\n### Project Tickets\n- [TICKET-123](url): Summary of ticket...\n\n### Documentation\n- [Doc Title](url): Key decisions and requirements...\n\n### Figma Designs\n- [Design Name](url): Design intent and component overview...\n\n### Existing Plans \u002F Specs\n- [filename.md](path): Structure summary, well-defined sections, gaps to fill...\n```\n\n**Store source URLs\u002Fpaths in plan frontmatter** under `source_docs:`:\n\n```yaml\nsource_docs:\n  tickets:\n    - https:\u002F\u002Ftracker.example.com\u002FTICKET-123\n  docs:\n    - https:\u002F\u002Fwiki.example.com\u002Fpages\u002Fdoc-id\n  figma:\n    - https:\u002F\u002Ffigma.com\u002Ffile\u002Fabc123\n  plans:\n    - docs\u002Fspecs\u002Fexisting-feature-spec.md\n```\n\nIf all three inputs are \"None\", skip this step and proceed.\n\n## Main Tasks\n\n### 1. Local Research (Always Runs - Parallel)\n\n\u003Cthinking>\nFirst, I need to understand the project's conventions, existing patterns, and any documented learnings. This is fast and local - it informs whether external research is needed.\n\u003C\u002Fthinking>\n\nRun these agents **in parallel** to gather local context:\n\n- Use the repo-research-analyst skill to: feature_description\n- Use the learnings-researcher skill to: feature_description\n\n**What to look for:**\n- **Repo research:** existing patterns, CLAUDE.md guidance, technology familiarity, pattern consistency\n- **Learnings:** documented solutions in `docs\u002Fsolutions\u002F` that might apply (gotchas, patterns, lessons learned)\n\nThese findings inform the next step.\n\n### 1.5. Research Decision\n\nBased on signals from Step 0 and findings from Step 1, decide on external research.\n\n**High-risk topics → always research.** Security, payments, external APIs, data privacy. The cost of missing something is too high. This takes precedence over speed signals.\n\n**Strong local context → skip external research.** Codebase has good patterns, CLAUDE.md has guidance, user knows what they want. External research adds little value.\n\n**Uncertainty or unfamiliar territory → research.** User is exploring, codebase has no examples, new technology. External perspective is valuable.\n\n**Announce the decision and proceed.** Brief explanation, then continue. User can redirect if needed.\n\nExamples:\n- \"Your codebase has solid patterns for this. Proceeding without external research.\"\n- \"This involves payment processing, so I'll research current best practices first.\"\n\n### 1.5b. External Research (Conditional)\n\n**Only run if Step 1.5 indicates external research is valuable.**\n\nRun these agents in parallel:\n\n- Use the best-practices-researcher skill to: feature_description\n- Use the framework-docs-researcher skill to: feature_description\n\n### 1.6. Consolidate Research\n\nAfter all research steps complete, consolidate findings:\n\n- Document relevant file paths from repo research (e.g., `app\u002FServices\u002FExampleService.php:42`)\n- **Include relevant institutional learnings** from `docs\u002Fsolutions\u002F` (key insights, gotchas to avoid)\n- **Include project context** from structured inputs (project tickets, documentation, Figma designs)\n- Note external documentation URLs and best practices (if external research was done)\n- List related issues or PRs discovered\n- Capture CLAUDE.md conventions\n\n**Optional validation:** Briefly summarize findings and ask if anything looks off or missing before proceeding to planning.\n\n### 2. Issue Planning & Structure\n\n\u003Cthinking>\nThink like a product manager - what would make this issue clear and actionable? Consider multiple perspectives\n\u003C\u002Fthinking>\n\n**Title & Categorization:**\n\n- [ ] Draft clear, searchable issue title using conventional format (e.g., `feat: Add user authentication`, `fix: Cart total calculation`)\n- [ ] Determine issue type: enhancement, bug, refactor\n- [ ] Convert title to filename: add today's date prefix, strip prefix colon, kebab-case, add `-plan` suffix\n  - Example: `feat: Add User Authentication` → `2026-01-21-feat-add-user-authentication-plan.md`\n  - Keep it descriptive (3-5 words after prefix) so plans are findable by context\n\n**Stakeholder Analysis:**\n\n- [ ] Identify who will be affected by this issue (end users, developers, operations)\n- [ ] Consider implementation complexity and required expertise\n\n**Content Planning:**\n\n- [ ] Choose appropriate detail level based on issue complexity and audience\n- [ ] List all necessary sections for the chosen template\n- [ ] Gather supporting materials (error logs, screenshots, design mockups)\n- [ ] Prepare code examples or reproduction steps if applicable, name the mock filenames in the lists\n\n**Execution Readiness:**\n\nFor plans that will be executed via `\u002Fworkflows-work`, ensure each implementation task includes:\n- **Files:** List of files to create or modify\n- **Depends on:** Which other tasks must complete first (or \"None\")\n- **Success criteria:** Testable checkboxes that define \"done\"\n- **Test command:** The exact command to verify the task is complete\n\nThis structured format enables the `\u002Fworkflows-work` orchestrator to delegate each task to a focused subagent with clear scope and termination criteria. Plans without this structure will be flagged for refinement before execution begins.\n\n### 3. SpecFlow Analysis\n\nAfter planning the issue structure, run SpecFlow Analyzer to validate and refine the feature specification:\n\n- Use the spec-flow-analyzer skill to: feature_description, research_findings\n\n**SpecFlow Analyzer Output:**\n\n- [ ] Review SpecFlow analysis results\n- [ ] Incorporate any identified gaps or edge cases into the issue\n- [ ] Update acceptance criteria based on SpecFlow findings\n\n### 4. Choose Implementation Detail Level\n\n**Important for `\u002Fworkflows-work` compatibility:** All detail levels can be executed, but the MORE and A LOT levels produce plans with structured execution chunks (per-task success criteria, test commands, file lists) that enable the subagent orchestration model in `\u002Fworkflows-work`. MINIMAL plans work but may require the orchestrator to decompose tasks further before delegating to subagents.\n\nSelect how comprehensive you want the issue to be, simpler is mostly better.\n\n#### ? MINIMAL (Quick Issue)\n\n**Best for:** Simple bugs, small improvements, clear features\n\n**Includes:**\n\n- Problem statement or feature description\n- Basic acceptance criteria\n- Essential context only\n\n**Note:** MINIMAL plans may need to be enriched with per-task success criteria before running `\u002Fworkflows-work`. The orchestrator can handle this decomposition automatically, but providing structured tasks up front leads to more predictable execution.\n\n**Structure:**\n\n````markdown\n---\ntitle: [Issue Title]\ntype: [feat|fix|refactor]\nstatus: active\ndate: YYYY-MM-DD\nsource_docs:\n  tickets: []\n  docs: []\n  figma: []\n  plans: []\n---\n\n# [Issue Title]\n\n[Brief problem\u002Ffeature description]\n\n## Acceptance Criteria\n\n- [ ] Core requirement 1\n- [ ] Core requirement 2\n\n## Context\n\n[Any critical information]\n\n## MVP\n\n### ExampleController.php\n\n```php\n\u002F\u002F app\u002FHttp\u002FControllers\u002FExampleController.php\nclass ExampleController extends Controller\n{\n    public function __construct()\n    {\n        $this->name = 'example';\n    }\n}\n```\n\n## References\n\n- Related issue: #[issue_number]\n- Documentation: [relevant_docs_url]\n````\n\n#### ? MORE (Standard Issue)\n\n**Best for:** Most features, complex bugs, team collaboration\n\n**Includes everything from MINIMAL plus:**\n\n- Detailed background and motivation\n- Technical considerations\n- Success metrics\n- Dependencies and risks\n- Basic implementation suggestions\n\n**Structure:**\n\n```markdown\n---\ntitle: [Issue Title]\ntype: [feat|fix|refactor]\nstatus: active\ndate: YYYY-MM-DD\nsource_docs:\n  tickets: []\n  docs: []\n  figma: []\n  plans: []\n---\n\n# [Issue Title]\n\n## Overview\n\n[Comprehensive description]\n\n## Problem Statement \u002F Motivation\n\n[Why this matters]\n\n## Proposed Solution\n\n[High-level approach]\n\n## Technical Considerations\n\n- Architecture impacts\n- Performance implications\n- Security considerations\n\n## Implementation Phases\n\n#### Phase 1: [Phase Name]\n\n##### Task 1.1: [Task Name]\n**Files:** `path\u002Fto\u002Ffile1.php`, `path\u002Fto\u002Ffile2.php`\n**Depends on:** None\n**Success criteria:**\n- [ ] Criterion 1\n- [ ] Criterion 2\n**Test command:** `\u003Cproject-appropriate test command>`\n\n##### Task 1.2: [Task Name]\n**Files:** `path\u002Fto\u002Ffile3.php`\n**Depends on:** Task 1.1\n**Success criteria:**\n- [ ] Criterion 1\n- [ ] Criterion 2\n**Test command:** `\u003Cproject-appropriate test command>`\n\n#### Phase 2: [Phase Name]\n\n##### Task 2.1: [Task Name]\n**Files:** `path\u002Fto\u002Ffile4.php`\n**Depends on:** Task 1.2\n**Success criteria:**\n- [ ] Criterion 1\n- [ ] Criterion 2\n**Test command:** `\u003Cproject-appropriate test command>`\n\n## Acceptance Criteria\n\n- [ ] Detailed requirement 1\n- [ ] Detailed requirement 2\n- [ ] Testing requirements\n\n## Success Metrics\n\n[How we measure success]\n\n## Dependencies & Risks\n\n[What could block or complicate this]\n\n## References & Research\n\n- Similar implementations: [file_path:line_number]\n- Best practices: [documentation_url]\n- Related PRs: #[pr_number]\n```\n\n#### ? A LOT (Comprehensive Issue)\n\n**Best for:** Major features, architectural changes, complex integrations\n\n**Includes everything from MORE plus:**\n\n- Detailed implementation plan with phases\n- Alternative approaches considered\n- Extensive technical specifications\n- Resource requirements and timeline\n- Future considerations and extensibility\n- Risk mitigation strategies\n- Documentation requirements\n\n**Structure:**\n\n```markdown\n---\ntitle: [Issue Title]\ntype: [feat|fix|refactor]\nstatus: active\ndate: YYYY-MM-DD\nsource_docs:\n  tickets: []\n  docs: []\n  figma: []\n  plans: []\n---\n\n# [Issue Title]\n\n## Overview\n\n[Executive summary]\n\n## Problem Statement\n\n[Detailed problem analysis]\n\n## Proposed Solution\n\n[Comprehensive solution design]\n\n## Technical Approach\n\n### Architecture\n\n[Detailed technical design]\n\n### Implementation Phases\n\n#### Phase 1: [Foundation]\n\n##### Task 1.1: [Task Name]\n**Files:** `path\u002Fto\u002Ffile1.php`, `path\u002Fto\u002Ffile2.php`\n**Depends on:** None\n**Success criteria:**\n- [ ] Criterion 1\n- [ ] Criterion 2\n**Test command:** `\u003Cproject-appropriate test command>`\n\n##### Task 1.2: [Task Name]\n**Files:** `path\u002Fto\u002Ffile3.php`\n**Depends on:** Task 1.1\n**Success criteria:**\n- [ ] Criterion 1\n- [ ] Criterion 2\n**Test command:** `\u003Cproject-appropriate test command>`\n\n#### Phase 2: [Core Implementation]\n\n##### Task 2.1: [Task Name]\n**Files:** `path\u002Fto\u002Ffile4.php`, `path\u002Fto\u002Ffile5.php`\n**Depends on:** Task 1.2\n**Success criteria:**\n- [ ] Criterion 1\n- [ ] Criterion 2\n**Test command:** `\u003Cproject-appropriate test command>`\n\n##### Task 2.2: [Task Name]\n**Files:** `path\u002Fto\u002Ffile6.php`\n**Depends on:** Task 2.1\n**Success criteria:**\n- [ ] Criterion 1\n- [ ] Criterion 2\n**Test command:** `\u003Cproject-appropriate test command>`\n\n#### Phase 3: [Polish & Optimization]\n\n##### Task 3.1: [Task Name]\n**Files:** `path\u002Fto\u002Ffile7.php`\n**Depends on:** Task 2.2\n**Success criteria:**\n- [ ] Criterion 1\n- [ ] Criterion 2\n**Test command:** `\u003Cproject-appropriate test command>`\n\n## Alternative Approaches Considered\n\n[Other solutions evaluated and why rejected]\n\n## Acceptance Criteria\n\n### Functional Requirements\n\n- [ ] Detailed functional criteria\n\n### Non-Functional Requirements\n\n- [ ] Performance targets\n- [ ] Security requirements\n- [ ] Accessibility standards\n\n### Quality Gates\n\n- [ ] Test coverage requirements\n- [ ] Documentation completeness\n- [ ] Code review approval\n\n## Success Metrics\n\n[Detailed KPIs and measurement methods]\n\n## Dependencies & Prerequisites\n\n[Detailed dependency analysis]\n\n## Risk Analysis & Mitigation\n\n[Comprehensive risk assessment]\n\n## Resource Requirements\n\n[Team, time, infrastructure needs]\n\n## Future Considerations\n\n[Extensibility and long-term vision]\n\n## Documentation Plan\n\n[What docs need updating]\n\n## References & Research\n\n### Internal References\n\n- Architecture decisions: [file_path:line_number]\n- Similar features: [file_path:line_number]\n- Configuration: [file_path:line_number]\n\n### External References\n\n- Framework documentation: [url]\n- Best practices guide: [url]\n- Industry standards: [url]\n\n### Related Work\n\n- Previous PRs: #[pr_numbers]\n- Related issues: #[issue_numbers]\n- Design documents: [links]\n```\n\n### 5. Issue Creation & Formatting\n\n\u003Cthinking>\nApply best practices for clarity and actionability, making the issue easy to scan and understand\n\u003C\u002Fthinking>\n\n**Content Formatting:**\n\n- [ ] Use clear, descriptive headings with proper hierarchy (##, ###)\n- [ ] Include code examples in triple backticks with language syntax highlighting\n- [ ] Add screenshots\u002Fmockups if UI-related (drag & drop or use image hosting)\n- [ ] Use task lists (- [ ]) for trackable items that can be checked off\n- [ ] Add collapsible sections for lengthy logs or optional details using `\u003Cdetails>` tags\n- [ ] Apply appropriate emoji for visual scanning (? bug, ✨ feature, ? docs, ♻️ refactor)\n\n**Cross-Referencing:**\n\n- [ ] Link to related issues\u002FPRs using #number format\n- [ ] Reference specific commits with SHA hashes when relevant\n- [ ] Link to code using permalink features (branch + commit SHA for permanent links)\n- [ ] Mention relevant team members with @username if needed\n- [ ] Add links to external resources with descriptive text\n\n**Code & Examples:**\n\n````markdown\n# Good example with syntax highlighting and line references\n\n\n```php\n\u002F\u002F app\u002FServices\u002FUserService.php:42\npublic function processUser(User $user): array\n{\n    \u002F\u002F Implementation here\n}\n```\n\n# Collapsible error logs\n\n\u003Cdetails>\n\u003Csummary>Full error stacktrace\u003C\u002Fsummary>\n\n`Error details here...`\n\n\u003C\u002Fdetails>\n````\n\n**AI-Era Considerations:**\n\n- [ ] Account for accelerated development with AI pair programming\n- [ ] Include prompts or instructions that worked well during research\n- [ ] Note which AI tools were used for initial exploration (Claude, Copilot, etc.)\n- [ ] Emphasize comprehensive testing given rapid implementation\n- [ ] Document any AI-generated code that needs human review\n\n### 6. Final Review & Submission\n\n**Pre-submission Checklist:**\n\n- [ ] Title is searchable and descriptive\n- [ ] Labels accurately categorize the issue\n- [ ] All template sections are complete\n- [ ] Links and references are working\n- [ ] Acceptance criteria are measurable\n- [ ] Add names of files in pseudo code examples and todo lists\n- [ ] Add an ERD mermaid diagram if applicable for new model changes\n\n## Directory Setup & Gitignore\n\nBefore writing the plan file, ensure the output directory and gitignore rules exist:\n\n```bash\n# Create docs\u002Fplans\u002F directory if it doesn't exist\nmkdir -p docs\u002Fplans\n\n# Ensure docs\u002Fplans\u002F and docs\u002Fbrainstorms\u002F are in .gitignore (but NOT docs\u002Fsolutions\u002F)\nif [ -f .gitignore ]; then\n  grep -qxF 'docs\u002Fplans\u002F' .gitignore || echo 'docs\u002Fplans\u002F' >> .gitignore\n  grep -qxF 'docs\u002Fbrainstorms\u002F' .gitignore || echo 'docs\u002Fbrainstorms\u002F' >> .gitignore\nelse\n  printf 'docs\u002Fplans\u002F\\ndocs\u002Fbrainstorms\u002F\\n' > .gitignore\nfi\n```\n\n**IMPORTANT:** `docs\u002Fsolutions\u002F` must NOT be added to .gitignore -- it contains committed institutional knowledge.\n\n## Output Format\n\n**Filename:** Use the date and kebab-case filename from Step 2 Title & Categorization.\n\n```\ndocs\u002Fplans\u002FYYYY-MM-DD-\u003Ctype>-\u003Cdescriptive-name>-plan.md\n```\n\nExamples:\n- ✅ `docs\u002Fplans\u002F2026-01-15-feat-user-authentication-flow-plan.md`\n- ✅ `docs\u002Fplans\u002F2026-02-03-fix-checkout-race-condition-plan.md`\n- ✅ `docs\u002Fplans\u002F2026-03-10-refactor-api-client-extraction-plan.md`\n- ❌ `docs\u002Fplans\u002F2026-01-15-feat-thing-plan.md` (not descriptive - what \"thing\"?)\n- ❌ `docs\u002Fplans\u002F2026-01-15-feat-new-feature-plan.md` (too vague - what feature?)\n- ❌ `docs\u002Fplans\u002F2026-01-15-feat: user auth-plan.md` (invalid characters - colon and space)\n- ❌ `docs\u002Fplans\u002Ffeat-user-auth-plan.md` (missing date prefix)\n\n## Post-Generation Options\n\nAfter writing the plan file, use the **AskUserQuestion tool** to present these options:\n\n**Question:** \"Plan ready at `docs\u002Fplans\u002FYYYY-MM-DD-\u003Ctype>-\u003Cname>-plan.md`. What would you like to do next?\"\n\n**Options:**\n1. **Open plan in editor** - Open the plan file for review\n2. **Run `\u002Fdeepen-plan`** - Enhance each section with parallel research agents (best practices, performance, UI)\n3. **Run `\u002Ftechnical_review`** - Technical feedback from code-focused reviewers (Rabak Laravel, Rabak Vue, Simplicity)\n4. **Review and refine** - Improve the document through structured self-review\n5. **Start `\u002Fworkflows-work`** - Begin implementing this plan locally\n6. **Start `\u002Fworkflows-work` on remote** - Begin implementing in Claude Code on the web (use `&` to run in background)\n7. **Create Issue** - Create issue in project tracker\n\nBased on selection:\n- **Open plan in editor** → Run `open docs\u002Fplans\u002F\u003Cplan_filename>.md` to open the file in the user's default editor\n- **`\u002Fdeepen-plan`** → Call the \u002Fdeepen-plan command with the plan file path to enhance with research\n- **`\u002Ftechnical_review`** → Call the \u002Ftechnical_review command with the plan file path\n- **Review and refine** → Load `document-review` skill.\n- **`\u002Fworkflows-work`** → Call the \u002Fworkflows-work command with the plan file path\n- **`\u002Fworkflows-work` on remote** → Run `\u002Fworkflows-work docs\u002Fplans\u002F\u003Cplan_filename>.md &` to start work in background for Claude Code web\n- **Create Issue** → See \"Issue Creation\" section below\n- **Other** (automatically provided) → Accept free text for rework or specific changes\n\n**Note:** If running `\u002Fworkflows-plan` with ultrathink enabled, automatically run `\u002Fdeepen-plan` after plan creation for maximum depth and grounding.\n\nLoop back to options after Simplify or Other changes until user selects `\u002Fworkflows-work` or `\u002Ftechnical_review`.\n\n## Issue Creation\n\nWhen user selects \"Create Issue\":\n\n1. **Save the plan as a tracker-ready description:**\n\n   The plan file is already in markdown format. Inform the user:\n   - \"Plan saved at `[plan_path]`. You can create a ticket using the plan content.\"\n   - Copy the plan content to clipboard if possible, or point to the file path\n\n2. **After creation:**\n   - Ask if they want to proceed to `\u002Fworkflows-work` or `\u002Ftechnical_review`\n\nNEVER CODE! Just research and write the plan.\n",{"name":5,"description":7},"main","b097d394a335a9ec3c8a02d64e111f1a9c96703d",".github\u002Fskills\u002Fworkflows-plan","https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fnaysmith","https:\u002F\u002Fgithub.com\u002FThe-Rabak","2026-03-04 03:03:05",{"source":8,"skillName":5,"commands":37,"prompt":47,"zipAvailable":48},[38,41,44],{"tool":39,"command":40},"npx","npx skills add The-Rabak\u002Fnaysmith --skill workflows-plan",{"tool":42,"command":43},"bunx","bunx skills add The-Rabak\u002Fnaysmith --skill workflows-plan",{"tool":45,"command":46},"pnpm","pnpm dlx skills add The-Rabak\u002Fnaysmith --skill workflows-plan","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fnaysmith\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fworkflows-plan\u002FSKILL.md",true,[],[51,62,76,93,107,118],{"skillNo":52,"name":53,"nameZh":6,"description":54,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":55,"categories":56,"keywords":57,"publishedAt":25},"01M6CYBMHFVAMC4T3J8QFYN42M","workflows-work","Execute work plans efficiently while maintaining quality and finishing features","https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fnaysmith\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fworkflows-work\u002FSKILL.md",[],[58,59,18,60,61],"workflows work","work","execute","quality",{"skillNo":63,"name":64,"nameZh":6,"description":65,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":66,"categories":67,"keywords":68,"publishedAt":25},"01M6CYBJ1KP7W3X8HEG49KST9Q","workflows-review","Perform exhaustive code reviews using multi-agent analysis, ultra-thinking, and worktrees","https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fnaysmith\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fworkflows-review\u002FSKILL.md",[],[69,18,70,71,72,73,74,75],"workflows review","review","thinking","worktrees","multi-agent","analysis","code",{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":87,"publishedAt":25},"01M6CYBBKAHJJ85JC2PS380TGZ","workflows-compound","Document a recently solved problem to compound your team's knowledge","https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fnaysmith\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fworkflows-compound\u002FSKILL.md",[82],{"categoryNo":83,"categoryName":84,"taxonomyType":85,"taxonomyTypeDesc":86},"01JBSEEDCAT000000000000021","资料检索与研究","SCENARIO","使用场景",[18,88,89,90,91,92],"compound","workflows compound","document","knowledge","team",{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":99,"publishedAt":25},"01M6CYB9062GMP8VSA7N7PB4NW","workflows-brainstorm","Explore requirements and approaches through collaborative dialogue before planning implementation","https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fnaysmith\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fworkflows-brainstorm\u002FSKILL.md",[],[100,101,18,102,103,104,105,106],"workflows brainstorm","brainstorm","planning","requirements","dialogue","implementation","explore",{"skillNo":108,"name":109,"nameZh":6,"description":110,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":111,"categories":112,"keywords":113,"publishedAt":25},"01M6CYB6S7GKWH62CRV3K79MHW","triage","Triage and categorize findings for the CLI todo system","https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fnaysmith\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ftriage\u002FSKILL.md",[],[109,114,115,116,117],"cli","system","categorize","todo",{"skillNo":119,"name":120,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":122,"categories":123,"keywords":127,"publishedAt":25},"01M6CYB4GDXS6AYFH7NMJRTXP7","test-browser","Run browser tests on pages affected by current PR or branch","https:\u002F\u002Fgithub.com\u002FThe-Rabak\u002Fnaysmith\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ftest-browser\u002FSKILL.md",[124],{"categoryNo":125,"categoryName":126,"taxonomyType":85,"taxonomyTypeDesc":86},"01JBSEEDCAT000000000000008","测试与质量",[128,129,130,131,132,133],"test","browser","test browser","pr","run","branch"]