Skip to main content

complete-context

Thoroughly interview the user to gather complete context before starting any task. Use when beginning a new project, implementing a feature, debugging an issue, or whenever you need complete understanding of requirements.

ソース情報

リポジトリ
getflamingo/skills
ソースの最終更新活動
2026年4月30日 15:02
検出された SKILL.md の言語
英語
スター
1
フォーク
0

インストール方法

デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。

ソースファイルを確認

インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。

SKILL.md を表示中

SKILL.md
ソースの指示 · 読み取り専用プレビュー
name
complete-context
description
Thoroughly interview the user to gather complete context before starting any task. Use when beginning a new project, implementing a feature, debugging an issue, or whenever you need complete understanding of requirements.
## Purpose This skill ensures you have complete context before proceeding with any task. Incomplete understanding leads to wasted time, incorrect implementations, and frustration. This skill guides you through a systematic interview process to gather every necessary detail. ## When to Activate Activate this skill when: - Starting a new project or feature - Implementing complex functionality - Debugging unclear issues - Refactoring existing code - Making architectural decisions - User provides vague or incomplete requirements - Task involves multiple components or systems ## Interview Process ### Phase 1: High-Level Understanding Start with these fundamental questions: 1. **What is the primary goal?** - What problem are we solving? - What does success look like? - What is the desired outcome? 2. **What is the context?** - Where does this fit in the larger system? - What are the dependencies? - Who are the users/stakeholders? 3. **What are the constraints?** - Time constraints? - Budget constraints? - Technical constraints? - Business constraints? ### Phase 2: Technical Details Ask technical-specific questions: 4. **What is the current state?** - What exists now? - What needs to change? - What stays the same? 5. **What are the requirements?** - Functional requirements? - Non-functional requirements (performance, security, scalability)? - Compliance requirements? 6. **What are the edge cases?** - What happens when X fails? - What are the error conditions? - What are the boundary conditions? ### Phase 3: Implementation Details Dive into implementation specifics: 7. **What are the technical specifications?** - Which technologies/frameworks? - Which programming language? - Which database/storage? - Which APIs/services? 8. **What is the data flow?** - Where does data come from? - How is it processed? - Where does it go? - What transformations occur? 9. **What are the integration points?** - External APIs? - Internal services? - Third-party dependencies? - Database connections? ### Phase 4: Validation and Testing Ensure quality and correctness: 10. **How will we validate the solution?** - What are the acceptance criteria? - How will we test it? - What are the success metrics? 11. **What are the potential risks?** - What could go wrong? - What are the mitigation strategies? - What are the contingency plans? ### Phase 5: Code-Specific Questions If working with code, ask: 12. **What is the codebase structure?** - Which files/directories are relevant? - What is the existing architecture? - What are the coding standards? 13. **What are the existing patterns?** - What patterns are already in use? - Should we follow existing patterns? - Are there anti-patterns to avoid? 14. **What is the deployment context?** - Development/staging/production environments? - CI/CD pipeline? - Deployment process? ## Interview Techniques ### Progressive Disclosure - Start with high-level questions - Drill down into details as needed - Don't overwhelm with all questions at once - Adapt questions based on previous answers ### Clarification - Repeat back what you understand - Ask for confirmation - Paraphrase to ensure accuracy - Flag assumptions explicitly ### Exploration - Ask "what if" scenarios - Explore alternative approaches - Challenge assumptions gently - Consider edge cases proactively ### Codebase Exploration Before asking, explore the codebase: - Read relevant files - Understand existing patterns - Check for similar implementations - Identify dependencies ## Question Templates ### For New Features ``` What feature are we building? Who will use it? What problem does it solve? What are the success criteria? What are the technical requirements? Are there any constraints or limitations? How should it handle errors? What are the edge cases? ``` ### For Bug Fixes ``` What is the bug? What is the expected behavior? What is the actual behavior? When does it occur? What are the steps to reproduce? What is the impact? Are there any workarounds? What is the urgency? ``` ### For Refactoring ``` What needs to be refactored? Why does it need refactoring? What are the goals? What are the risks? What is the scope? Are there any constraints? How will we validate the refactoring? ``` ### For Architecture Decisions ``` What decision are we making? What are the options? What are the trade-offs? What are the constraints? What are the success criteria? How will we measure success? ``` ## Confirmation Checklist Before proceeding, confirm you have: - [ ] Clear understanding of the goal - [ ] Complete requirements specification - [ ] All constraints identified - [ ] Technical approach agreed upon - [ ] Edge cases considered - [ ] Error handling strategy defined - [ ] Testing approach established - [ ] Success criteria defined - [ ] Risks identified and mitigated - [ ] Implementation scope clear ## Common Pitfalls ### Assuming Too Much - Don't assume you know what the user wants - Don't skip questions because you think you know the answer - Don't make assumptions about technical details - Don't assume constraints that haven't been stated ### Asking Too Many Questions at Once - Ask questions progressively - Wait for answers before asking more - Group related questions - Prioritize critical questions first ### Not Exploring the Codebase - Always explore relevant code before asking - Understand existing patterns - Check for similar implementations - Identify dependencies ### Not Confirming Understanding - Always repeat back your understanding - Ask for explicit confirmation - Flag your assumptions - Clarify ambiguities ## When to Stop Interviewing Stop when: - User confirms you have complete understanding - All critical questions have been answered - You can explain the task back to the user accurately - You have enough information to proceed confidently - User indicates they want to move forward ## Example Interview **User**: "I need to add a login feature." **Agent**: Let me ask some questions to ensure I understand completely: 1. What type of login? (username/password, OAuth, SSO, etc.) 2. Which authentication provider? (local database, Auth0, Firebase, etc.) 3. What are the security requirements? (2FA, password complexity, session management) 4. What user information needs to be stored? 5. What happens after login? (redirect to dashboard, show user profile, etc.) 6. What should happen on logout? 7. How should we handle password reset? 8. Are there any compliance requirements? (GDPR, SOC2, etc.) 9. What are the error scenarios? (wrong password, account locked, etc.) 10. What is the UI/UX expectation? Continue asking until you have complete understanding. ## Best Practices - Be thorough but efficient - Adapt questions to the context - Explore the codebase before asking - Confirm understanding before proceeding - Document key decisions - Flag assumptions explicitly - Consider the user's expertise level - Use simple, clear language - Be patient with vague answers - Guide the user to provide complete information
GitHubで見る