ce:plan

安装量: 38
排名: #18813

安装

npx skills add https://github.com/everyinc/compound-engineering-plugin --skill ce:plan
Create a plan for a new feature or bug fix
Introduction
Note: The current year is 2026.
Use this when dating plans and searching for recent documentation.
Transform 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.
Feature Description
#$ARGUMENTS
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."
Do not proceed until you have a clear feature description from the user.
0. Idea Refinement
Check for requirements document first:
Before asking questions, look for recent requirements documents in
docs/brainstorms/
that match this feature:
ls
-la
docs/brainstorms/*-requirements.md
2
>
/dev/null
|
head
-10
Relevance criteria:
A requirements document is relevant if:
The topic (from filename or YAML frontmatter) semantically matches the feature description
Created within the last 14 days
If multiple candidates match, use the most recent one
If a relevant requirements document exists:
Read the source document
thoroughly
— every section matters
Announce: "Found source document from [date]: [topic]. Using as foundation for planning."
Extract and carry forward
ALL
of the following into the plan:
Key decisions and their rationale
Chosen approach and why alternatives were rejected
Problem framing, constraints, and requirements captured during brainstorming
Outstanding questions, preserving whether they block planning or are intentionally deferred
Success criteria and scope boundaries
Dependencies and assumptions, plus any high-level technical direction only when the origin document is inherently technical
Skip the idea refinement questions below
— the source document already answered WHAT to build
Use source document content as the
primary input
to research and planning phases
Critical: The source document is the origin document.
Throughout the plan, reference specific decisions with
(see origin: )
when carrying forward conclusions. Do not paraphrase decisions in a way that loses their original context — link back to the source.
Do not omit source content
— if the source document discussed it, the plan must address it (even if briefly). Scan each section before finalizing the plan to verify nothing was dropped.
If
Resolve Before Planning
contains any items, stop.
Do not proceed with planning. Tell the user planning is blocked by unanswered brainstorm questions and direct them to resume
/ce:brainstorm
or answer those questions first.
If multiple source documents could match:
Use
AskUserQuestion tool
to ask which source document to use, or whether to proceed without one.
If no requirements document is found (or not relevant), run idea refinement:
Refine the idea through collaborative dialogue using the
AskUserQuestion tool
:
Ask questions one at a time to understand the idea fully
Prefer multiple choice questions when natural options exist
Focus on understanding: purpose, constraints and success criteria
Continue until the idea is clear OR user says "proceed"
Gather signals for research decision.
During refinement, note:
User's familiarity
Do they know the codebase patterns? Are they pointing to examples?
User's intent
Speed vs thoroughness? Exploration vs execution?
Topic risk
Security, payments, external APIs warrant more caution
Uncertainty level
Is the approach clear or open-ended? Skip option: If the feature description is already detailed, offer: "Your description is clear. Should I proceed with research, or would you like to refine it further?" Main Tasks 1. Local Research (Always Runs - Parallel) Run these agents in parallel to gather local context: Task compound-engineering:research:repo-research-analyst(feature_description) Task compound-engineering:research:learnings-researcher(feature_description) What to look for: Repo research: existing patterns, AGENTS.md guidance, technology familiarity, pattern consistency Learnings: documented solutions in docs/solutions/ that might apply (gotchas, patterns, lessons learned) These findings inform the next step. 1.5. Research Decision Based on signals from Step 0 and findings from Step 1, decide on external research. 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. Strong local context -> skip external research. Codebase has good patterns, AGENTS.md has guidance, user knows what they want. External research adds little value. Uncertainty or unfamiliar territory → research. User is exploring, codebase has no examples, new technology. External perspective is valuable. Announce the decision and proceed. Brief explanation, then continue. User can redirect if needed. Examples: "Your codebase has solid patterns for this. Proceeding without external research." "This involves payment processing, so I'll research current best practices first." 1.5b. External Research (Conditional) Only run if Step 1.5 indicates external research is valuable. Run these agents in parallel: Task compound-engineering:research:best-practices-researcher(feature_description) Task compound-engineering:research:framework-docs-researcher(feature_description) 1.6. Consolidate Research After all research steps complete, consolidate findings: Document relevant file paths from repo research (e.g., app/services/example_service.rb:42 ) Include relevant institutional learnings from docs/solutions/ (key insights, gotchas to avoid) Note external documentation URLs and best practices (if external research was done) List related issues or PRs discovered Capture AGENTS.md conventions Optional validation: Briefly summarize findings and ask if anything looks off or missing before proceeding to planning. 2. Issue Planning & Structure Title & Categorization: Draft clear, searchable issue title using conventional format (e.g., feat: Add user authentication , fix: Cart total calculation ) Determine issue type: enhancement, bug, refactor Convert title to filename: add today's date prefix, determine daily sequence number, strip prefix colon, kebab-case, add -plan suffix Scan docs/plans/ for files matching today's date pattern YYYY-MM-DD-\d{3}- Find the highest existing sequence number for today Increment by 1, zero-padded to 3 digits (001, 002, etc.) Example: feat: Add User Authentication → 2026-01-21-001-feat-add-user-authentication-plan.md Keep it descriptive (3-5 words after prefix) so plans are findable by context Stakeholder Analysis: Identify who will be affected by this issue (end users, developers, operations) Consider implementation complexity and required expertise Content Planning: Choose appropriate detail level based on issue complexity and audience List all necessary sections for the chosen template Gather supporting materials (error logs, screenshots, design mockups) Prepare code examples or reproduction steps if applicable, name the mock filenames in the lists 3. SpecFlow Analysis After planning the issue structure, run SpecFlow Analyzer to validate and refine the feature specification: Task compound-engineering:workflow:spec-flow-analyzer(feature_description, research_findings) SpecFlow Analyzer Output: Review SpecFlow analysis results Incorporate any identified gaps or edge cases into the issue Update acceptance criteria based on SpecFlow findings 4. Choose Implementation Detail Level Select how comprehensive you want the issue to be, simpler is mostly better. 📄 MINIMAL (Quick Issue) Best for: Simple bugs, small improvements, clear features Includes: Problem statement or feature description Basic acceptance criteria Essential context only Structure:

title : [ Issue Title ] type : [ feat | fix | refactor ] status : active date : YYYY - MM - DD origin : docs/brainstorms/YYYY - MM - DD - <topic

- requirements.md

if originated from a requirements doc, otherwise omit


[Issue Title] [Brief problem/feature description]

Acceptance Criteria

[ ] Core requirement 1

[ ] Core requirement 2

Context [Any critical information]

MVP

test.rb

ruby
class
Test
def
initialize
@name
=
"test"
end
end

Sources

** Origin document: ** docs/brainstorms/YYYY-MM-DD--requirements.md — include if plan originated from an upstream requirements doc - Related issue: #[issue_number] - Documentation: [relevant_docs_url] 📋 MORE (Standard Issue) Best for: Most features, complex bugs, team collaboration Includes everything from MINIMAL plus: Detailed background and motivation Technical considerations Success metrics Dependencies and risks Basic implementation suggestions Structure:


title : [ Issue Title ] type : [ feat | fix | refactor ] status : active date : YYYY - MM - DD origin : docs/brainstorms/YYYY - MM - DD - <topic

- requirements.md

if originated from a requirements doc, otherwise omit


[Issue Title]

Overview [Comprehensive description]

Problem Statement / Motivation [Why this matters]

Proposed Solution [High-level approach]

Technical Considerations

Architecture impacts

Performance implications

Security considerations

System-Wide Impact

**
Interaction graph
**

[What callbacks/middleware/observers fire when this runs?]

**
Error propagation
**

[How do errors flow across layers? Do retry strategies align?]

**
State lifecycle risks
**

[Can partial failure leave orphaned/inconsistent state?]

**
API surface parity
**

[What other interfaces expose similar functionality and need the same change?]

**
Integration test scenarios
**
[Cross-layer scenarios that unit tests won't catch]

Acceptance Criteria

[ ] Detailed requirement 1

[ ] Detailed requirement 2

[ ] Testing requirements

Success Metrics [How we measure success]

Dependencies & Risks [What could block or complicate this]

Sources & References

** Origin document: ** docs/brainstorms/YYYY-MM-DD--requirements.md — include if plan originated from an upstream requirements doc - Similar implementations: [file_path:line_number] - Best practices: [documentation_url] - Related PRs: #[pr_number] 📚 A LOT (Comprehensive Issue) Best for: Major features, architectural changes, complex integrations Includes everything from MORE plus: Detailed implementation plan with phases Alternative approaches considered Extensive technical specifications Resource requirements and timeline Future considerations and extensibility Risk mitigation strategies Documentation requirements Structure:


title : [ Issue Title ] type : [ feat | fix | refactor ] status : active date : YYYY - MM - DD origin : docs/brainstorms/YYYY - MM - DD - <topic

- requirements.md

if originated from a requirements doc, otherwise omit


[Issue Title]

Overview [Executive summary]

Problem Statement [Detailed problem analysis]

Proposed Solution [Comprehensive solution design]

Technical Approach

Architecture [Detailed technical design]

Implementation Phases

Phase 1: [Foundation]

Tasks and deliverables

Success criteria

Estimated effort

Phase 2: [Core Implementation]

Tasks and deliverables

Success criteria

Estimated effort

Phase 3: [Polish & Optimization]

Tasks and deliverables

Success criteria

Estimated effort

Alternative Approaches Considered [Other solutions evaluated and why rejected]

System-Wide Impact

Interaction Graph [Map the chain reaction: what callbacks, middleware, observers, and event handlers fire when this code runs? Trace at least two levels deep. Document: "Action X triggers Y, which calls Z, which persists W."]

Error & Failure Propagation [Trace errors from lowest layer up. List specific error classes and where they're handled. Identify retry conflicts, unhandled error types, and silent failure swallowing.]

State Lifecycle Risks [Walk through each step that persists state. Can partial failure orphan rows, duplicate records, or leave caches stale? Document cleanup mechanisms or their absence.]

API Surface Parity [List all interfaces (classes, DSLs, endpoints) that expose equivalent functionality. Note which need updating and which share the code path.]

Integration Test Scenarios [3-5 cross-layer test scenarios that unit tests with mocks would never catch. Include expected behavior for each.]

Acceptance Criteria

Functional Requirements

[ ] Detailed functional criteria

Non-Functional Requirements

[ ] Performance targets

[ ] Security requirements

[ ] Accessibility standards

Quality Gates

[ ] Test coverage requirements

[ ] Documentation completeness

[ ] Code review approval

Success Metrics [Detailed KPIs and measurement methods]

Dependencies & Prerequisites [Detailed dependency analysis]

Risk Analysis & Mitigation [Comprehensive risk assessment]

Resource Requirements [Team, time, infrastructure needs]

Future Considerations [Extensibility and long-term vision]

Documentation Plan [What docs need updating]

Sources & References

Origin

** Origin document: ** docs/brainstorms/YYYY-MM-DD--requirements.md — include if plan originated from an upstream requirements doc. Key decisions carried forward: [list 2-3 major decisions from the origin]

Internal References

Architecture decisions: [file_path:line_number]

Similar features: [file_path:line_number]

Configuration: [file_path:line_number]

External References

Framework documentation: [url]

Best practices guide: [url]

Industry standards: [url]

Previous PRs: #[pr_numbers]

Design documents: [links] 5. Issue Creation & Formatting Content Formatting: Use clear, descriptive headings with proper hierarchy (##, ###) Include code examples in triple backticks with language syntax highlighting Add screenshots/mockups if UI-related (drag & drop or use image hosting) Use task lists (- [ ]) for trackable items that can be checked off Add collapsible sections for lengthy logs or optional details using

tags Apply appropriate emoji for visual scanning (🐛 bug, ✨ feature, 📚 docs, ♻️ refactor) Cross-Referencing: Link to related issues/PRs using #number format Reference specific commits with SHA hashes when relevant Link to code using GitHub's permalink feature (press 'y' for permanent link) Mention relevant team members with @username if needed Add links to external resources with descriptive text Code & Examples: # Good example with syntax highlighting and line references
ruby
# app/services/user_service.rb:42
def
process_user
(
user
)
# Implementation here
end
# Collapsible error logs < details > < summary > Full error stacktrace `Error details here...`

AI-Era Considerations: Account for accelerated development with AI pair programming Include prompts or instructions that worked well during research Note which AI tools were used for initial exploration (Claude, Copilot, etc.) Emphasize comprehensive testing given rapid implementation Document any AI-generated code that needs human review 6. Final Review & Submission Origin document cross-check (if plan originated from a requirements doc): Before finalizing, re-read the origin document and verify: Every key decision from the origin document is reflected in the plan The chosen approach matches what was decided in the origin document Constraints and requirements from the origin document are captured in acceptance criteria Open questions from the origin document are either resolved or flagged The origin: frontmatter field points to the correct source file The Sources section includes the origin document with a summary of carried-forward decisions Pre-submission Checklist: Title is searchable and descriptive Labels accurately categorize the issue All template sections are complete Links and references are working Acceptance criteria are measurable Add names of files in pseudo code examples and todo lists Add an ERD mermaid diagram if applicable for new model changes Write Plan File REQUIRED: Write the plan file to disk before presenting any options. mkdir -p docs/plans/

Determine daily sequence number

today

$( date +%Y-%m-%d ) last_seq = $( ls docs/plans/$ { today } -*-plan.md 2

/dev/null | grep -oP " ${today} -\K\d{3}" | sort -n | tail -1 ) next_seq = $( printf "%03d" $(( $ { last_seq:-0 } + 1 ) ) ) Use the Write tool to save the complete plan to docs/plans/YYYY-MM-DD-NNN---plan.md (where NNN is $next_seq from the bash command above). This step is mandatory and cannot be skipped — even when running as part of LFG/SLFG or other automated pipelines. Confirm: "Plan written to docs/plans/[filename]" Pipeline mode: If invoked from an automated workflow (LFG, SLFG, or any disable-model-invocation context), skip all AskUserQuestion calls. Make decisions automatically and proceed to writing the plan without interactive prompts. Output Format Filename: Use the date, daily sequence number, and kebab-case filename from Step 2 Title & Categorization. docs/plans/YYYY-MM-DD-NNN---plan.md Examples: ✅ docs/plans/2026-01-15-001-feat-user-authentication-flow-plan.md ✅ docs/plans/2026-02-03-001-fix-checkout-race-condition-plan.md ✅ docs/plans/2026-03-10-002-refactor-api-client-extraction-plan.md ❌ docs/plans/2026-01-15-feat-thing-plan.md (missing sequence number, not descriptive) ❌ docs/plans/2026-01-15-001-feat-new-feature-plan.md (too vague - what feature?) ❌ docs/plans/2026-01-15-001-feat: user auth-plan.md (invalid characters - colon and space) ❌ docs/plans/feat-user-auth-plan.md (missing date prefix and sequence number) Post-Generation Options After writing the plan file, use the AskUserQuestion tool to present these options: Question: "Plan ready at docs/plans/YYYY-MM-DD-NNN---plan.md . What would you like to do next?" Options: Open plan in editor - Open the plan file for review Run /deepen-plan - Enhance each section with parallel research agents (best practices, performance, UI) Review and refine - Improve the document through structured self-review Share to Proof - Upload to Proof for collaborative review and sharing Start /ce:work - Begin implementing this plan locally Start /ce:work on remote - Begin implementing in Claude Code on the web (use & to run in background) Create Issue - Create issue in project tracker (GitHub/Linear) Based on selection: Open plan in editor → Run open docs/plans/.md to open the file in the user's default editor /deepen-plan → Call the /deepen-plan command with the plan file path to enhance with research Review and refine → Load document-review skill. Share to Proof → Upload the plan to Proof: CONTENT = $( cat docs/plans/ < plan_filename

.md ) TITLE = "Plan: " RESPONSE = $( curl -s -X POST https://www.proofeditor.ai/share/markdown \ -H "Content-Type: application/json" \ -d " $( jq -n --arg title " $TITLE " --arg markdown " $CONTENT " --arg by "ai:compound" '{title: $title, markdown: $markdown, by: $by}' ) " ) PROOF_URL = $( echo " $RESPONSE " | jq -r '.tokenUrl' ) Display: View & collaborate in Proof: — skip silently if curl fails. Then return to options. /ce:work → Call the /ce:work command with the plan file path /ce:work on remote → Run /ce:work docs/plans/.md & to start work in background for Claude Code web Create Issue → See "Issue Creation" section below Other (automatically provided) → Accept free text for rework or specific changes Note: If running /ce:plan with ultrathink enabled, automatically run /deepen-plan after plan creation for maximum depth and grounding. Loop back to options after Simplify or Other changes until user selects /ce:work or another action. Issue Creation When user selects "Create Issue", detect their project tracker from AGENTS.md: Check for tracker preference in the user's AGENTS.md (global or project). If AGENTS.md is absent, fall back to CLAUDE.md: Look for project_tracker: github or project_tracker: linear Or look for mentions of "GitHub Issues" or "Linear" in their workflow section If GitHub: Use the title and type from Step 2 (already in context - no need to re-read the file): gh issue create --title ": " --body-file < plan_path</p> <p>If Linear: linear issue create --title "<title>" --description " $( cat < plan_path</p> <p>) " If no tracker configured: Ask user: "Which project tracker do you use? (GitHub/Linear/Other)" Suggest adding project_tracker: github or project_tracker: linear to their AGENTS.md After creation: Display the issue URL Ask if they want to proceed to /ce:work NEVER CODE! Just research and write the plan.</p> </blockquote> </article> <a href="/" class="back-link">← <span data-i18n="detail.backToLeaderboard">返回排行榜</span></a> </div> <aside class="sidebar"> <section class="related-skills" id="relatedSkillsSection"> <h2 class="related-title" data-i18n="detail.relatedSkills">相关 Skills</h2> <div class="related-list" id="relatedSkillsList"> <div class="skeleton-card"></div> <div class="skeleton-card"></div> <div class="skeleton-card"></div> </div> </section> </aside> </div> </div> <script src="https://unpkg.com/i18next@23.11.5/i18next.min.js" defer></script> <script src="https://unpkg.com/i18next-browser-languagedetector@7.2.1/i18nextBrowserLanguageDetector.min.js" defer></script> <script defer> // Language resources - same pattern as index page const resources = { 'zh-CN': null, 'en': null, 'ja': null, 'ko': null, 'zh-TW': null, 'es': null, 'fr': null }; // Load language files (only current + fallback for performance) async function loadLanguageResources() { const savedLang = localStorage.getItem('i18nextLng') || 'en'; const langsToLoad = new Set([savedLang, 'en']); // current + fallback await Promise.all([...langsToLoad].map(async (lang) => { try { const response = await fetch(`/locales/${lang}.json`); if (response.ok) { resources[lang] = { translation: await response.json() }; } } catch (error) { console.warn(`Failed to load ${lang} language file:`, error); } })); } // Load a single language on demand (for language switching) async function loadLanguage(lang) { if (resources[lang]) return; try { const response = await fetch(`/locales/${lang}.json`); if (response.ok) { resources[lang] = { translation: await response.json() }; i18next.addResourceBundle(lang, 'translation', resources[lang].translation); } } catch (error) { console.warn(`Failed to load ${lang} language file:`, error); } } // Initialize i18next async function initI18n() { try { await loadLanguageResources(); // Filter out null values from resources const validResources = {}; for (const [lang, data] of Object.entries(resources)) { if (data !== null) { validResources[lang] = data; } } console.log('Loaded languages:', Object.keys(validResources)); console.log('zh-CN resource:', validResources['zh-CN']); console.log('detail.home in resource:', validResources['zh-CN']?.translation?.detail?.home); // 检查是否有保存的语言偏好 const savedLang = localStorage.getItem('i18nextLng'); // 如果没有保存的语言偏好,默认使用英文 const defaultLang = savedLang && ['zh-CN', 'en', 'ja', 'ko', 'zh-TW', 'es', 'fr'].includes(savedLang) ? savedLang : 'en'; await i18next .use(i18nextBrowserLanguageDetector) .init({ lng: defaultLang, // 强制设置初始语言 fallbackLng: 'en', supportedLngs: ['zh-CN', 'en', 'ja', 'ko', 'zh-TW', 'es', 'fr'], resources: validResources, detection: { order: ['localStorage'], // 只使用 localStorage,不检测浏览器语言 caches: ['localStorage'], lookupLocalStorage: 'i18nextLng' }, interpolation: { escapeValue: false } }); console.log('i18next initialized, language:', i18next.language); console.log('Test translation:', i18next.t('detail.home')); // Set initial language in selector const langSwitcher = document.getElementById('langSwitcher'); langSwitcher.value = i18next.language; // Update page language updatePageLanguage(); // Language switch event langSwitcher.addEventListener('change', async (e) => { await loadLanguage(e.target.value); // load on demand i18next.changeLanguage(e.target.value).then(() => { updatePageLanguage(); localStorage.setItem('i18nextLng', e.target.value); }); }); } catch (error) { console.error('i18next init failed:', error); } } // Translation helper function t(key, options = {}) { return i18next.t(key, options); } // Update all translatable elements function updatePageLanguage() { // Update HTML lang attribute document.documentElement.lang = i18next.language; // Update elements with data-i18n attribute document.querySelectorAll('[data-i18n]').forEach(el => { const key = el.getAttribute('data-i18n'); el.textContent = t(key); }); } // Copy command function function copyCommand() { const command = document.getElementById('installCommand').textContent; const btn = document.getElementById('copyBtn'); navigator.clipboard.writeText(command).then(() => { btn.textContent = t('copied'); btn.classList.add('copied'); setTimeout(() => { btn.textContent = t('copy'); btn.classList.remove('copied'); }, 2000); }).catch(() => { // Fallback for non-HTTPS const textArea = document.createElement('textarea'); textArea.value = command; textArea.style.position = 'fixed'; textArea.style.left = '-9999px'; document.body.appendChild(textArea); textArea.select(); document.execCommand('copy'); document.body.removeChild(textArea); btn.textContent = t('copied'); btn.classList.add('copied'); setTimeout(() => { btn.textContent = t('copy'); btn.classList.remove('copied'); }, 2000); }); } // Initialize document.getElementById('copyBtn').addEventListener('click', copyCommand); initI18n(); // 异步加载相关 Skills async function loadRelatedSkills() { const owner = 'everyinc'; const skillName = 'ce:plan'; const currentLang = 'fr'; const listContainer = document.getElementById('relatedSkillsList'); const section = document.getElementById('relatedSkillsSection'); try { const response = await fetch(`/api/related-skills/${encodeURIComponent(owner)}/${encodeURIComponent(skillName)}?limit=6`); if (!response.ok) { throw new Error('Failed to load'); } const data = await response.json(); const relatedSkills = data.related_skills || []; if (relatedSkills.length === 0) { // 没有相关推荐时隐藏整个区域 section.style.display = 'none'; return; } // 渲染相关 Skills listContainer.innerHTML = relatedSkills.map(skill => { const desc = skill.description || ''; const truncatedDesc = desc.length > 60 ? desc.substring(0, 60) + '...' : desc; return ` <a href="${currentLang === 'en' ? '' : '/' + currentLang}/skill/${skill.owner}/${skill.repo}/${skill.skill_name}" class="related-card"> <div class="related-name">${escapeHtml(skill.skill_name)}</div> <div class="related-meta"> <span class="related-owner">${escapeHtml(skill.owner)}</span> <span class="related-installs">${skill.installs}</span> </div> <div class="related-desc">${escapeHtml(truncatedDesc)}</div> </a> `; }).join(''); } catch (error) { console.error('Failed to load related skills:', error); // 加载失败时显示提示或隐藏 listContainer.innerHTML = '<div class="related-empty">暂无相关推荐</div>'; } } // HTML 转义 function escapeHtml(text) { const div = document.createElement('div'); div.textContent = text; return div.innerHTML; } // 页面加载完成后异步加载相关 Skills if (document.readyState === 'loading') { document.addEventListener('DOMContentLoaded', loadRelatedSkills); } else { loadRelatedSkills(); } </script> </body> </html>