a8fc9c7715
* fix(shellcheck): declare and assign separately in router.sh (SC2155) * feat(plugin): enhance context management and skill invocation - Update .context-manifest.json to include profile and detailed source information. - Revise context-scout.md to clarify context root discovery and navigation. - Modify commands to replace deprecated skills with updated ones (brainstorming → approach, systematic-debugging → debugger). - Streamline install-context.md for clarity and remove interactive profile selection. - Improve oac-status.md to provide a more comprehensive status report. - Add OAC system paths to session-start.sh for better context management. - Remove obsolete skills and improve documentation for existing commands.
95 lines
3.9 KiB
Markdown
95 lines
3.9 KiB
Markdown
---
|
||
name: oac-approach
|
||
description: "Use before any implementation — understands the request, discovers project context, and proposes a concise plan for user approval before writing any code."
|
||
---
|
||
|
||
# Plan Before You Code
|
||
|
||
## Overview
|
||
|
||
Understand the request, discover relevant context, propose a concise plan, get approval. Keep it fast — the goal is alignment, not a design workshop.
|
||
|
||
<HARD-GATE>
|
||
Do NOT write any code or make any file changes until the user has approved your proposed approach.
|
||
</HARD-GATE>
|
||
|
||
## The Process
|
||
|
||
### Step 1: Understand the Request
|
||
|
||
Read the user's message. You already have the "what" — don't ask a series of questions up front. Only ask clarifying questions if:
|
||
- The request is genuinely ambiguous (two different valid interpretations)
|
||
- You discover during context check that key details are missing (e.g. which framework, which database)
|
||
|
||
In those cases, ask the specific questions you need — not a blanket "tell me more". Be explicit about what you need and why.
|
||
|
||
### Step 2: Discover Context
|
||
|
||
Invoke `oac:context-discovery` with the task topic to find relevant project standards and patterns.
|
||
|
||
**If context-discovery reports no context installed:** proceed anyway — note it as "none" in the proposal and include the context hint (see Step 4). Do not pause or ask the user before proposing.
|
||
|
||
**If context found:** note the key files returned — reference them in your proposal.
|
||
|
||
### Step 3: Ask Clarifying Questions (if needed)
|
||
|
||
After reviewing the context and the request, if there are still gaps that would significantly change the approach, ask them now — explicitly and concisely:
|
||
|
||
```
|
||
Before I propose an approach, I need a couple of details:
|
||
|
||
1. {specific question} — because {why it matters to the approach}
|
||
2. {specific question} — because {why it matters to the approach}
|
||
```
|
||
|
||
Keep it to the minimum needed. If you can make a reasonable assumption, state it in the proposal instead of asking.
|
||
|
||
### Step 4: Propose
|
||
|
||
Present a lightweight plan. Short — not a full spec:
|
||
|
||
```
|
||
## Proposed Approach
|
||
|
||
**What**: {1-2 sentence description of what we're building/changing}
|
||
**How**: {brief description of approach — key decisions only}
|
||
**Assumptions**: {any assumptions made where questions weren't asked}
|
||
**Files**: {list of files to create or modify}
|
||
**Context loaded**: {key standards files found, or "none — using general best practices"}
|
||
**External docs needed**: {any library docs to fetch first, or "none"}
|
||
|
||
Approve or let me know what to adjust.
|
||
```
|
||
|
||
**If context was missing or minimal**, append this hint at the end of the proposal — do not replace or interrupt the proposal, just add it after:
|
||
|
||
```
|
||
💡 Tip: For better results tailored to your project's standards, run /install-context
|
||
to set up context files. This helps me follow your coding conventions automatically.
|
||
```
|
||
|
||
### Step 5: Get Approval
|
||
|
||
Wait for the user to approve or adjust. If they adjust, update the proposal and ask again. Do not start implementation until explicitly approved.
|
||
|
||
### Step 6: Hand Off to Implementation
|
||
|
||
Once approved:
|
||
- **Simple** (1–3 files, straightforward): implement directly
|
||
- **Complex** (4+ files, multiple components): invoke `oac:task-breakdown` to create subtasks first
|
||
|
||
## Key Principles
|
||
|
||
- **Fast** — Understand from the message, don't interrogate the user up front
|
||
- **Context first** — Always attempt discovery before proposing
|
||
- **No context = hint, not block** — Show the install tip at the bottom of the proposal, never before it
|
||
- **Explicit questions** — If you must ask, say what you need and why — not "tell me more"
|
||
- **Assumptions over questions** — State assumptions in proposal rather than asking for every detail
|
||
- **Concise proposal** — A paragraph, not a doc; enough for yes/no/adjust
|
||
- **YAGNI** — Propose the minimum that satisfies the requirement
|
||
|
||
## Related
|
||
|
||
- `oac:context-discovery` — invoked in Step 2
|
||
- `oac:context-setup` — when no context found
|
||
- `oac:task-breakdown` — for complex features after approval
|