# Github Issue Authoring

> Converts evidence, specifications, audits, bug reports, and rough notes into scoped, copy-ready GitHub issues or dependency-aware issue batches. Use when defining implementation work clearly without performing the implementation itself.

- Skill: `egohygiene/github-issue-authoring` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add egohygiene/github-issue-authoring`
- Raw SKILL.md: https://api.skillmd.com/api/skills/egohygiene/github-issue-authoring/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: MIT
- Author: egohygiene (https://skillmd.com/u/egohygiene)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/egohygiene/github-issue-authoring

---


# GitHub Issue Authoring

<!-- aether-continuity-disposition: reader -->

## Repository continuity composition

For repository-scoped work, compose `maintain-repository-continuity` in
**Resume** mode before selecting work. This skill is continuity read-only: do
not create, refresh, or otherwise mutate `CONTINUITY.md` unless a separate
authorized repository-changing workflow takes ownership of that handoff.

- **Contribute:** Verified repository context, issue dependencies, scope, acceptance criteria, and evidence gaps
- **Never claim:** That an issue was created or updated without live evidence, or authority to mutate CONTINUITY.md without separate authorization

## Purpose

Transform repository evidence into a clear GitHub issue that another engineer or
agent can execute without guessing scope, constraints, or validation.

## Required Inputs

Resolve as much of the following as possible:

- problem statement, desired outcome, and user motivation
- relevant specifications, audits, notes, or defect evidence
- affected systems, constraints, exclusions, and dependencies
- repository conventions, templates, labels, and validation commands
- unresolved questions or decisions that must stay visible

When repository evidence is incomplete, label assumptions explicitly.

## Workflow

1. extract the durable problem, goal, boundaries, and observable outcome
2. inspect repository evidence before prescribing paths, commands, or ownership
3. choose whether the result should be one issue or an ordered batch of issues
4. write copy-ready issue content using the focused resources:

    - `./references/copy-ready-checklist.md`
    - `./templates/GITHUB_ISSUE.template.md`

5. make acceptance criteria observable and keep non-goals explicit
6. preserve the user's copy-and-paste formatting preference; when fenced blocks would break copying or rendering, use four-space-indented inner code examples instead
7. validate title clarity, internal consistency, dependency order, and execution readiness

## Constraints

- Do not implement the requested work inside the issue-authoring step.
- Do not invent repository paths, commands, labels, or ownership.
- Do not mix multiple independently shippable outcomes into one issue without stating why.
- Do not hide unresolved decisions or missing evidence.
- Do not embed provider-specific tooling instructions into the core workflow.

## Completion Criteria

- [ ] The issue can be executed without reopening accepted decisions.
- [ ] Scope, non-goals, and dependencies are explicit.
- [ ] Validation steps are observable and repository-aware.
- [ ] Copy-ready formatting is preserved.
- [ ] Missing evidence and open questions remain visible.

## Provenance

This canonical skill is first-party Ego Hygiene content curated from the staged
candidate at `.staging/skills/github-issue-authoring/SKILL.md`.

## Source Delta

- Adopted: the staged workflow for extracting durable intent, inspecting the
  repository before prescribing work, and validating issue completeness.
- Rewritten: canonical metadata, copy-ready template, deterministic evals, and
  the explicit formatting rule for four-space-indented inner code examples when
  fenced blocks would copy poorly.
- Rejected: the placeholder `github-issue` staging copy as a synonym identity;
  broader or specialized legacy variants such as `github-issues` and
  `create-github-issue-*` were reviewed as overlap but not adopted into the core
  provider-neutral workflow.