Gentleman-Programming/gentle-ai-issue-creation

Creación de Issues

Regla Principal

Descubre el flujo de contribución del repositorio objetivo antes de proponer o publicar. Los Formularios de Issue YAML son la autoridad de formato para la ruta automatizada predeterminada: materializa las respuestas revisadas en un BODY_FILE privado y publica con --body-file.

Descubrimiento Seguro

Ejecuta primero verificaciones de solo lectura:

ga auth status
REPO="$(gh repo view --json nameWithOwner -q .nameWithOwner)"
REPO_URL="$(gh repo view --json url -q .url)"
HOST="${REPO_URL#*://}"
HOST="${HOST%%/*}"
TARGET="$HOST/$REPO"
gh repo view --json nameWithOwner,url,hasDiscussionsEnabled,hasIssuesEnabled,isBlankIssuesEnabled
git ls-files README.md CONTRIBUTING.md CONTRIBUTING.* .github/CONTRIBUTING.md .github/ISSUE_TEMPLATE .github/ISSUE_TEMPLATE/config.yml
gh api --hostname "$HOST" --paginate "repos/$REPO/labels?per_page=100" --jq '.[].name'

Inspecciona README.md, instrucciones de contribución, enlaces de contacto de .github/ISSUE_TEMPLATE/config.yml, formularios, etiquetas, e issues abiertos y cerrados. Para preguntas/soporte, sigue el enrutamiento de Discussions/contacto prescrito por el repositorio cuando esté disponible; de lo contrario, pregunta o detente. Completa la verificación del objetivo para REPO, HOST y TARGET. Falla antes de mutar cuando falte o sea ambigua la autenticación, verificación del objetivo, disponibilidad de issues, política, selección de formulario o metadatos requeridos. Se permite un fallback en blanco solo cuando isBlankIssuesEnabled es explícitamente verdadero.

Construye LABEL_ARGS solo a partir de etiquetas revisadas que existan y la política permita que el actor las aplique:

LABEL_ARGS=()
LABEL_ARGS+=(--label "$LABEL") # Repetir solo por cada etiqueta permitida descubierta.

Decisión de Duplicados y Formulario

1. Describe el informe en una oración, deriva QUERY, luego completa una búsqueda de duplicados en issues abiertos y cerrados:

   gh issue list --repo "$TARGET" --state all --search "$QUERY" --limit 1000
   

   El agente debe completar la búsqueda de duplicados de manera proactiva y conservar evidencia de su resultado. Si los resultados están saturados o la integridad es incierta, reduce la búsqueda de solo lectura o detente. Comenta en un duplicado confirmado en lugar de crear uno. Antes de comentar en un duplicado confirmado, realiza el mismo escaneo de privacidad/redacción en el cuerpo del comentario exacto que para la publicación.

2. Selecciona solo un formulario proporcionado por el repositorio cuando su propósito declarado coincida. Si varios formularios coinciden y la política no los distingue, detente y solicita esa decisión.

3. Para un formulario YAML, lee su esquema y establece controles en el orden declarado. Soporta solo input, textarea, dropdown y checkboxes. Los controles de Markdown son guía sin respuesta: honra sus instrucciones visibles al recopilar y materializar respuestas adyacentes, pero no los renderices como secciones de respuesta. Falla antes de mutar en caso de estructura o respuestas requeridas malformadas, no soportadas, faltantes o ambiguas. Un esquema malformado, o respuestas requeridas faltantes o ambiguas, fallan antes de mutar: no abras un navegador ni mutaciones. Una transferencia al navegador está disponible solo cuando el usuario solicita explícitamente la finalización en el navegador o un formulario seleccionado sintácticamente válido no puede representarse de manera segura/fiel mediante la ruta automatizada; de lo contrario, informa por qué la automatización no es segura y detente.

Control	Manejo requerido
input / textarea	Conserva la etiqueta visible. Requiere una respuesta cuando validations.required es verdadero; de lo contrario, renderiza _Sin respuesta_.
dropdown	Conserva etiquetas y opciones visibles. Requiere el texto exacto de la opción seleccionada; selección única tiene una selección, y selección múltiple conserva las selecciones en el orden de opciones declaradas. Un dropdown requerido necesita al menos una selección válida; un dropdown opcional sin selección renderiza _Sin respuesta_.
checkboxes	Conserva la etiqueta visible y cada opción como - [x] o - [ ] en el orden declarado. Aplica checkboxes individualmente requeridos. Para opciones operativas verificables por el agente, completa proactivamente la acción y márcala solo con evidencia conservada; el agente puede atestiguar explícitamente solo su propio trabajo respaldado por evidencia y no debe atribuir sus acciones al usuario. Hechos personales, consentimiento, declaraciones legales y otras afirmaciones de usuario en primera persona requieren afirmación explícita del usuario; requiere afirmación explícita en primera persona para tales declaraciones del usuario. No marques checkboxes de forma general: una solicitud de publicación no afirma ningún checkbox.

