Add Gitea issue pipelines and prompts using tea CLI
gt-issue-impl, gt-issue-research, gt-issue-rewrite, gt-issue-update pipelines with corresponding prompts. Mirrors the gh-issue-* variants but uses tea CLI with --login librete for Gitea authentication. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
121
.wave/pipelines/gt-issue-impl.yaml
Normal file
121
.wave/pipelines/gt-issue-impl.yaml
Normal file
@@ -0,0 +1,121 @@
|
||||
kind: WavePipeline
|
||||
metadata:
|
||||
name: gt-issue-impl
|
||||
description: "Implement a Gitea issue end-to-end: fetch, assess, plan, implement, create PR"
|
||||
|
||||
input:
|
||||
source: cli
|
||||
schema:
|
||||
type: string
|
||||
description: "Gitea repository and issue number"
|
||||
example: "public/librenotes 42"
|
||||
|
||||
steps:
|
||||
- id: fetch-assess
|
||||
persona: implementer
|
||||
workspace:
|
||||
type: worktree
|
||||
branch: "{{ pipeline_id }}"
|
||||
exec:
|
||||
type: prompt
|
||||
source_path: .wave/prompts/gitea-issue-impl/fetch-assess.md
|
||||
output_artifacts:
|
||||
- name: assessment
|
||||
path: .wave/output/issue-assessment.json
|
||||
type: json
|
||||
handover:
|
||||
contract:
|
||||
type: json_schema
|
||||
source: .wave/output/issue-assessment.json
|
||||
schema_path: .wave/contracts/issue-assessment.schema.json
|
||||
must_pass: true
|
||||
on_failure: retry
|
||||
max_retries: 2
|
||||
|
||||
- id: plan
|
||||
persona: implementer
|
||||
dependencies: [fetch-assess]
|
||||
memory:
|
||||
inject_artifacts:
|
||||
- step: fetch-assess
|
||||
artifact: assessment
|
||||
as: issue_assessment
|
||||
workspace:
|
||||
type: worktree
|
||||
branch: "{{ pipeline_id }}"
|
||||
base: main
|
||||
exec:
|
||||
type: prompt
|
||||
source_path: .wave/prompts/gitea-issue-impl/plan.md
|
||||
output_artifacts:
|
||||
- name: impl-plan
|
||||
path: .wave/output/impl-plan.json
|
||||
type: json
|
||||
handover:
|
||||
contract:
|
||||
type: json_schema
|
||||
source: .wave/output/impl-plan.json
|
||||
schema_path: .wave/contracts/issue-impl-plan.schema.json
|
||||
must_pass: true
|
||||
on_failure: retry
|
||||
max_retries: 2
|
||||
|
||||
- id: implement
|
||||
persona: craftsman
|
||||
dependencies: [plan]
|
||||
memory:
|
||||
inject_artifacts:
|
||||
- step: fetch-assess
|
||||
artifact: assessment
|
||||
as: issue_assessment
|
||||
- step: plan
|
||||
artifact: impl-plan
|
||||
as: plan
|
||||
workspace:
|
||||
type: worktree
|
||||
branch: "{{ pipeline_id }}"
|
||||
exec:
|
||||
type: prompt
|
||||
source_path: .wave/prompts/gitea-issue-impl/implement.md
|
||||
handover:
|
||||
contract:
|
||||
type: test_suite
|
||||
command: "{{ project.test_command }}"
|
||||
must_pass: true
|
||||
on_failure: retry
|
||||
max_retries: 3
|
||||
compaction:
|
||||
trigger: "token_limit_80%"
|
||||
persona: summarizer
|
||||
|
||||
- id: create-pr
|
||||
persona: craftsman
|
||||
dependencies: [implement]
|
||||
memory:
|
||||
inject_artifacts:
|
||||
- step: fetch-assess
|
||||
artifact: assessment
|
||||
as: issue_assessment
|
||||
workspace:
|
||||
type: worktree
|
||||
branch: "{{ pipeline_id }}"
|
||||
exec:
|
||||
type: prompt
|
||||
source_path: .wave/prompts/gitea-issue-impl/create-pr.md
|
||||
output_artifacts:
|
||||
- name: pr-result
|
||||
path: .wave/output/pr-result.json
|
||||
type: json
|
||||
handover:
|
||||
contract:
|
||||
type: json_schema
|
||||
source: .wave/output/pr-result.json
|
||||
schema_path: .wave/contracts/pr-result.schema.json
|
||||
must_pass: true
|
||||
on_failure: retry
|
||||
max_retries: 2
|
||||
outcomes:
|
||||
- type: pr
|
||||
extract_from: .wave/output/pr-result.json
|
||||
json_path: .pr_url
|
||||
label: "Pull Request"
|
||||
257
.wave/pipelines/gt-issue-research.yaml
Normal file
257
.wave/pipelines/gt-issue-research.yaml
Normal file
@@ -0,0 +1,257 @@
|
||||
kind: WavePipeline
|
||||
metadata:
|
||||
name: gt-issue-research
|
||||
description: Research a Gitea issue and post findings as a comment
|
||||
release: true
|
||||
|
||||
input:
|
||||
source: cli
|
||||
example: "public/librenotes 42"
|
||||
schema:
|
||||
type: string
|
||||
description: "Gitea repository and issue number (e.g. 'owner/repo number')"
|
||||
|
||||
steps:
|
||||
- id: fetch-issue
|
||||
persona: gitea-analyst
|
||||
workspace:
|
||||
type: worktree
|
||||
branch: "{{ pipeline_id }}"
|
||||
exec:
|
||||
type: prompt
|
||||
source: |
|
||||
Fetch the Gitea issue specified in the input: {{ input }}
|
||||
|
||||
The input format is "owner/repo issue_number" (e.g., "public/librenotes 42").
|
||||
|
||||
Parse the input to extract the repository and issue number.
|
||||
Use the tea CLI to fetch the issue:
|
||||
|
||||
tea issues list --repo <owner/repo> --login librete -o json -f index,title,body,labels,state,url --limit 50
|
||||
|
||||
Then filter the JSON output for the issue matching the requested number.
|
||||
|
||||
Parse the output and produce structured JSON with the issue content.
|
||||
Include repository information in the output.
|
||||
output_artifacts:
|
||||
- name: issue-content
|
||||
path: .wave/output/issue-content.json
|
||||
type: json
|
||||
handover:
|
||||
contract:
|
||||
type: json_schema
|
||||
source: .wave/output/issue-content.json
|
||||
schema_path: .wave/contracts/issue-content.schema.json
|
||||
on_failure: retry
|
||||
max_retries: 3
|
||||
|
||||
- id: analyze-topics
|
||||
persona: researcher
|
||||
dependencies: [fetch-issue]
|
||||
memory:
|
||||
inject_artifacts:
|
||||
- step: fetch-issue
|
||||
artifact: issue-content
|
||||
as: issue
|
||||
workspace:
|
||||
type: worktree
|
||||
branch: "{{ pipeline_id }}"
|
||||
exec:
|
||||
type: prompt
|
||||
source: |
|
||||
Analyze the Gitea issue and extract research topics.
|
||||
|
||||
Identify:
|
||||
1. Key technical questions that need external research
|
||||
2. Domain concepts that require clarification
|
||||
3. External dependencies, libraries, or tools to investigate
|
||||
4. Similar problems/solutions that might provide guidance
|
||||
|
||||
For each topic, provide:
|
||||
- A unique ID (TOPIC-001, TOPIC-002, etc.)
|
||||
- A clear title
|
||||
- Specific questions to answer (1-5 questions per topic)
|
||||
- Search keywords for web research
|
||||
- Priority (critical/high/medium/low based on relevance to solving the issue)
|
||||
- Category (technical/documentation/best_practices/security/performance/compatibility/other)
|
||||
|
||||
Focus on topics that will provide actionable insights for the issue author.
|
||||
Limit to 10 most important topics.
|
||||
output_artifacts:
|
||||
- name: topics
|
||||
path: .wave/output/research-topics.json
|
||||
type: json
|
||||
handover:
|
||||
contract:
|
||||
type: json_schema
|
||||
source: .wave/output/research-topics.json
|
||||
schema_path: .wave/contracts/research-topics.schema.json
|
||||
on_failure: retry
|
||||
max_retries: 2
|
||||
|
||||
- id: research-topics
|
||||
persona: researcher
|
||||
dependencies: [analyze-topics]
|
||||
memory:
|
||||
inject_artifacts:
|
||||
- step: fetch-issue
|
||||
artifact: issue-content
|
||||
as: issue
|
||||
- step: analyze-topics
|
||||
artifact: topics
|
||||
as: research_plan
|
||||
workspace:
|
||||
type: worktree
|
||||
branch: "{{ pipeline_id }}"
|
||||
exec:
|
||||
type: prompt
|
||||
source: |
|
||||
Research the topics identified in the research plan.
|
||||
|
||||
For each topic in the research plan:
|
||||
1. Execute web searches using the provided keywords
|
||||
2. Evaluate source credibility (official docs > authoritative > community)
|
||||
3. Extract relevant findings with key points
|
||||
4. Include direct quotes where helpful
|
||||
5. Rate your confidence in the answer (high/medium/low/inconclusive)
|
||||
|
||||
For each finding:
|
||||
- Assign a unique ID (FINDING-001, FINDING-002, etc.)
|
||||
- Provide a summary (20-2000 characters)
|
||||
- List key points as bullet items
|
||||
- Include source URL, title, and type
|
||||
- Rate relevance to the topic (0-1)
|
||||
|
||||
Always include source URLs for attribution.
|
||||
If a topic yields no useful results, mark confidence as "inconclusive".
|
||||
Document any gaps in the research.
|
||||
output_artifacts:
|
||||
- name: findings
|
||||
path: .wave/output/research-findings.json
|
||||
type: json
|
||||
handover:
|
||||
contract:
|
||||
type: json_schema
|
||||
source: .wave/output/research-findings.json
|
||||
schema_path: .wave/contracts/research-findings.schema.json
|
||||
on_failure: retry
|
||||
max_retries: 2
|
||||
|
||||
- id: synthesize-report
|
||||
persona: summarizer
|
||||
dependencies: [research-topics]
|
||||
memory:
|
||||
inject_artifacts:
|
||||
- step: fetch-issue
|
||||
artifact: issue-content
|
||||
as: original_issue
|
||||
- step: research-topics
|
||||
artifact: findings
|
||||
as: research
|
||||
workspace:
|
||||
type: worktree
|
||||
branch: "{{ pipeline_id }}"
|
||||
exec:
|
||||
type: prompt
|
||||
source: |
|
||||
Synthesize the research findings into a coherent report for the Gitea issue.
|
||||
|
||||
Create a well-structured research report that includes:
|
||||
|
||||
1. Executive Summary:
|
||||
- Brief overview (50-1000 chars)
|
||||
- Key findings (1-7 bullet points)
|
||||
- Primary recommendation
|
||||
- Confidence assessment (high/medium/low)
|
||||
|
||||
2. Detailed Findings:
|
||||
- Organize by topic/section
|
||||
- Include code examples where relevant
|
||||
- Reference sources using SRC-### IDs
|
||||
|
||||
3. Recommendations:
|
||||
- Actionable items with IDs (REC-001, REC-002, etc.)
|
||||
- Priority and effort estimates
|
||||
- Maximum 10 recommendations
|
||||
|
||||
4. Sources:
|
||||
- List all sources with IDs (SRC-001, SRC-002, etc.)
|
||||
- Include URL, title, type, and reliability
|
||||
|
||||
5. Pre-rendered Markdown:
|
||||
- Generate complete markdown_content field ready for Gitea comment
|
||||
- Use proper headers, bullet points, and formatting
|
||||
- Include a header: "## Research Findings (Wave Pipeline)"
|
||||
- End with sources section
|
||||
output_artifacts:
|
||||
- name: report
|
||||
path: .wave/output/research-report.json
|
||||
type: json
|
||||
handover:
|
||||
contract:
|
||||
type: json_schema
|
||||
source: .wave/output/research-report.json
|
||||
schema_path: .wave/contracts/research-report.schema.json
|
||||
on_failure: retry
|
||||
max_retries: 2
|
||||
|
||||
- id: post-comment
|
||||
persona: gitea-commenter
|
||||
dependencies: [synthesize-report]
|
||||
memory:
|
||||
inject_artifacts:
|
||||
- step: fetch-issue
|
||||
artifact: issue-content
|
||||
as: issue
|
||||
- step: synthesize-report
|
||||
artifact: report
|
||||
as: report
|
||||
workspace:
|
||||
type: worktree
|
||||
branch: "{{ pipeline_id }}"
|
||||
exec:
|
||||
type: prompt
|
||||
source: |
|
||||
Post the research report as a comment on the Gitea issue.
|
||||
|
||||
Steps:
|
||||
1. Read the issue details to get the repository and issue number
|
||||
2. Read the report to get the markdown_content
|
||||
3. Write the markdown content to a file, then use tea CLI to post the comment:
|
||||
|
||||
# Write to file to avoid shell escaping issues with large markdown
|
||||
cat > /tmp/comment-body.md << 'COMMENT_EOF'
|
||||
<markdown_content>
|
||||
COMMENT_EOF
|
||||
|
||||
tea comment <number> "$(cat /tmp/comment-body.md)" --repo <owner/repo> --login librete
|
||||
|
||||
4. Add a footer to the comment:
|
||||
---
|
||||
*Generated by [Wave](https://github.com/re-cinq/wave) issue-research pipeline*
|
||||
|
||||
5. Capture the result and verify success
|
||||
6. Clean up temp files
|
||||
|
||||
Record the result with:
|
||||
- success: true/false
|
||||
- issue_reference: issue number and repository
|
||||
- comment: id, url, body_length (if successful)
|
||||
- error: code, message, retryable (if failed)
|
||||
- timestamp: current time
|
||||
output_artifacts:
|
||||
- name: comment-result
|
||||
path: .wave/output/comment-result.json
|
||||
type: json
|
||||
outcomes:
|
||||
- type: url
|
||||
extract_from: .wave/output/comment-result.json
|
||||
json_path: .comment.url
|
||||
label: "Research Comment"
|
||||
handover:
|
||||
contract:
|
||||
type: json_schema
|
||||
source: .wave/output/comment-result.json
|
||||
schema_path: .wave/contracts/comment-result.schema.json
|
||||
on_failure: retry
|
||||
max_retries: 3
|
||||
194
.wave/pipelines/gt-issue-rewrite.yaml
Normal file
194
.wave/pipelines/gt-issue-rewrite.yaml
Normal file
@@ -0,0 +1,194 @@
|
||||
kind: WavePipeline
|
||||
metadata:
|
||||
name: gt-issue-rewrite
|
||||
description: "Analyze and rewrite poorly documented Gitea issues"
|
||||
release: true
|
||||
|
||||
input:
|
||||
source: cli
|
||||
example: "public/librenotes 42"
|
||||
schema:
|
||||
type: string
|
||||
description: "Gitea repository, optionally with issue number (e.g. 'owner/repo' or 'owner/repo 42')"
|
||||
|
||||
steps:
|
||||
- id: scan-issues
|
||||
persona: gitea-analyst
|
||||
workspace:
|
||||
type: worktree
|
||||
branch: "{{ pipeline_id }}"
|
||||
exec:
|
||||
type: prompt
|
||||
source: |
|
||||
MANDATORY: You MUST call the Bash tool. NEVER say "tea CLI not installed" without trying.
|
||||
|
||||
Input: {{ input }}
|
||||
|
||||
Parse the input to determine the mode:
|
||||
- If the input contains a number after the repo (e.g. "public/librenotes 42"), this is SINGLE ISSUE mode.
|
||||
Extract the repo (first token) and issue number (second token).
|
||||
- If the input is just a repo (e.g. "public/librenotes"), this is BATCH mode.
|
||||
|
||||
Execute these commands using the Bash tool:
|
||||
|
||||
1. tea --version
|
||||
|
||||
2a. SINGLE ISSUE mode: Parse the repo and number from {{ input }}, then run:
|
||||
tea issues list --repo <REPO> --login librete -o json -f index,title,body,labels,url --limit 50
|
||||
Then filter the JSON for the issue matching the requested number.
|
||||
2b. BATCH mode:
|
||||
tea issues list --repo {{ input }} --login librete --limit 10 -o json -f index,title,body,labels,url
|
||||
|
||||
After getting REAL results from Bash, analyze issues and score them.
|
||||
In single issue mode, analyze the one issue. In batch mode, analyze all returned issues.
|
||||
output_artifacts:
|
||||
- name: issue_analysis
|
||||
path: .wave/artifact.json
|
||||
type: json
|
||||
required: true
|
||||
handover:
|
||||
max_retries: 1
|
||||
contract:
|
||||
type: json_schema
|
||||
schema_path: .wave/contracts/github-issue-analysis.schema.json
|
||||
validate: true
|
||||
must_pass: true
|
||||
allow_recovery: true
|
||||
recovery_level: progressive
|
||||
progressive_validation: false
|
||||
|
||||
- id: plan-enhancements
|
||||
persona: gitea-analyst
|
||||
dependencies: [scan-issues]
|
||||
memory:
|
||||
inject_artifacts:
|
||||
- step: scan-issues
|
||||
artifact: issue_analysis
|
||||
as: analysis
|
||||
workspace:
|
||||
type: worktree
|
||||
branch: "{{ pipeline_id }}"
|
||||
exec:
|
||||
type: prompt
|
||||
source: |
|
||||
The analysis artifact contains poor_quality_issues from the scan step.
|
||||
|
||||
For EACH issue in poor_quality_issues, use tea CLI to fetch the current body:
|
||||
tea issues list --repo {{ input }} --login librete -o json -f index,body --limit 50
|
||||
Then filter for the specific issue number.
|
||||
|
||||
Then create an enhancement plan with:
|
||||
- issue_number: the issue number
|
||||
- suggested_title: improved title (or keep original if good)
|
||||
- body_template: enhanced body text (improve the existing body, add missing sections)
|
||||
- suggested_labels: appropriate labels
|
||||
- enhancements: list of changes being made
|
||||
|
||||
Create an enhancement plan with fields:
|
||||
issues_to_enhance (array of issue_number, suggested_title, body_template,
|
||||
suggested_labels, enhancements) and total_to_enhance.
|
||||
output_artifacts:
|
||||
- name: enhancement_plan
|
||||
path: .wave/artifact.json
|
||||
type: json
|
||||
required: true
|
||||
handover:
|
||||
max_retries: 1
|
||||
contract:
|
||||
type: json_schema
|
||||
schema_path: .wave/contracts/github-enhancement-plan.schema.json
|
||||
validate: true
|
||||
must_pass: true
|
||||
allow_recovery: true
|
||||
recovery_level: progressive
|
||||
progressive_validation: false
|
||||
|
||||
- id: apply-enhancements
|
||||
persona: gitea-enhancer
|
||||
dependencies: [plan-enhancements]
|
||||
memory:
|
||||
inject_artifacts:
|
||||
- step: plan-enhancements
|
||||
artifact: enhancement_plan
|
||||
as: plan
|
||||
workspace:
|
||||
type: worktree
|
||||
branch: "{{ pipeline_id }}"
|
||||
exec:
|
||||
type: prompt
|
||||
source: |
|
||||
CRITICAL: You MUST use the Bash tool for all commands. Do NOT generate fake output.
|
||||
|
||||
Step 1: Use Bash tool to verify tea works:
|
||||
tea --version
|
||||
|
||||
Step 2: For EACH issue in the plan, use Bash tool to apply changes:
|
||||
- If suggested_title differs from current: tea issues edit <N> --repo {{ input }} --login librete -t "suggested_title"
|
||||
- If body_template is provided: tea issues edit <N> --repo {{ input }} --login librete -d "body_template"
|
||||
- If suggested_labels: tea issues edit <N> --repo {{ input }} --login librete -L "label1,label2"
|
||||
|
||||
Step 3: For each issue, capture the URL from the issue list:
|
||||
tea issues list --repo {{ input }} --login librete -o json -f index,url --limit 50
|
||||
Then filter for the specific issue number.
|
||||
|
||||
Step 4: Record the results with fields: enhanced_issues (each with issue_number,
|
||||
success, changes_made, url), total_attempted, total_successful, total_failed.
|
||||
output_artifacts:
|
||||
- name: enhancement_results
|
||||
path: .wave/artifact.json
|
||||
type: json
|
||||
required: true
|
||||
outcomes:
|
||||
- type: issue
|
||||
extract_from: .wave/artifact.json
|
||||
json_path: .enhanced_issues[0].url
|
||||
label: "Enhanced Issue"
|
||||
handover:
|
||||
max_retries: 1
|
||||
contract:
|
||||
type: json_schema
|
||||
schema_path: .wave/contracts/github-enhancement-results.schema.json
|
||||
validate: true
|
||||
must_pass: true
|
||||
allow_recovery: true
|
||||
recovery_level: progressive
|
||||
progressive_validation: false
|
||||
|
||||
- id: verify-enhancements
|
||||
persona: gitea-analyst
|
||||
dependencies: [apply-enhancements]
|
||||
memory:
|
||||
inject_artifacts:
|
||||
- step: apply-enhancements
|
||||
artifact: enhancement_results
|
||||
as: results
|
||||
- step: scan-issues
|
||||
artifact: issue_analysis
|
||||
as: original_analysis
|
||||
workspace:
|
||||
type: worktree
|
||||
branch: "{{ pipeline_id }}"
|
||||
exec:
|
||||
type: prompt
|
||||
source: |
|
||||
For each enhanced issue, verify with:
|
||||
tea issues list --repo {{ input }} --login librete -o json -f index,title,labels --limit 50
|
||||
Then filter for the specific issue numbers.
|
||||
|
||||
Compile a verification report with fields:
|
||||
total_enhanced, successful_enhancements, failed_enhancements, and summary.
|
||||
output_artifacts:
|
||||
- name: verification_report
|
||||
path: .wave/artifact.json
|
||||
type: json
|
||||
required: true
|
||||
handover:
|
||||
max_retries: 1
|
||||
contract:
|
||||
type: json_schema
|
||||
schema_path: .wave/contracts/github-verification-report.schema.json
|
||||
validate: true
|
||||
must_pass: true
|
||||
allow_recovery: true
|
||||
recovery_level: progressive
|
||||
progressive_validation: false
|
||||
182
.wave/pipelines/gt-issue-update.yaml
Normal file
182
.wave/pipelines/gt-issue-update.yaml
Normal file
@@ -0,0 +1,182 @@
|
||||
kind: WavePipeline
|
||||
metadata:
|
||||
name: gt-issue-update
|
||||
description: "Refresh a stale Gitea issue by comparing it against recent codebase changes"
|
||||
release: true
|
||||
|
||||
input:
|
||||
source: cli
|
||||
example: "public/librenotes 45 -- acceptance criteria are outdated after the worktree refactor"
|
||||
schema:
|
||||
type: string
|
||||
description: "owner/repo number [-- optional criticism or direction]"
|
||||
|
||||
steps:
|
||||
- id: gather-context
|
||||
persona: gitea-analyst
|
||||
workspace:
|
||||
type: worktree
|
||||
branch: "{{ pipeline_id }}"
|
||||
exec:
|
||||
type: prompt
|
||||
source: |
|
||||
MANDATORY: You MUST call the Bash tool. NEVER say "tea CLI not installed" without trying.
|
||||
|
||||
Input: {{ input }}
|
||||
|
||||
Parse the input:
|
||||
- Split on " -- " to separate the repo+number from optional criticism.
|
||||
- The first part is "<owner/repo> <number>". Extract REPO (first token) and NUMBER (second token).
|
||||
- If there is text after " -- ", that is the user's CRITICISM about what's wrong with the issue.
|
||||
- If there is no " -- ", criticism is empty.
|
||||
|
||||
Execute these commands using the Bash tool:
|
||||
|
||||
1. tea --version
|
||||
|
||||
2. Fetch the full issue:
|
||||
tea issues list --repo REPO --login librete -o json -f index,title,body,labels,state,url --limit 50
|
||||
Then filter the JSON for the issue matching NUMBER.
|
||||
|
||||
3. Get commits since the issue was created (cap at 100):
|
||||
git log --since="<created_at>" --oneline -100
|
||||
|
||||
4. Scan the issue body for file path references (anything matching patterns like
|
||||
`internal/...`, `cmd/...`, `.wave/...`, or backtick-quoted paths).
|
||||
For each referenced file, check if it still exists using `ls -la <path>`.
|
||||
|
||||
5. Read CLAUDE.md for current project context:
|
||||
Read the file CLAUDE.md from the repository root.
|
||||
|
||||
After gathering ALL data, produce a JSON result matching the contract schema.
|
||||
output_artifacts:
|
||||
- name: issue_context
|
||||
path: .wave/artifact.json
|
||||
type: json
|
||||
required: true
|
||||
handover:
|
||||
max_retries: 1
|
||||
contract:
|
||||
type: json_schema
|
||||
schema_path: .wave/contracts/issue-update-context.schema.json
|
||||
validate: true
|
||||
must_pass: true
|
||||
allow_recovery: true
|
||||
recovery_level: progressive
|
||||
progressive_validation: false
|
||||
|
||||
- id: draft-update
|
||||
persona: gitea-analyst
|
||||
dependencies: [gather-context]
|
||||
memory:
|
||||
inject_artifacts:
|
||||
- step: gather-context
|
||||
artifact: issue_context
|
||||
as: context
|
||||
workspace:
|
||||
type: worktree
|
||||
branch: "{{ pipeline_id }}"
|
||||
exec:
|
||||
type: prompt
|
||||
source: |
|
||||
MANDATORY: You MUST call the Bash tool for any commands. NEVER generate fake output.
|
||||
|
||||
The context artifact contains the gathered issue context.
|
||||
|
||||
Your task: Compare the original issue against the codebase changes and draft an updated version.
|
||||
|
||||
Step 1: Analyze each section of the issue body. Classify each as:
|
||||
- STILL_VALID: Content is accurate and up-to-date
|
||||
- OUTDATED: Content references old behavior, removed files, or superseded patterns
|
||||
- INCOMPLETE: Content is partially correct but missing recent developments
|
||||
- WRONG: Content is factually incorrect given current codebase state
|
||||
|
||||
Step 2: If there is user criticism (non-empty "criticism" field), address EVERY point raised.
|
||||
The criticism takes priority — it represents what the issue author thinks is wrong.
|
||||
|
||||
Step 3: Draft the updated issue:
|
||||
- Preserve sections classified as STILL_VALID (do not rewrite what works)
|
||||
- Rewrite OUTDATED and WRONG sections to reflect current reality
|
||||
- Expand INCOMPLETE sections with missing information
|
||||
- If the title needs updating, draft a new title
|
||||
- Append a "---\n**Changes since original**" section at the bottom listing what changed and why
|
||||
|
||||
Step 4: If file paths in the issue body are now missing (from referenced_files.missing),
|
||||
update or remove those references.
|
||||
|
||||
Produce a JSON result matching the contract schema.
|
||||
output_artifacts:
|
||||
- name: update_draft
|
||||
path: .wave/artifact.json
|
||||
type: json
|
||||
required: true
|
||||
handover:
|
||||
max_retries: 1
|
||||
contract:
|
||||
type: json_schema
|
||||
schema_path: .wave/contracts/issue-update-draft.schema.json
|
||||
validate: true
|
||||
must_pass: true
|
||||
allow_recovery: true
|
||||
recovery_level: progressive
|
||||
progressive_validation: false
|
||||
|
||||
- id: apply-update
|
||||
persona: gitea-enhancer
|
||||
dependencies: [draft-update]
|
||||
memory:
|
||||
inject_artifacts:
|
||||
- step: draft-update
|
||||
artifact: update_draft
|
||||
as: draft
|
||||
- step: gather-context
|
||||
artifact: issue_context
|
||||
as: context
|
||||
workspace:
|
||||
type: worktree
|
||||
branch: "{{ pipeline_id }}"
|
||||
exec:
|
||||
type: prompt
|
||||
source: |
|
||||
CRITICAL: You MUST use the Bash tool for all commands. Do NOT generate fake output.
|
||||
|
||||
Step 1: Use Bash tool to verify tea works:
|
||||
tea --version
|
||||
|
||||
Step 2: Extract the repo and issue number from the available artifacts.
|
||||
|
||||
Step 3: Apply the update:
|
||||
- If title_changed is true:
|
||||
tea issues edit <NUMBER> --repo <REPO> --login librete -t "<updated_title>"
|
||||
- Write the updated_body to a temp file, then apply it:
|
||||
Write updated_body to /tmp/issue-body.md
|
||||
tea issues edit <NUMBER> --repo <REPO> --login librete -d "$(cat /tmp/issue-body.md)"
|
||||
- Clean up /tmp/issue-body.md after applying.
|
||||
|
||||
Step 4: Verify the update was applied:
|
||||
tea issues list --repo <REPO> --login librete -o json -f index,title,body,url --limit 50
|
||||
Then filter for the specific issue number.
|
||||
|
||||
Compare the returned title and body against what was intended. Flag any discrepancies.
|
||||
|
||||
Step 5: Record the results as a JSON object matching the contract schema.
|
||||
output_artifacts:
|
||||
- name: update_result
|
||||
path: .wave/artifact.json
|
||||
type: json
|
||||
required: true
|
||||
outcomes:
|
||||
- type: issue
|
||||
extract_from: .wave/artifact.json
|
||||
json_path: .url
|
||||
label: "Updated Issue"
|
||||
handover:
|
||||
max_retries: 1
|
||||
contract:
|
||||
type: json_schema
|
||||
schema_path: .wave/contracts/issue-update-result.schema.json
|
||||
validate: true
|
||||
must_pass: true
|
||||
allow_recovery: true
|
||||
recovery_level: progressive
|
||||
progressive_validation: false
|
||||
67
.wave/prompts/gitea-issue-impl/create-pr.md
Normal file
67
.wave/prompts/gitea-issue-impl/create-pr.md
Normal file
@@ -0,0 +1,67 @@
|
||||
You are creating a pull request for the implemented Gitea issue.
|
||||
|
||||
Input: {{ input }}
|
||||
|
||||
## Working Directory
|
||||
|
||||
You are running in an **isolated git worktree** shared with previous pipeline steps.
|
||||
Your working directory IS the project root. The feature branch was created by the
|
||||
plan step and is already checked out. All git operations here are isolated from
|
||||
the main working tree.
|
||||
|
||||
Read the issue assessment artifact to find the issue number, repository, branch name, and issue URL.
|
||||
|
||||
## SAFETY: Do NOT Modify the Working Tree
|
||||
|
||||
This step MUST NOT run `git checkout`, `git stash`, or any command that changes
|
||||
the current branch or working tree state. The branch already exists from the
|
||||
implement step — just push it and create the PR.
|
||||
|
||||
## Instructions
|
||||
|
||||
### Step 1: Load Context
|
||||
|
||||
From the issue assessment artifact, extract:
|
||||
- Issue number and title
|
||||
- Repository (`owner/repo`)
|
||||
- Branch name
|
||||
- Issue URL
|
||||
|
||||
### Step 2: Push the Branch
|
||||
|
||||
Push the feature branch without checking it out:
|
||||
|
||||
```bash
|
||||
git push -u origin <BRANCH_NAME>
|
||||
```
|
||||
|
||||
### Step 3: Create Pull Request
|
||||
|
||||
Create the PR using `tea pulls create` with `--head` to target the branch. The PR description MUST include `Closes #<NUMBER>` to auto-close the issue on merge.
|
||||
|
||||
```bash
|
||||
tea pulls create --repo <OWNER/REPO> --login librete --head <BRANCH_NAME> -t "<concise title>" -d "$(cat <<'PRBODY'
|
||||
## Summary
|
||||
<3-5 bullet points describing the changes>
|
||||
|
||||
Closes #<ISSUE_NUMBER>
|
||||
|
||||
## Changes
|
||||
<list of key files changed and why>
|
||||
|
||||
## Test Plan
|
||||
<how the changes were validated>
|
||||
PRBODY
|
||||
)"
|
||||
```
|
||||
|
||||
## CONSTRAINTS
|
||||
|
||||
- Do NOT spawn Task subagents — work directly in the main context
|
||||
- Do NOT run `git checkout`, `git stash`, or any branch-switching commands
|
||||
- The PR description MUST contain `Closes #<NUMBER>` to link to the issue
|
||||
- Do NOT include Co-Authored-By or AI attribution in commits
|
||||
|
||||
## Output
|
||||
|
||||
Produce a JSON status report matching the injected output schema.
|
||||
81
.wave/prompts/gitea-issue-impl/fetch-assess.md
Normal file
81
.wave/prompts/gitea-issue-impl/fetch-assess.md
Normal file
@@ -0,0 +1,81 @@
|
||||
You are fetching a Gitea issue and assessing whether it has enough detail to implement.
|
||||
|
||||
Input: {{ input }}
|
||||
|
||||
The input format is `owner/repo number` (e.g. `public/librenotes 42`).
|
||||
|
||||
## Working Directory
|
||||
|
||||
You are running in an isolated Wave workspace. The `tea` CLI works from any
|
||||
directory when using the `--repo` and `--login` flags, 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 `tea` CLI to fetch issues and filter for the target:
|
||||
|
||||
```bash
|
||||
tea issues list --repo <OWNER/REPO> --login librete -o json -f index,title,body,labels,state,url --limit 50
|
||||
```
|
||||
|
||||
Then filter the JSON output for the issue matching the requested number.
|
||||
|
||||
### 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
|
||||
|
||||
## Output
|
||||
|
||||
Produce a JSON assessment matching the injected output schema.
|
||||
87
.wave/prompts/gitea-issue-impl/implement.md
Normal file
87
.wave/prompts/gitea-issue-impl/implement.md
Normal file
@@ -0,0 +1,87 @@
|
||||
You are implementing a Gitea issue according to the plan and task breakdown.
|
||||
|
||||
Input: {{ input }}
|
||||
|
||||
## Working Directory
|
||||
|
||||
You are running in an **isolated git worktree** shared with previous pipeline steps.
|
||||
Your working directory IS the project root. The feature branch was created by the
|
||||
plan step and is already checked out. All git operations here are isolated from
|
||||
the main working tree.
|
||||
|
||||
## Instructions
|
||||
|
||||
### Step 1: Load Context
|
||||
|
||||
1. Get the issue details and branch name from the issue assessment artifact
|
||||
2. Get the task breakdown, file changes, and feature directory from the plan artifact
|
||||
|
||||
### Step 2: Read Plan Files
|
||||
|
||||
Navigate to the feature directory and read:
|
||||
- `spec.md` — the full specification
|
||||
- `plan.md` — the implementation plan
|
||||
- `tasks.md` — the phased task breakdown
|
||||
|
||||
### Step 3: Execute Implementation
|
||||
|
||||
Follow the task breakdown phase by phase:
|
||||
|
||||
**Setup first**: Initialize project structure, dependencies, configuration
|
||||
|
||||
**Tests before code (TDD)**:
|
||||
- Write tests that define expected behavior
|
||||
- Run tests to confirm they fail for the right reason
|
||||
- Implement the code to make tests pass
|
||||
|
||||
**Core development**: Implement the changes specified in the plan
|
||||
|
||||
**Integration**: Wire components together, update imports, middleware
|
||||
|
||||
**Polish**: Edge cases, error handling, documentation updates
|
||||
|
||||
### Step 4: Validate Between Phases
|
||||
|
||||
After each phase, run:
|
||||
```bash
|
||||
go test -race ./...
|
||||
```
|
||||
|
||||
If tests fail, fix the issue before proceeding to the next phase.
|
||||
|
||||
### Step 5: Mark Completed Tasks
|
||||
|
||||
As you complete each task, mark it as `[X]` in `tasks.md`.
|
||||
|
||||
### Step 6: Final Validation
|
||||
|
||||
After all tasks are complete:
|
||||
1. Run `go test -race ./...` one final time
|
||||
2. Verify all tasks in `tasks.md` are marked complete
|
||||
3. Stage and commit all changes:
|
||||
```bash
|
||||
git add -A
|
||||
git reset HEAD -- .wave/artifacts .wave/output .claude CLAUDE.md 2>/dev/null || true
|
||||
git commit -m "feat: implement #<ISSUE_NUMBER> — <short description>"
|
||||
```
|
||||
|
||||
Commit changes to the worktree branch.
|
||||
|
||||
## Agent Usage — USE UP TO 6 AGENTS
|
||||
|
||||
Maximize parallelism with up to 6 Task agents for independent work:
|
||||
- Agents 1-2: Setup and foundational tasks (Phase 1-2)
|
||||
- Agents 3-4: Core implementation tasks (parallelizable [P] tasks)
|
||||
- Agent 5: Test writing and validation
|
||||
- Agent 6: Integration and polish tasks
|
||||
|
||||
Coordinate agents to respect task dependencies:
|
||||
- Sequential tasks (no [P] marker) must complete before dependents start
|
||||
- Parallel tasks [P] affecting different files can run simultaneously
|
||||
- Run test validation between phases
|
||||
|
||||
## Error Handling
|
||||
|
||||
- If a task fails, halt dependent tasks but continue independent ones
|
||||
- Provide clear error context for debugging
|
||||
- If tests fail, fix the issue before proceeding to the next phase
|
||||
90
.wave/prompts/gitea-issue-impl/plan.md
Normal file
90
.wave/prompts/gitea-issue-impl/plan.md
Normal file
@@ -0,0 +1,90 @@
|
||||
You are creating an implementation plan for a Gitea issue.
|
||||
|
||||
Input: {{ input }}
|
||||
|
||||
## Working Directory
|
||||
|
||||
You are running in an **isolated git worktree** checked out at `main` (detached HEAD).
|
||||
Your working directory IS the project root. All git operations here are isolated
|
||||
from the main working tree and will not affect it.
|
||||
|
||||
Use `create-new-feature.sh` to create the feature branch from this clean starting point.
|
||||
|
||||
## Instructions
|
||||
|
||||
### Step 1: Read Assessment
|
||||
|
||||
From the issue assessment artifact, extract:
|
||||
- Issue number, title, body, and repository
|
||||
- Branch name from the assessment
|
||||
- Complexity estimate
|
||||
- Which speckit steps were skipped
|
||||
|
||||
### Step 2: Create Feature Branch
|
||||
|
||||
Use the `create-new-feature.sh` script to create a properly numbered branch:
|
||||
|
||||
```bash
|
||||
.specify/scripts/bash/create-new-feature.sh --json --number <ISSUE_NUMBER> --short-name "<SHORT_NAME>" "<ISSUE_TITLE>"
|
||||
```
|
||||
|
||||
If the branch already exists (e.g. from a resume), check it out instead:
|
||||
```bash
|
||||
git checkout <BRANCH_NAME>
|
||||
```
|
||||
|
||||
### Step 3: Write Spec from Issue
|
||||
|
||||
In the feature directory (e.g. `specs/<BRANCH_NAME>/`), create `spec.md` with:
|
||||
- Issue title as heading
|
||||
- Full issue body
|
||||
- Labels and metadata
|
||||
- Any acceptance criteria extracted from the issue
|
||||
- Link back to the original issue URL
|
||||
|
||||
### Step 4: Create Implementation Plan
|
||||
|
||||
Write `plan.md` in the feature directory with:
|
||||
|
||||
1. **Objective**: What the issue asks for (1-2 sentences)
|
||||
2. **Approach**: High-level strategy
|
||||
3. **File Mapping**: Which files need to be created/modified/deleted
|
||||
4. **Architecture Decisions**: Any design choices made
|
||||
5. **Risks**: Potential issues and mitigations
|
||||
6. **Testing Strategy**: What tests are needed
|
||||
|
||||
### Step 5: Create Task Breakdown
|
||||
|
||||
Write `tasks.md` in the feature directory with a phased breakdown:
|
||||
|
||||
```markdown
|
||||
# Tasks
|
||||
|
||||
## Phase 1: Setup
|
||||
- [ ] Task 1.1: Description
|
||||
- [ ] Task 1.2: Description
|
||||
|
||||
## Phase 2: Core Implementation
|
||||
- [ ] Task 2.1: Description [P] (parallelizable)
|
||||
- [ ] Task 2.2: Description [P]
|
||||
|
||||
## Phase 3: Testing
|
||||
- [ ] Task 3.1: Write unit tests
|
||||
- [ ] Task 3.2: Write integration tests
|
||||
|
||||
## Phase 4: Polish
|
||||
- [ ] Task 4.1: Documentation updates
|
||||
- [ ] Task 4.2: Final validation
|
||||
```
|
||||
|
||||
Mark parallelizable tasks with `[P]`.
|
||||
|
||||
## CONSTRAINTS
|
||||
|
||||
- Do NOT spawn Task subagents — work directly in the main context
|
||||
- Do NOT start implementation — only planning in this step
|
||||
- Do NOT use WebSearch — all information is in the issue and codebase
|
||||
|
||||
## Output
|
||||
|
||||
Produce a JSON status report matching the injected output schema.
|
||||
Reference in New Issue
Block a user