local-ticket-system

Original：🇨🇳 Chinese

Translated

Set up a Markdown-based local ticket management system for your project. Create task, bug, and chapter tickets in the .local/ticket/ directory, and track progress using checklists. It can be used casually since it is not managed by Git. Language and framework agnostic. Use when requested: "introduce ticket system", "task management with Markdown", "set up local ticket management", "create ticket", "create bug ticket", "create chapter", "create epic", "local ticket system", "setup ticket management".

3installs

Sourcetbsten/skills

Added on2026-05-20

NPX Install

npx skill4agent add tbsten/skills local-ticket-system

SKILL.md Content (Chinese)

View Translation Comparison →

local-ticket-system

Set up a directory-based ticket management system in

.local/ticket/

for your project to create and manage tickets.

Usage

Use in any of the following situations:

Want to newly introduce local ticket management to a project
Want to add task, bug, or chapter tickets to an existing ticket system
Want to change the status of a ticket (move to done / closed / archived / deferred)

Step 1: Setup (First time only)

If

.local/ticket/

does not exist in the project, perform the following steps:

Create the
```
.local/ticket/
```
directory
Copy
```
assets/about.md
```
as
```
.local/ticket/about.md
```

Copy

assets/task-0xx-template.md

as

.local/ticket/task-0xx-template.md

Copy

assets/chapter-template.md

as

.local/ticket/chapter-template.md

Add
```
.local/
```
to
```
.gitignore
```
if it is not already included

Skip if

.local/ticket/

already exists.

Step 2: Determine Ticket Type

Before creating a ticket, analyze the user's requirements and select the appropriate type.

Type Definitions

Type	Purpose	Granularity
task	A single unit of work. Granularity that can be implemented and committed	Small to medium. Can be completed in one work session
bug	Record and fix existing defects	Small to medium. One ticket per bug
chapter	A high-level concept that groups multiple tasks/bugs	Large. Proceed by organizing requirements → splitting into tasks/bugs

Decision Criteria

Check in the following order:

Is it an existing defect? →
```
bug
```
Does it need to be split into multiple work steps? →
```
chapter
```
- Requirements are still ambiguous, requiring design and consideration
- Changes span multiple screens/features
- Involves changes across multiple layers such as DB design + API + frontend
Can it be completed in one work session? →
```
task
```

If unsure, confirm with the user. If you set something that should be a chapter as a task, the ticket will become bloated and difficult to manage. Conversely, setting something that can be a task as a chapter will create unnecessary overhead.

Step 3: Create Ticket

Create a ticket according to the type determined in Step 2.

Naming Conventions

Task:

task-{3-digit serial number}-{slug}.md

(example:

task-001-add-login.md

)

Bug:

bug-{3-digit serial number}-{slug}.md

(example:

bug-001-null-pointer.md

)

Chapter:

chapter-{slug}.md

(example:

chapter-multi-tenant.md

)

For task / bug serial numbers, get the maximum number from existing tickets (including done/, closed/) in

.local/ticket/

and add 1. Chapters do not use serial numbers.

Title Format

The

# Title

line in the ticket body should start with one emoji prefix that represents the content. Apply this regardless of type (task / bug / chapter).

Example:

markdown

# 🗑️ Delete unnecessary code
# ✨ Add login functionality
# 🐛 null pointer in user lookup
# 🏗️ Multi-tenant support chapter

You can basically choose any emoji that fits the content freely. If unsure, select from the reference table below.

Emoji	Purpose
✨	New feature / feat
🐛	Bug fix / fix
🗑️	Delete unnecessary code/files
♻️	Refactoring
📝	Documentation
✅	Add/modify tests
🎨	Code style / formatting
⚡	Performance improvement
🔧	Configuration change
🚧	WIP / In progress
🔥	Large-scale deletion
🔒	Security fix
⬆️	Dependency upgrade
⬇️	Dependency downgrade
🚀	Deployment / release
💄	UI / style adjustment
🏗️	Architecture change / chapter
🚨	Fix lint warnings
🔀	Merge
📦	Packaging
🧪	Experimental feature
🩹	Minor fix
💚	CI fix
📈	Metrics / analytics
🌐	i18n / l10n
♿	Accessibility
🏷️	Type / type definition
🚸	UX improvement
🩺	Health check / diagnosis

