| namespace | aiwg |
| name | steward-prep-delivery |
| platforms | ["all"] |
| description | Steward-assisted prep for filing issues and PRs — environment capture, template selection, duplicate detection, delivery-policy compliance check |
| script | {"entrypoint":"find-duplicates.sh","runtime":"bash","cwd":"project-root","argsHint":"<search-terms...>"} |
Steward Prep for Delivery (#1269)
You are walking the user through filing a high-quality issue or PR, mirroring the import pattern used for the recent jmagly→roctinam tester report sweep (Gitea #1264–#1269).
When this fires
- "I want to file an issue"
- "I want to open a PR"
- "Help me file a bug report"
- "Should this be a new issue or a comment on an existing one?"
- "Walk me through the import flow for this tester report"
The walkthrough
Step 1: Triage
Ask the user: "Is this one bug, or did you find multiple issues in a single session?"
- One issue → use
bug-report.md (or feature-request.md if it's a proposal, not a defect)
- Multiple findings → use
tester-report.md and split during triage
- Already filed elsewhere (GitHub, Discord, email) → use
imported-report.md
Don't make this decision for them — surface the templates and let them pick.
Step 2: Environment capture (for bug reports)
For bug-report.md, the operator needs to fill in environment info. Help them collect it:
aiwg version
aiwg doctor
node --version
uname -a
If they're filing on behalf of an agent platform (Claude Code, hermes, Codex, …), make sure the platform name is captured — the same bug can manifest differently across providers.
Step 3: Duplicate detection (BEFORE filing)
Run the duplicate-detection helper. The skill's script: entrypoint
(find-duplicates.sh) searches the local aiwg discover index plus the Gitea
issue tracker for likely duplicates of the proposed title or keywords:
aiwg run skill steward-prep-delivery -- "<keywords from the issue title>"
Output: ranked list of existing open issues that match. If any look like duplicates, prefer commenting on them over filing a new one. If none match, proceed to filing.
Step 4: Draft assembly
Help the user fill out the chosen template. Specifically:
- For bug-report.md: insist on a copy-paste-able repro (not "X seems broken"). Paste exact error text in code blocks.
- For feature-request.md: insist on a concrete proposal (interfaces, file paths, command syntax) — not "we should make X better."
- For tester-report.md: encourage one finding per section with severity, repro, expected/actual.
- For imported-report.md: include the source link, original reporter handle, and platform/environment correction if the source got it wrong (e.g., the jmagly tester report cited Claude Code, but the actual harness was hermes).
Step 5: Policy compliance check
Before they click "Submit", confirm:
-
Delivery policy: read .aiwg/aiwg.config delivery.mode. If direct, the fix will land with Closes #N in the commit (no PR). If pr-required, they'll need a feature branch. If feature-branch, branch only. Tell them what to expect.
-
No AI attribution: if they're using an AI tool to help draft, the commit/PR must not include Co-Authored-By: <AI> lines or "Generated with" markers. This is the project's no-attribution rule, applied universally.
-
CI green before done: a commit isn't done until CI passes. Remind them to wait for the run on Gitea, and if it fails, fix it before declaring resolution.
Step 6: Submit and follow up
For Gitea issues, use:
aiwg run skill issue-create -- "<title>" --provider gitea --labels "bug"
(Or invoke the relevant template manually via the Gitea web UI — both are fine.)
For PRs that close issues, ensure the body contains Closes #N (or Refs #N if it doesn't fully close).
Anti-patterns to flag
- "While I'm at it" — if the user starts adding unrelated changes during issue/PR drafting, split into separate tickets. One bug per issue, one concern per PR.
- Vague titles — "doesn't work" or "broken" titles get bumped back; insist on
type(scope): subject form (e.g., bug(steward): path resolution lands at dist/).
- Missing environment — bug reports without OS/version/platform get clarified before action. Don't let them slip through.
- Re-filing duplicates — always run the duplicate-detection helper first. Comments on existing issues are cheaper than fresh issues.
Related skills
issue-create — the actual filing surface (Gitea, GitHub, Jira, Linear, local)issue-auto-sync — detects commit ↔ issue links automaticallyaddress-issues — runs issue-driven agent loops to close issues with code
References
CONTRIBUTING.md — full contributor guide.gitea/ISSUE_TEMPLATE/ — issue templates.gitea/pull_request_template.md — PR templateagentic/code/addons/aiwg-utils/rules/delivery-policy.md — delivery mode ruleagentic/code/frameworks/sdlc-complete/rules/no-attribution.md — no-attribution rule- #1269 (parent issue), #1264–#1268 (the tester report sweep that motivated this)
