fix: init skill avoids brainstorming interception, detects existing specs
This commit is contained in:
@@ -1,19 +1,21 @@
|
|||||||
---
|
---
|
||||||
name: init
|
name: init
|
||||||
description: Initialize the agent loop harness in the current project. Scaffolds .loop/ directory, detects tech stack, picks mode, generates config, and flows into planning.
|
description: "Setup task: scaffold .loop/ directory and generate config for the agent loop harness. Not a creative task — do not brainstorm or generate ideas. Reads existing specs if present."
|
||||||
---
|
---
|
||||||
|
|
||||||
# /init — Initialize Agent Loop for a Project
|
# /init — Initialize Agent Loop for a Project
|
||||||
|
|
||||||
Set up the agent loop harness in the current project. This is the entry point for first-time use.
|
Set up the agent loop harness in the current project. This is infrastructure setup, not creative work.
|
||||||
|
|
||||||
|
**IMPORTANT:** Do NOT invoke brainstorming, planning, or idea-generation skills. This skill handles its own flow. If the user wants to brainstorm first, they should do that separately before running this skill.
|
||||||
|
|
||||||
## What This Skill Does
|
## What This Skill Does
|
||||||
|
|
||||||
1. Scaffolds the `.loop/` directory with prompts, templates, and lib scripts from the plugin
|
1. Checks for existing specs/plans in the project (uses them if found)
|
||||||
2. Analyzes the project to understand its tech stack, structure, and conventions
|
2. Scaffolds the `.loop/` directory
|
||||||
3. Asks the user what they want to accomplish (explore, implement, or fix)
|
3. Detects tech stack
|
||||||
4. Creates project-specific configuration (`config.json`, `init.sh`)
|
4. Picks mode and generates config
|
||||||
5. Flows into planning to generate the PRD and sprint contracts
|
5. Flows into `/agent-loop:plan` to decompose the spec into stories
|
||||||
|
|
||||||
## Instructions
|
## Instructions
|
||||||
|
|
||||||
@@ -56,17 +58,23 @@ archive/
|
|||||||
|
|
||||||
**If `.loop/` already exists**, ask the user if they want to re-initialize (which resets config but preserves prd.json/progress.md if they exist).
|
**If `.loop/` already exists**, ask the user if they want to re-initialize (which resets config but preserves prd.json/progress.md if they exist).
|
||||||
|
|
||||||
### Step 1: Project Discovery
|
### Step 1: Check for Existing Specs
|
||||||
|
|
||||||
Read the project to understand what we're working with:
|
Search for existing design documents or specs in the project:
|
||||||
- Check for `CLAUDE.md`, `AGENTS.md`, `README.md` at the project root
|
- `docs/superpowers/specs/*.md`
|
||||||
- Check for `package.json`, `Cargo.toml`, `pyproject.toml`, `go.mod`, `Package.swift`, `composer.json` to identify the tech stack
|
- `docs/specs/*.md`
|
||||||
- Run `ls` on the project root to see the top-level structure
|
- `docs/*.md` (that look like feature specs)
|
||||||
|
- `SPEC.md`, `PRD.md`, `DESIGN.md` at root
|
||||||
|
- Any markdown file that contains design/architecture/requirements content
|
||||||
|
|
||||||
Present a brief summary:
|
**If a spec is found:**
|
||||||
> "I see this is a [language/framework] project with [key characteristics]. The main source is in [dir/]."
|
> "I found an existing spec at `{path}`. I'll use this as the basis for generating stories."
|
||||||
|
|
||||||
### Step 2: Mode Selection
|
Read the spec and use it as input for planning. Do NOT ask the user to re-describe what they want — the spec already has it. Skip to Step 3 (mode is almost certainly **implement**).
|
||||||
|
|
||||||
|
**If no spec is found**, proceed to Step 2.
|
||||||
|
|
||||||
|
### Step 2: Mode Selection and Description
|
||||||
|
|
||||||
Ask the user:
|
Ask the user:
|
||||||
|
|
||||||
@@ -76,28 +84,25 @@ Ask the user:
|
|||||||
> b) **Implement** — Build a new feature from a PRD. Code changes, commits, and tests.
|
> b) **Implement** — Build a new feature from a PRD. Code changes, commits, and tests.
|
||||||
> c) **Fix** — Work through a list of bugs or tech debt items. Targeted code changes.
|
> c) **Fix** — Work through a list of bugs or tech debt items. Targeted code changes.
|
||||||
|
|
||||||
### Step 3: Clarifying Questions
|
Based on the mode, ask 2-3 brief clarifying questions. Do NOT over-interview — keep it focused:
|
||||||
|
|
||||||
Based on the mode, ask 3-5 questions:
|
**For Implement:** "Describe the feature in 1-3 sentences."
|
||||||
|
**For Explore:** "What areas should I focus on?"
|
||||||
|
**For Fix:** "Do you have a list of issues, or should I find them?"
|
||||||
|
|
||||||
**For Explore:**
|
### Step 3: Project Discovery
|
||||||
- "What areas are you most interested in? (e.g., auth, database, API, frontend, everything)"
|
|
||||||
- "Are there known problem areas you want me to focus on?"
|
|
||||||
- "How many exploration sessions should I budget? (default: 20)"
|
|
||||||
|
|
||||||
**For Implement:**
|
Read the project to understand what we're working with:
|
||||||
- "Describe the feature you want to build (1-3 sentences is fine)"
|
- Check for `CLAUDE.md`, `AGENTS.md`, `README.md` at the project root
|
||||||
- "Are there any architectural constraints I should know about?"
|
- Check for `package.json`, `Cargo.toml`, `pyproject.toml`, `go.mod`, `Package.swift`, `composer.json` to identify the tech stack
|
||||||
- "Should I follow any specific patterns from the existing codebase?"
|
- Run `ls` on the project root to see the top-level structure
|
||||||
|
|
||||||
**For Fix:**
|
Present a brief summary:
|
||||||
- "Do you have a list of issues, or should I find them?"
|
> "I see this is a [language/framework] project with [key characteristics]."
|
||||||
- "Any areas that are off-limits for changes?"
|
|
||||||
- "What's the priority: security, stability, or code quality?"
|
|
||||||
|
|
||||||
### Step 4: Generate Configuration
|
### Step 4: Generate Configuration
|
||||||
|
|
||||||
Create `.loop/config.json` based on the project and user's answers:
|
Create `.loop/config.json` based on the project:
|
||||||
|
|
||||||
```json
|
```json
|
||||||
{
|
{
|
||||||
@@ -114,28 +119,11 @@ Create `.loop/config.json` based on the project and user's answers:
|
|||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
Create `.loop/init.sh` with project-specific setup commands:
|
Create `.loop/init.sh` with project-specific setup commands (dev server, test runner, linter, etc.). Make it executable.
|
||||||
- Dev server startup (if applicable)
|
|
||||||
- Test runner command
|
|
||||||
- Type checker command
|
|
||||||
- Linter command
|
|
||||||
- Any environment setup needed
|
|
||||||
|
|
||||||
Make `init.sh` executable.
|
|
||||||
|
|
||||||
### Step 5: Flow into Planning
|
### Step 5: Flow into Planning
|
||||||
|
|
||||||
Tell the user:
|
Tell the user:
|
||||||
> "Project configured. Now let's plan the work."
|
> "Project configured. Generating stories from {spec name / user description}..."
|
||||||
|
|
||||||
Then invoke the `/agent-loop:plan` skill to generate the PRD and sprint contracts.
|
Then invoke `/agent-loop:plan` to generate the PRD and sprint contracts. If a spec was found in Step 1, pass it as context so the plan skill uses it directly.
|
||||||
|
|
||||||
### Step 6: Ready to Run
|
|
||||||
|
|
||||||
Once planning is complete, tell the user:
|
|
||||||
> "Everything is set up. To start the loop:"
|
|
||||||
> ```
|
|
||||||
> /agent-loop:run # Interactive (recommended) — visible, can intervene
|
|
||||||
> .loop/loop.sh # Headless — fully autonomous
|
|
||||||
> ```
|
|
||||||
> You can monitor progress in `.loop/progress.md` and check story status in `.loop/prd.json`.
|
|
||||||
|
|||||||
Reference in New Issue
Block a user