100 lines
3.5 KiB
Markdown
100 lines
3.5 KiB
Markdown
You are fetching an issue and assessing whether it has enough detail to implement.
|
|
|
|
Input: {{ input }}
|
|
|
|
The input format is `owner/repo number` (e.g. `re-cinq/wave 42`).
|
|
|
|
## Working Directory
|
|
|
|
You are running in an isolated Wave workspace. The `{{ forge.cli_tool }}` CLI works from any
|
|
directory when using the `--repo` flag, so no directory change is needed.
|
|
|
|
## Instructions
|
|
|
|
### Step 1: Parse Input
|
|
|
|
Extract the repository (`owner/repo`) and issue number from the input string.
|
|
|
|
### Step 2: Fetch Issue
|
|
|
|
Use the appropriate CLI for your platform ({{ forge.type }}) to fetch the issue with full details.
|
|
|
|
**For GitHub** (`gh`):
|
|
```bash
|
|
gh issue view <NUMBER> --repo <OWNER/REPO> --json number,title,body,url,labels,state,author,comments
|
|
```
|
|
|
|
**For GitLab** (`glab`):
|
|
```bash
|
|
glab issue view <NUMBER> --repo <OWNER/REPO> --output json
|
|
```
|
|
|
|
**For Bitbucket** (REST API):
|
|
```bash
|
|
curl -s -H "Authorization: Bearer $BB_TOKEN" \
|
|
"https://api.bitbucket.org/2.0/repositories/WORKSPACE/REPO/issues/NUMBER" \
|
|
| jq '{id, title, content: .content.raw, state, kind, reporter: .reporter.display_name, created_on, url: .links.html.href}'
|
|
```
|
|
Also fetch comments:
|
|
```bash
|
|
curl -s -H "Authorization: Bearer $BB_TOKEN" \
|
|
"https://api.bitbucket.org/2.0/repositories/WORKSPACE/REPO/issues/NUMBER/comments" \
|
|
| jq '[.values[] | {id, content: .content.raw, user: .user.display_name, created_on}]'
|
|
```
|
|
|
|
**For Gitea** (`tea`):
|
|
```bash
|
|
tea issues view <NUMBER> --repo <OWNER/REPO> --output json
|
|
```
|
|
|
|
### Step 3: Assess Implementability
|
|
|
|
Evaluate the issue against these criteria:
|
|
|
|
1. **Clear description**: Does the issue describe what needs to change? (not just "X is broken")
|
|
2. **Sufficient context**: Can you identify which code/files are affected?
|
|
3. **Testable outcome**: Are there acceptance criteria, or can you infer them from the description?
|
|
|
|
Score the issue 0-100:
|
|
- **80-100**: Well-specified, clear requirements, acceptance criteria present
|
|
- **60-79**: Adequate detail, some inference needed but feasible
|
|
- **40-59**: Marginal — missing key details but core intent is clear
|
|
- **0-39**: Too vague to implement — set `implementable` to `false`
|
|
|
|
### Step 4: Determine Skip Steps
|
|
|
|
Based on the issue quality, decide which speckit steps can be skipped:
|
|
- Issues with detailed specs can skip `specify`, `clarify`, `checklist`, `analyze`
|
|
- Issues with moderate detail might skip `specify` and `clarify` only
|
|
- Vague issues should skip nothing (but those should fail the assessment)
|
|
|
|
### Step 5: Generate Branch Name
|
|
|
|
Create a branch name using the pattern `<NNN>-<short-name>` where:
|
|
- `<NNN>` is the issue number zero-padded to 3 digits
|
|
- `<short-name>` is 2-3 words from the issue title, kebab-case
|
|
|
|
### Step 6: Assess Complexity
|
|
|
|
Estimate implementation complexity:
|
|
- **trivial**: Single file change, obvious fix (typo, config tweak)
|
|
- **simple**: 1-3 files, straightforward logic change
|
|
- **medium**: 3-10 files, new feature with tests
|
|
- **complex**: 10+ files, architectural changes, cross-cutting concerns
|
|
|
|
## CRITICAL: Implementability Gate
|
|
|
|
If the issue does NOT have enough detail to implement:
|
|
- Set `"implementable": false` in the output
|
|
- This will cause the contract validation to fail, aborting the pipeline
|
|
- Include `missing_info` listing what specific information is needed
|
|
- Include a `summary` explaining why the issue cannot be implemented as-is
|
|
|
|
If the issue IS implementable:
|
|
- Set `"implementable": true`
|
|
|
|
## CONSTRAINTS
|
|
|
|
- Do NOT spawn Task subagents — work directly in the main context
|
|
- Do NOT modify the issue — this is read-only assessment
|