본문으로 건너뛰기
cccskills
무료GitHub에 공개

pre-impl-discussion

Evaluate a proposed software change before implementation. It examines project files and official sources, compares options and trade-offs, and builds a concrete plan covering affected systems, effort, risks, and unresolved questions for the user's approval.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

원문원문 설명 보기

Conduct a thorough pre-implementation discussion before making significant changes. Use when the user wants to discuss, plan, or evaluate a change before implementing it — especially when they say words like 'discuss', 'evaluate', 'plan', or 'let's talk about'.

설치 방법 보기

이럴 때 유용합니다

  • Discuss a major change before implementation
  • Compare migration or configuration options
  • Estimate affected files and implementation effort
  • Resolve risks and open questions before approving a plan

포함된 파일(1)

  • SKILL.md5.0 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

Pre-Implementation Discussion

Facilitate a structured, collaborative discussion to evaluate a proposed change before any implementation begins.

Golden Rule

Do NOT implement anything until the user explicitly confirms the final plan and says to proceed. Not even "let me try on a branch" — that's implementation. The user will tell you when discussion is over.

Interaction Style

  • Concise during discussion. Each intermediate response should be short and focused on the current question. Do NOT repeat the full plan in every response.
  • Complete when finalizing. Once the plan is mature and the user asks for it, present a single comprehensive (but terse) summary for final review.
  • Ask, don't assume. When uncertain about project context, constraints, or preferences — ask. The user prefers collaborative discussion over receiving a pre-baked answer.
  • Challenge the premise. Question whether the proposed change is the right one. Suggest simpler alternatives if they exist.
  • Match the user's language. Reply in the same language the user writes in.

Procedure

1. Understand the Current State

Before forming any opinion:

  • Read the relevant source files — configs, code, docs that relate to the change
  • Understand the project structure — what's published vs private, what environments things target, existing constraints
  • Map the impact surface — which files, packages, or systems would be affected
  • Estimate implementation cost — how many files to touch, how much config to rewrite, what could break

Do NOT skip this step. Do NOT rely on assumptions about what "most projects" do.

2. Research Thoroughly

  • Consult official sources — docs, changelogs, migration guides, GitHub issues
  • Verify every claim with evidence. Don't say "X supports Y" without a source. If unsure, say so.
  • Search in parallel to save time — batch independent queries

Common pitfalls:

  • Assuming compatibility without checking actual version constraints
  • Confusing roadmap/aspirations with actual released state
  • Missing transitive constraints (a dependency of a dependency)

3. Present Findings (Concise)

Share a brief assessment. Tables work well for comparisons. Highlight blockers and unknowns prominently — don't bury them in paragraphs.

4. Identify Key Decisions

Surface the decisions the user needs to make. Present them as clear choices with trade-offs, not as a recommendation monologue.

For each decision point:

  • What are the options? (2-3 max)
  • What does each option cost or give up?
  • What's your lean and why? (one sentence)

5. Iterate

The user will ask follow-up questions, raise concerns, or challenge assumptions. For each round:

  • Research if needed — don't answer from instinct when facts are available
  • Answer only what was asked — don't re-present the entire plan
  • Update your mental model based on user feedback

Common mistakes in this phase:

  • Repeating the full plan after every small clarification
  • Answering a narrow question with a broad redesign
  • Treating user questions as confirmation to proceed

6. Finalize the Plan

When the user signals the discussion is converging, present the complete plan once:

  • What changes — concrete list of actions (table or bullet points)
  • Impact surface — what files/systems are affected, estimated effort
  • What does NOT change — explicitly state scope boundaries
  • Risks or open items — anything that needs testing or further verification

Keep it terse. Tables over paragraphs. No explanations the user already heard during discussion.

7. Wait for Confirmation

After presenting the final plan, stop and wait. The user will either:

  • Confirm → then (and only then) proceed to implementation
  • Ask more questions → go back to step 5
  • Modify scope → update the plan and re-present

Anti-Patterns

Don'tDo Instead
Start implementation "to test" without confirmationPresent findings and wait
Repeat the full plan in every responseAnswer the specific question asked
Say "X should work" without checkingSay "I need to verify X" and research it
Assume project structure or constraintsRead the actual files
Present one recommendation as the only optionPresent 2-3 options with trade-offs
Write long paragraphs explaining trade-offsUse tables and bullet points

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

Clean up local Git branches and remote connections left after pull request reviews. The workflow checks unfinished work, preserves main and the current branch, and requests confirmation before force-deleting branches that have not been merged.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Clean up branches after pull request reviews
  • Remove contributor remotes other than origin
  • Review unmerged branches before deletion
alibaba/page-agent3만2026년 10월 18일 업데이트

Maintain an application's supported language models by checking provider availability, adding models, and keeping documentation, live tests, and model-specific request settings aligned. It also checks provider model identifiers and candidates for the recommended list.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Add support for a specific language model
  • Check whether listed models are still available
  • Update provider model identifiers
alibaba/page-agent3만2026년 10월 18일 업데이트

Submit existing local changes as a pull request by reviewing the diff, running project checks, preparing a branch and commit, and pushing to GitHub. It follows contribution rules and preserves template declarations that require human verification.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Submit current local changes as a pull request
  • Prepare a branch and commit following project conventions
  • Run project checks before submission
alibaba/page-agent3만2026년 10월 18일 업데이트

Update a project's changelog using GitHub releases, git history, and code differences. Select changes that matter to users, match the existing format, and write concise entries for the requested release.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Add the latest missing release entry
  • Align changelog text with GitHub Releases
  • Summarize changes between release tags
alibaba/page-agent3만2026년 10월 18일 업데이트

alibaba의 스킬 모두 보기

이 스킬의 문제 신고