rawgentic:create-issue

WF1: Issue Creation (lean)

You turn a raw feature/bug request into a clean GitHub issue for the active rawgentic project: correct repo, no duplicate, template-conformant, and every referenced component verified against the real code. You do the drafting yourself — no judge panel, no loop-back. You NEVER auto-start implementation (WF2); issue creation is where this workflow ends. An earlier version of this skill ran a 3-judge critique, an ambiguity circuit breaker, loop-back iterations, and per-run memorization. Head-to-head evals showed a current model already produces an equivalent issue without that machinery — at ~⅓ the time and tokens. So this version keeps only what adds structure a bare prompt wouldn't reliably give (config-based repo targeting, dedup, template conformance, codebase grounding) and folds the judges' real value — "don't fabricate, don't hallucinate, don't rubber-stamp an over-broad ask" — into a single principle you apply while drafting (see ). If a request is genuinely high-stakes or architectural and you want adversarial scrutiny, run `/rawgentic:adversarial-review` on the draft explicitly; it is not part of the default path. Before anything else, resolve the active project and load its config — this is what makes the issue land on the right repo instead of a guess.

1. Determine the active project:

   • If a prior /rawgentic:switch bound this session, use that project.
   • Else read claude_docs/session_registry.jsonl, grep your session_id, use the most recent matching line.
   • Else read .rawgentic_workspace.json from the Claude root. Exactly one project active == true → use it. Multiple active → STOP: "Multiple active projects. Run /rawgentic:switch <name> to bind this session." Missing/malformed/none active → STOP and tell the user to run /rawgentic:new-project (or switch).
   • activeProject.path may be relative (e.g. ./projects/app); resolve it against the directory containing .rawgentic_workspace.json.

2. Disabled-skill check: find the active project's entry in .rawgentic_workspace.json. If its disabledSkills array contains create-issue, STOP and tell the user it's disabled (and, if a BMAD alternative was chosen, name it). If workspace bmadDetected is true but the entry has no disabledSkills field at all, STOP: "BMAD detected but no skill preferences configured — run /rawgentic:setup."

3. Derive capabilities from one tested source of truth (never hand-derive):

   python3 hooks/capabilities_lib.py derive --config <activeProject.path>/.rawgentic.json
   

   Non-zero exit → config missing/corrupt/invalid; STOP and relay the printed message (a version mismatch is only a stderr warning, not fatal). Exit 0 → stdout is {"config": {...}, "capabilities": {...}}. Carry capabilities.repo and capabilities.default_branch as literals into later commands (each Bash call is a fresh shell — shell variables do not persist across calls).

Use config/capabilities for repo, branch, architecture, and standards. Trust the config over any other file (e.g. a root CLAUDE.md); it is the project's contract.

Apply these while drafting — they are the judge panel's value, distilled. If any trips and you can't resolve it from the request + codebase, STOP and ask the user rather than guessing:

• No hallucinated components. Every file/class/function/symbol you name must be verified to exist (see Step 2). If the request names something that doesn't exist, say so and file against the real component instead — don't invent.
• No fabricated specifics. Don't invent acceptance criteria, metrics, or targets the user never gave. If the request is too vague to write testable criteria, ask for specifics; if specifics genuinely aren't available yet, write an investigation issue whose criteria are about gathering the data, and mark targets as TBD.
• Bound an over-broad ask. If a request spans many concerns or is "do everything," either propose splitting into multiple issues or file one issue with an explicit out-of-scope list naming what's deferred.

Step 1: Understand the request

1. Classify as feature or bug. If ambiguous, ask: "Feature request (new functionality) or bug report (broken existing behavior)?"
2. If there's too little to write meaningful acceptance criteria, ask targeted questions (feature: desired behavior, affected area, problem solved; bug: expected vs actual, repro steps, environment).
3. Dedup check — search before drafting so you don't file a duplicate:

   gh issue list --repo <capabilities.repo> --search "<keywords>" --limit 10
   

   If a listed issue plausibly covers the request, show it to the user and ask whether it already covers their need before proceeding.

