init local dev commit

Local Dev/extensive-planning/SKILL.md

@@ -0,0 +1,125 @@
+---
+name: extensive-planning
+description: Use when planning complex feature, architecture, refactor, or implementation work before code changes, especially when the user asks for extensive planning, decisions and questions, research, a report, tests, user stories, or a TDD-ready plan.
+---
+
+# Extensive Planning
+
+## Overview
+
+Use this skill to plan substantial codebase work before implementation. The goal is to understand the existing system, research implementation options, resolve decisions with the user, and produce a final HTML implementation report that is ready for test-driven development.
+
+Do not implement production code while using this skill unless the user explicitly ends planning and asks for implementation.
+
+## Workflow
+
+Move through these stages in order:
+
+1. Review Current Code and Architecture
+2. Research
+3. Decisions and Questions
+4. Discussion
+5. Report
+
+Keep the user oriented by naming the current stage in responses. Do not skip ahead to the Report until every decision and open question has been resolved or explicitly deferred by the user.
+
+## Step 1: Review Current Code and Architecture
+
+Start by inspecting the current project before proposing solutions.
+
+Do the following:
+
+- Identify the repository structure, frameworks, package manager, scripts, and relevant configuration files.
+- Read the files that define the feature area or adjacent architecture.
+- Trace the current data flow, component boundaries, APIs, services, state management, persistence, tests, and build/runtime entry points.
+- Note what is already implemented and what behavior already exists.
+- Separate observed facts from assumptions.
+
+Output a concise current-state summary:
+
+- Current codebase shape
+- Current architecture and data flow
+- Existing behavior related to the requested feature
+- Files/modules likely involved
+- Constraints, conventions, and risks discovered
+
+## Step 2: Research
+
+Research implementation options only after understanding the existing code.
+
+Do the following:
+
+- Search the codebase for existing utilities, patterns, dependencies, plugins, and similar implementations before suggesting new ones.
+- Investigate external libraries, plugins, APIs, or framework features that may help.
+- Prefer official documentation, primary sources, and currently maintained packages when external research is needed.
+- Compare options against the codebase's existing stack, complexity, maintenance cost, bundle/runtime impact, licensing fit, and testability.
+- Avoid adding dependencies when the existing stack can reasonably solve the problem.
+
+Output a research summary:
+
+- Existing internal options
+- External options considered
+- Recommended approach and why
+- Options rejected and why
+- New dependencies that might be needed, if any
+
+## Step 3: Decisions and Questions
+
+List every decision and unclear point before writing the final report.
+
+For decisions:
+
+- Present each decision with clear options, such as Option A, Option B, and Option C.
+- Explain the tradeoffs, risks, and recommended option.
+- Include the concrete implementation impact of each choice.
+
+For questions:
+
+- Ask about unclear requirements, behavior, UX, edge cases, data ownership, API contracts, performance, compatibility, rollout, and preferences.
+- Include only questions that affect implementation.
+- Group related questions so the user can answer efficiently.
+
+End this stage by explicitly asking the user to choose among the listed decisions and answer the open questions.
+
+Do not proceed to the Report in the same response unless the user has already answered everything and explicitly asked for the report.
+
+## Step 4: Discussion
+
+Use this stage for the back-and-forth that resolves Step 3.
+
+Do the following:
+
+- Track which decisions are resolved, which are still open, and which are deferred.
+- Update recommendations when the user gives new information.
+- Ask focused follow-up questions only when they are necessary.
+- Keep the conversation anchored to decisions that affect the plan.
+
+Continue this stage until all decisions and questions are resolved or explicitly deferred. Then ask whether to produce the final Report, unless the user has already requested it.
+
+## Step 5: Report
+
+Before writing the report, read `assets/extensive-planning-report-template.html` and follow its structure.
+
+Reports created with this skill must always be HTML. Produce a complete, standalone `.html` document with semantic sections, readable styling, and the full agreed plan. Do not produce the final report as Markdown, plain text, JSON, or any other format unless the user explicitly overrides this requirement.
+
+Save planning reports and other planning artifacts in the repository root `plans/` folder by default. Create `plans/` if it does not exist. Do not place planning artifacts in `docs/`; `docs/` is for durable project documentation only.
+
+The report must summarize the agreed plan and include:
+
+- Existing implementation, split into reused parts and changed parts.
+- New libraries and packages, including a statement when none are needed.
+- New implementation details, including what changes and how it will work.
+- Refactoring, rewrites, or cleanup needed before or during implementation.
+- Tests and user stories to create before implementation, supporting test-driven development.
+
+Keep the report concrete enough that another Codex session can implement from it without rediscovering the same context.
+
+## Handoff Rules
+
+- Treat the Report as a planning artifact, not implementation.
+- Save the Report as HTML in the repo root `plans/` folder by default, or present it directly only when the user asks not to write a file.
+- Include file paths and module names when known.
+- Mark assumptions clearly.
+- Mark deferred decisions clearly.
+- If the plan requires current external package or API information, verify it before finalizing.
+- If the user asks to implement after the Report, switch to the appropriate implementation workflow and write tests before production code.

Local Dev/extensive-planning/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "Extensive Planning"
+  short_description: "Plan code changes before implementation"
+  default_prompt: "Use $extensive-planning to plan this feature thoroughly before implementation."
+
+policy:
+  allow_implicit_invocation: true