From 03fc8222aecdccee466780826c46bc0077629332 Mon Sep 17 00:00:00 2001 From: main Date: Fri, 1 May 2026 19:26:13 -0400 Subject: Add pro-plan skill --- README.md | 1 + pro-plan/SKILL.md | 150 ++++++++++++++++++++++++++++++++++++++++++++ pro-plan/agents/openai.yaml | 4 ++ 3 files changed, 155 insertions(+) create mode 100644 pro-plan/SKILL.md create mode 100644 pro-plan/agents/openai.yaml diff --git a/README.md b/README.md index fd64b4e..b146f22 100644 --- a/README.md +++ b/README.md @@ -7,4 +7,5 @@ Current skills: - `assemble-pro-review-package`: throwaway reviewer handoff bundles centered on a single concatenated giga-prompt with aggressively inlined code, logs, and other textual context - `fahrenheit-451`: zero-based documentation purge and consolidation for markdown and plaintext notes - `haussmann`: zero-based Rust source-tree audit and reorganization for layout, module topology, and shared support placement +- `pro-plan`: biphasic Pro planning prompts that lock a rough implementation ask before inlining source context for high-leverage strategic insight - `redline`: logic-preserving wallclock optimization for a locked basket of invocations with measurement-first discipline 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 diff --git a/pro-plan/agents/openai.yaml b/pro-plan/agents/openai.yaml new file mode 100644 index 0000000..5ab1061 --- /dev/null +++ b/pro-plan/agents/openai.yaml @@ -0,0 +1,4 @@ +interface: + display_name: "Pro Plan" + short_description: "Assemble Pro implementation plans" + default_prompt: "Use $pro-plan to lock this rough implementation ask and assemble a Pro planning prompt." -- cgit v1.2.3