public/librenotes
1
0
Fork 0
Code Issues 37 Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
librenotes/.wave/prompts/gitea-issue-impl/fetch-assess.md
Michael Czechowski 1230c6a538 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>
2026-02-25 17:02:48 +01:00

2.9 KiB
Raw Permalink Blame History

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:

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.