nodefony-ticket

Writes and organizes GitHub issues with Conventional Commits titles and verifiable bodies.

Updated Dec 19, 2023
One-click install
npx skills add https://github.com/nodefony/nodefony-core --skill nodefony-ticket-nodefony
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: nodefony-ticket
Source: https://github.com/nodefony/nodefony-core/tree/main/.claude/skills/nodefony-ticket
Command: npx skills add https://github.com/nodefony/nodefony-core --skill nodefony-ticket-nodefony

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve? GitHub issues that are vague, unverifiable, or invisible to the project board force every future reader to redo the exploration work, wasting entire sessions on context reloading. This Skill enforces a disciplined ticket-writing protocol for the Nodefony repository so each issue is understandable in ten seconds and actionable without re-reading the codebase. ## Core Features & Use Cases - Standardized titles and bodies: Titles follow Conventional Commits (type, scope, infinitive description under 60 characters) and bodies follow four fixed blocks — problem, file:line proof, observable done-criterion, estimation and dependencies. - Board governance automation: Scripts lint the GitHub Projects board for binary-verifiable inconsistencies (missing milestones, duplicated order ranks, inverted dependencies, stale in-progress statuses) and sync issue templates with the protocol. - Parent/sub-ticket structuring: Detects when one ticket hides multiple independent done-criteria and splits it into a parent with autonomous children linked via the GitHub sub-issues API. - Use Case: Before opening an issue about a documentation bug, run the Skill to produce a compliant title like "docs(guides): retirer une entrée obsolète du hub", a body with a verifiable file:line anchor, and register it on the board with milestone, priority, and order in one command. ## Quick Start Ask the assistant to create a GitHub ticket for the Nodefony repository describing the problem you found, and it will produce a compliant title, structured body, and board registration.

Frequently Asked Questions about nodefony-ticket

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write a GitHub issue title with Conventional Commits?

Use the format type(scope): description with an infinitive verb, lowercase, under 60 characters, and no final period. Types include feat, fix, docs, refactor, perf, test, build, ci, and chore, matching the commitlint rules already enforced on the repository.

How do I create parent and sub-issues on GitHub?

Use gh issue create with the --parent flag at creation time, or call the addSubIssue GraphQL mutation with both node IDs afterward. The parent carries shared context and the sum of children's estimates, while each child stays autonomous.

What should a good GitHub issue body contain?

Four blocks in fixed order: the problem in two to four sentences, a current file:line proof or reproducing command, an observable done-criterion such as a passing test, and an estimation with dependencies. A Lexique block precedes them when abbreviations are used.

Why does gh project item-list give wrong board results?

The command truncates results silently at its limit, so sorting operates on an incomplete subset. The Skill mandates a paginated GraphQL snapshot script instead, and a test gate forbids item-list in all agent tooling.

When should a ticket be split into multiple tickets?

Split when the done-criteria block contains two or more independent criteria achievable by separate gestures in different files. Keep them together if both halves would be done in the same session on the same files, since each ticket pays its own context-loading cost.

Does this Skill work outside the Nodefony repository?

The scripts hardcode the nodefony organization, nodefony-core repository, and project number 2, so they target that specific project board. The writing protocol itself is portable, but the automation requires adaptation for other repositories.