Task Ticket Structure

Based on the template (

assets/task-0xx-template.md

), structure it with the following sections:

markdown

# {emoji} Title

Overview description

## Verification Method

Steps/commands for operation verification

## Checklist

- [ ] Implementation task 1
- [ ] Implementation task 2
- [ ] Delete unnecessary files
- [ ] Verification (perform items in the Verification Method section)
- [ ] Self-review
- [ ] commit
- [ ] Move this ticket to done/

Select one

{emoji}

according to the "Title Format" section.

Be sure to include the common items at the end of the checklist (from deleting unnecessary files to moving to done).

Bug Ticket Structure

In addition to the task structure, include the following:

Reproduction Steps — Specific steps to reproduce the issue
Expected Behavior and Actual Behavior
Suspected Cause — As much as you know
Candidate Response Strategies — List multiple options if available

Chapter Ticket Structure

Based on the template (

assets/chapter-template.md

), structure it with the following sections:

markdown

# {emoji} Title

## What We Want to Do

Rough purpose and background

## Issues / Motivation

Why we want to do this, what are the current issues

## Scope (Tentative)

- Bullet points of roughly what we want to do

## What We Won't Do (Tentative)

- Items explicitly out of scope

## Items Needing Consideration

- [ ] Things that must be decided before design/implementation

## How to Proceed

1. [ ] Finalize requirements and scope
2. [ ] Design (DB / API / screens)
3. [ ] Split into implementation tickets (task-xxx, bug-xxx, etc.)
4. [ ] Implementation
5. [ ] Testing and operation verification
6. [ ] Deployment

## Reference Information

- Related existing tickets, documents, external links, etc.

Step 4: Ticket Status Management

Task / Bug Lifecycle

Created: Place directly under
```
.local/ticket/
```
In Progress: Implement while completing the checklist
Done: Implementation and commit are complete → Move to
```
done/
```
Closed: Operation verification and validation are complete → Move to
```
closed/
```
Deferred: Intentionally postponed → Move to
```
deferred/
```
(intention to resume later)

Change status by moving the file:

bash

mv .local/ticket/task-001-add-login.md .local/ticket/done/

Chapter Lifecycle

Created: Place directly under
```
.local/ticket/
```
Under Consideration: Refine scope and items needing consideration
Split: Split into task / bug tickets. Record the names of split tickets in the chapter
Archived: Move to
```
archived/
```
when all child tickets are done/closed
Deferred: When postponing start → Move to
```
deferred/
```

Chapters are not moved to done/closed. Completion of child tickets means completion of the chapter.

Moving to deferred/

A place to put tickets/chapters that "will not be started in the current phase but are intended to be resumed in the future". It means postponement, not completion.

Before moving, add the following to the ticket:

markdown

**Deferred Reason**: <Why it is being postponed>
**Reopen Trigger**: <Conditions for resuming work>
**Deferred Date**: YYYY-MM-DD

When resuming work, move it back from

deferred/

to directly under

ticket/

.

local-ticket-system

NPX Install

Tags

SKILL.md Content (Chinese)

local-ticket-system

Usage

Step 1: Setup (First time only)

Step 2: Determine Ticket Type

Type Definitions

Decision Criteria

Step 3: Create Ticket

Naming Conventions

Title Format

Task Ticket Structure

Bug Ticket Structure

Chapter Ticket Structure

Step 4: Ticket Status Management

Task / Bug Lifecycle

Chapter Lifecycle

Moving to deferred/