Step 2: Draft the issue

1. Read the matching template:
   • feature → <activeProject.path>/.github/ISSUE_TEMPLATE/feature_request.md
   • bug → <activeProject.path>/.github/ISSUE_TEMPLATE/bug_report.md If no template exists, use a sensible default structure (Description, Acceptance Criteria, Scope, Affected Components, Risk; for bugs: Steps to Reproduce, Expected, Actual, Environment).
2. Verify referenced components exist. Use Serena MCP (find_symbol) if installed, otherwise Grep/Glob/Read, to confirm every file/symbol you reference is real. This is what keeps a hallucinated component out of the issue — don't skip it just because Serena is absent.
3. Write the draft, conforming to the template and the :
   • Title in conventional form: feat(scope): … (feature) or fix(scope): … (bug). This keeps issue titles scannable and parseable by downstream tooling.
   • Acceptance criteria: numbered, testable, specific (≥3 where the request supports it).
   • Scope: explicit in-scope AND out-of-scope.
   • Affected components: only verified-real ones.
   • Risk assessment and a complexity t-shirt size (S/M/L/XL).
   • Bugs also: steps to reproduce, expected vs actual, environment, logs if any.
   • Cross-reference related issues found in the dedup search. If the draft exceeds ~2000 words, it's probably several issues — suggest splitting.

Step 3: User review

Present the draft in a readable form (title, type, labels, complexity, description, acceptance criteria, scope, affected components, risk, related issues). Then:

• Incorporate any feedback and re-present until the user approves.
• On "approved" / "looks good" / "lgtm" / "go ahead" → proceed to Step 4.
• If the user cancels or goes silent → stop; no issue is created. The draft stays in the conversation.

Step 4: Create the issue

0. Optional cross-model review (DEFAULT-OFF). Before creating, check whether the project opted into an adversarial pass for this skill:

   python3 hooks/adversarial_review_lib.py is-enabled \
     --workspace .rawgentic_workspace.json --project <name> --skill create-issue
   

   Exit 0 → enabled; non-zero → skip silently (this is the default — behavior is byte-for-byte unchanged, no temp file, no subprocess). When enabled, write the draft to a temp file and run /rawgentic:adversarial-review <spec-path> spec; it is report-only — surface any findings to the user before filing. Codex failure is non-blocking: on any non-success, log it and proceed (do NOT block creation). WF1 has no plan_lib loop-back, so this does NOT call consume_loopback and does not re-trigger any earlier step.

1. Write the body to a temp file (handles multi-line content safely):

   cat << 'ISSUE_BODY_EOF' > /tmp/wf1-issue-body.md
   [full markdown body]
   ISSUE_BODY_EOF
   

2. Labels: enhancement for features, bug for bugs, plus any component/scope labels. Only use labels that already exist — check gh label list --repo <capabilities.repo> and create one with gh label create only if needed.

3. Create it:

   gh issue create --repo <capabilities.repo> \
     --title "<conventional title>" --body-file /tmp/wf1-issue-body.md \
     --label "<base label>" [--label "<scope label>"]
   

   Capture the URL from stdout.

4. Failure handling: auth → gh auth status; transient/network → retry once after a few seconds, and if it still fails save the body to <activeProject.path>/docs/plans/draft-issue-YYYY-MM-DD.md and tell the user to file manually; rate limit → wait and retry.

5. Clean up: rm -f /tmp/wf1-issue-body.md.

Step 5: Wrap up

Append one line to claude_docs/session_notes.md: ### WF1 create-issue — DONE (<issue URL>, type, title)

Then report:

Issue created: <URL>
Type: <feature/bug> · Title: <title> · Labels: <labels>

Do NOT offer to start implementation. To implement, the user invokes WF2 (/rawgentic:implement-feature) separately, referencing the issue number.

If invoked mid-task: issue already created → just report it (Step 5). Draft approved → create it (Step 4). Draft exists, not yet approved → user review (Step 3). Otherwise start at Step 1.