Para cada respuesta, renderiza ### <etiqueta visible> seguido de su valor materializado. Para textarea.attributes.render, encierra la respuesta con el lenguaje declarado y una valla lo suficientemente larga para su contenido. Nunca inventes respuestas, selecciones, confirmaciones o etiquetas.

Una plantilla Markdown puede completarse solo a partir de evidencia conocida en el mismo BODY_FILE privado. Si no existe una plantilla coincidente, usa el fallback estructurado en blanco revisado solo cuando los issues en blanco estén explícitamente habilitados; de lo contrario, detente sin publicar.

Revisión y Publicación

Antes del único intento de creación, revisa el objetivo, título, formulario seleccionado o fallback permitido, cuerpo exacto y etiquetas permitidas. El agente debe completar el escaneo de privacidad/redacción del cuerpo exacto inmediatamente antes de la publicación y conservar evidencia del mismo: reemplaza nombres de proyectos privados, nombres de usuario, nombres de host, rutas de inicio, credenciales y direcciones de red privadas con marcadores de posición útiles sin eliminar la estructura de reproducción.

Crea un directorio temporal de solo propiedad del propietario fuera del repositorio para ambos archivos privados; restringe al usuario actual y limpia ambos archivos en cada salida/resultado:

umask 077
REPO_ROOT="$(git rev-parse --show-toplevel)" || exit 1
REPO_ROOT="$(cd "$REPO_ROOT" && pwd -P)" || exit 1
if [ "$REPO_ROOT" = "/" ]; then
  printf '%s\n' "El directorio temporal está dentro del repositorio" >&2; exit 1
fi
TMP_DIR="$(TMPDIR=/tmp mktemp -d /tmp/gentle-ai-issue.XXXXXXXX)" || exit 1
trap 'rm -rf -- "$TMP_DIR"' EXIT
TMP_DIR_REAL="$(cd "$TMP_DIR" && pwd -P)" || exit 1
case "$TMP_DIR_REAL/" in
  "$REPO_ROOT/"*) printf '%s\n' "El directorio temporal está dentro del repositorio" >&2; exit 1 ;;
esac
chmod 700 "$TMP_DIR_REAL"
BODY_FILE="$TMP_DIR_REAL/body.md"
READBACK_FILE="$TMP_DIR_REAL/readback.json"

Realiza un intento de mutación a través de la ruta automatizada y publica exactamente una vez:

gh issue create --repo "$TARGET" --title "$TITLE" --body-file "$BODY_FILE" "${LABEL_ARGS[@]}"

Cuando la finalización en el navegador esté disponible bajo la decisión del formulario anterior, una transferencia opcional y separada al navegador puede abrir el formulario del repositorio. Nunca es prueba de publicación ni una respuesta a esquemas malformados o respuestas requeridas faltantes/ambiguas:

gh issue create --repo "$TARGET" --web

No reintentes en caso de tiempo de espera, fallo de red, identidad faltante u otro resultado incierto. Captura el número de issue devuelto, luego léelo de vuelta desde el host objetivo verificado antes de informar éxito:

gh issue view "$NUMBER" --repo "$TARGET" --json number,url,title,body,state,labels >"$READBACK_FILE"

Confirma que la lectura de vuelta identifica el issue del host objetivo y que el título y el cuerpo coinciden después de solo la normalización CRLF-a-LF y de nueva línea final. Reporta confirmed solo después de esta lectura de vuelta del host objetivo. De lo contrario, reporta no_write cuando un rechazo autoritativo demuestre que no se creó ningún issue, o unknown y detén todas las mutaciones posteriores.

Triaje

Antes de aprobar o cerrar un issue, verifica que sea concreto, no duplicado, suficientemente evidenciado, dentro del alcance y consistente con la política de etiquetas/estado del repositorio. Si algún punto es incierto, conserva el estado de revisión del repositorio y solicita la evidencia faltante más pequeña.