| name | github |
| description | GitHub operations: create, edit, link, list issues and manage Epic > Feature > Story hierarchy. Invoke before any GitHub operation. |
| argument-hint | [operation] [args] |
GitHub Operations
Initialization
Before any command, detect the current repository:
REPO=$(gh repo view --json nameWithOwner -q .nameWithOwner)
Use $REPO in gh -R "$REPO" commands.
Issue types
| Type | Label | Title prefix | Parent | Parent section |
|---|
| Epic | Type: Epic | [EPIC] | - | - |
| Feature | Type: Feature | [FEATURE] | Epic | ## Features |
| Story | Type: Story | [STORY] | Feature | ## User Stories |
| Bug | Type: Bug | [BUG] | - | - |
| Spike | Type: Spike | [SPIKE] | - | - |
| Tech Debt | Type: Tech Debt | [TECH DEBT] | - | - |
Title rules: no emoji, prefix in brackets, concise.
Hierarchy (GitHub Free)
No native sub-tasks. Hierarchy is managed by:
#N references in the parent description (dedicated section)- Cross-references in comments when linking issues
Epic
└── Feature (reference in ## Features)
└── Story (reference in ## User Stories)
GitHub does not have a native relates_to link API like GitLab. Use description
references (#N) and comments to establish relationships.
Understand before acting
Before creating, modifying, or closing an issue, always read the existing context:
- Read the full issue (description + all comments) before editing or closing
- For bugs or tech debt: check linked issues and related PRs to understand prior
decisions and constraints that led to the current implementation
- If a fix seems obvious but the code looks intentionally written that way, search
for the original issue or PR that introduced it before overriding
- Never close an issue as "duplicate" or "won't fix" without reading its full history
When investigating a bug or refactoring request, search for related issues:
gh issue list -R "$REPO" --search "keyword"
gh issue view {number} -R "$REPO" --json body -q .body
Behavioral rules
After creating an issue
- Always update the parent description to add the reference
- Format in the parent description:
- #N - short description
After closing an issue
- Add a closing comment explaining what was delivered (files, decisions)
- If it's the last Story of a Feature: check whether the Feature can be closed
Descriptions
Always use a HEREDOC for multi-line descriptions:
--body "$(cat <<'EOF'
content here
EOF
)"
Templates are in .github/ISSUE_TEMPLATE/.
See templates.md for structure per issue type.
Security
- NEVER put tokens in plain text (gh uses its local config)
- NEVER put secrets in issue descriptions
- NEVER put PII in titles or descriptions
Personas (user stories)
Two persona registries:
- Infrastructure & governance (15 personas):
governance-compliance/docs/03-organization/ORG-05-PERSONAS.md
- Application-level (5 personas):
granit-dotnet/docs/guide/personas-applicatifs.md
NEVER invent a new persona.
Infra/governance personas: SRE, Ingenieur DevOps, Developpeur, Architecte, DBA,
RSSI, DPO, CTO, Direction, Directeur juridique, Auditeur interne, Auditeur externe,
Utilisateur, Professionnel de sante, Product Owner
Application personas: Visiteur, Utilisateur authentifie, Administrateur d'application,
Approbateur, Gestionnaire de contenu
NEVER use hybrid roles ("slash roles" like SRE / DevOps).
Context (on-call, audit) goes in the story body, not in the persona.
Resources
- Detailed workflows (create, link, close): workflows.md
- Description templates per type: templates.md
- gh command reference: reference.md
- Persona registry:
governance-compliance/docs/03-organization/ORG-05-PERSONAS.md
