Add pro-plan skill

1 files changed, 150 insertions, 0 deletions

diff --git a/pro-plan/SKILL.md b/pro-plan/SKILL.md
new file mode 100644
index 0000000..662ad80
--- /dev/null
+++ b/pro-plan/SKILL.md
@@ -0,0 +1,150 @@
+---
+name: pro-plan
+description: "Build a self-contained Pro planning prompt after locally locking a rough feature, refactor, or design ask into concrete goals. Use when the user wants Pro's strategic insight before implementation: hidden structure, optimal types and data structures, elegant architecture, surprising simplifications, non-obvious pitfalls, or a plan shape that an implementation model can cross-check and execute."
+---
+
+# Pro Plan
+
+Use this skill when the user has a rough implementation idea and wants a Pro
+planning pass before coding.
+
+Pro is not being asked to act as a diligent implementation clerk. The local
+model can inspect the repo, run tools, write code, and test the result. Pro is
+being consulted for reach: the rare conceptual move, the hidden trap, the
+cleaner representation, the implementation shape that becomes obvious only
+after staring through the code rather than at it.
+
+The skill is biphasic:
+
+1. lock the ask locally
+2. assemble a self-contained Pro planning prompt from the locked ask and the
+   most insight-bearing context
+
+Do not skip the first phase. A vague prompt produces a vague oracle.
+
+## Phase 1: Lock The Ask
+
+Start from the user's rough sketch. Inspect the repo enough to see the actual
+surfaces involved. Then sharpen the request with the user until it is concrete
+enough to plan against.
+
+Push on:
+
+- desired behavior
+- explicit non-goals
+- affected APIs, data paths, commands, UI surfaces, protocols, or storage formats
+- constraints the implementation must respect
+- acceptance criteria or observable success conditions
+- compatibility, migration, performance, or security constraints when they are
+  actually part of the feature
+- ambiguities that would materially change the implementation
+
+Keep this phase conversational. Do not turn it into a questionnaire unless the
+ask is genuinely under-specified. The point is to converge on a locked target,
+not to create paperwork.
+
+When the scope is clear, write a short locked-ask brief. This brief becomes the
+first inlined section of the Pro prompt. If the user explicitly asks to proceed
+despite uncertainty, name the assumptions instead of pretending they are facts.
+
+## Phase 2: Assemble The Prompt
+
+Create one markdown document under `/tmp` unless the user asks otherwise. Do not
+commit it.
+
+Reuse the inliner from the sibling review-package skill:
+
+`/home/main/programming/projects/skills/assemble-pro-review-package/scripts/inline_section.py`
+
+Use it to append labeled sections and enforce the shared hard token ceiling.
+Do not copy or fork the inlining logic.
+
+Inline material that helps Pro see the true implementation shape:
+
+- the locked-ask brief
+- the domain files where the important concepts live
+- the current implementation around the target behavior
+- representative call sites
+- compact specs, design notes, schemas, or protocol docs
+- prior attempts, audit notes, benchmark notes, or bug reports when they reveal
+  the pressure behind the change
+- tests only when they encode behavior or invariants not obvious from source and
+  prose
+
+Do not dump the repo. Do not include files merely because they are nearby. Spend
+tokens on context that changes the plan.
+
+## Pro Prompt
+
+Address Pro as `you`. Ask for a plan, not code.
+
+The prompt should make clear that Pro has only the inlined context. Use language
+like this:
+
+```markdown
+You are planning an implementation from an inlined repository excerpt. The local
+implementation model will perform a final repository cross-check before editing,
+then implement.
+
+Prioritize:
+- the deepest interpretation of the locked request
+- the cleanest architecture or local representation
+- optimal types and data structures, written explicitly where possible
+- maximal type safety and runtime efficiency
+- hidden constraints, surprising simplifications, and leverage points
+- where the naive implementation would become awkward or wrong
+- the ordered implementation shape
+- assumptions that would materially change the plan
+
+Do not pad the response with generic testing, command, rollout, or risk
+checklists. Mention validation, migration, performance, or security only when
+there is a specific non-obvious issue in this code.
+
+Return a concrete implementation plan that an expert implementation model can
+cross-check against the full repo and then execute. Take your time: we are
+turning to you because we are interested in finding the absolute best possible
+solution.
+```
+
+## Output Shape
+
+The Pro prompt should request a response roughly shaped as:
+
+```markdown
+# Understanding
+
+Restate the locked request in the most precise form.
+
+# Core Insight
+
+Name the main implementation idea, representation, or architectural move.
+
+# Types And Data Structures
+
+Sketch the key types, data structures, invariants, and ownership boundaries
+where the plan benefits from making them explicit.
+
+# Plan
+
+Give the ordered implementation plan. Be concrete enough that another model can
+execute after checking the full repo.
+
+# Non-Obvious Pitfalls
+
+Include only pitfalls specific to this code or request.
+
+# Assumptions
+
+List assumptions that would materially alter the plan if false.
+```
+
+Do not demand sections that are irrelevant to the request. The shape is a
+default, not a cage.
+
+## Final Response To User
+
+Report only:
+
+- prompt document path
+- what context was inlined
+- any assumptions or unresolved scope questions carried into the prompt