backlog-queue

스타0

포크0

업데이트2026년 7월 19일 21:22

Wiki tickets under docs/wiki/tickets/ are the canonical task queue, each linked to a GitHub issue. Use when picking work, claiming an issue, or preparing PR references.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

출처

synthet

synthet/project-twelve

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Backlog queue (ProjectTwelve fork)

ProjectTwelve adaptation: The canonical task queue is wiki tickets at docs/wiki/tickets/README.md, each with frontmatter linking to a GitHub issue. This fork replaces the upstream GitHub Project Stage workflow. Do not use board Stage field IDs.

When to use

The user asks to pick the next task, start work, or "what's next".
The user asks to file a new backlog item.
A PR is being prepared and needs a Closes #N reference.
A task has hit a blocker or is ready for review.
An agent picks up a task without a corresponding issue — stop and file one first (or run python3 scripts/sync_wiki_tickets_to_github.py if the ticket exists but issue is missing).

The five-step contract

Every contributor (human or AI) follows the same five steps.

1. Pick from open wiki tickets

Run the compiled recommender (or use pick-next-task):

python scripts/pick_next_task.py

It ranks open tickets by phase (P0 → P5) then ticket id. If nothing is ready, stop and ask the maintainer. Do not invent new work.

2. Claim the linked GitHub issue

Use /task-claim <issue-number> (preferred) or:

gh issue edit <N> --repo synthet/project-twelve --add-assignee @me

Update the ticket markdown frontmatter status to claimed (or in_progress on first commit).

3. Mark in progress on first commit

Update ticket frontmatter status: in_progress when you push the first commit for the task.

4. If blocked, comment on the issue

gh issue comment <N> --repo synthet/project-twelve --body "Blocked: <reason + what would unblock>."

Update ticket frontmatter status: blocked.

5. PR references the issue

Your PR description must contain Closes #<N> when the PR completes the ticket. Use Refs #<N> only for partial work that leaves the issue open.

In the same PR (or an immediate follow-up before calling the task done):

Set ticket frontmatter status: done (canonical values: open | claimed | in_progress | blocked | done).
Update the matching row in docs/wiki/tickets/README.md.
Check exit-evidence boxes in the ticket body when the acceptance criteria are met.

After merge, confirm GitHub auto-closed the issue. If the PR used Refs by mistake, close the issue manually with a comment citing the merge commit.

Filing a new task

Add a ticket markdown file under docs/wiki/tickets/ following existing frontmatter conventions.
Update docs/wiki/tickets/README.md index.
Create the GitHub issue (manually or via scripts/sync_wiki_tickets_to_github.py).
Link the issue URL in the ticket frontmatter (github_issue).

Label conventions

When creating issues, prefer:

spec-driven — all backlog items
Phase labels matching ticket prefix (e.g. p0, p1)
type:spec, type:bug, type:chore as appropriate

Human reference

Full contract: docs/project/00-backlog-workflow.md.

이 저장소의 다른 Skills

같은 저장소

unity-tests

synthet/project-twelve

Run ProjectTwelve Unity batch validation and EditMode/PlayMode test suites via Unity 6000.5.1f1. Use when the user or ticket asks to run Unity tests, EditMode fixtures, batchmode validation, or verify test results from TestResults/*.xml.

2026-07-220

agent-memory

synthet/project-twelve

Log agent sessions, consolidate project memory (dream), promote reviewed memory, and load context for new chats. Use when ending a session, improving cross-session recall, or when the user mentions agent memory, dream, log-session, or memory.md.

2026-07-190

pick-next-task

synthet/project-twelve

Recommend the next open wiki ticket to work on, ranked by phase then priority, without claiming or mutating anything. Use when the user asks "what's next", to pick the next task, or to start work without a specific ticket in hand.

2026-07-190

repo-sync

synthet/project-twelve

Sync project-twelve with the Assets/_Licensed submodule via fetch_remotes.py, git hooks, and /fetch-remotes. Use at session start, before picking backlog work, or when the user asks to sync repos or get latest.

2026-07-190

commit-and-push

synthet/project-twelve

Use when the user asks to commit and push, publish, ship, or prepare a release commit. Guides staging only intended changes, writing a Conventional Commit, committing, and pushing to origin after verifying status and diff.

2026-07-190

karpathy-guidelines

synthet/project-twelve

Apply Karpathy's anti-pattern checklist before/during non-trivial coding — surface assumptions, resist overcomplication, keep diffs surgical, frame work as verifiable goals. Use on ambiguous or multi-step tasks, or when the user asks for a "Karpathy pass".

2026-07-190

name	backlog-queue
description	Wiki tickets under docs/wiki/tickets/ are the canonical task queue, each linked to a GitHub issue. Use when picking work, claiming an issue, or preparing PR references.

Backlog queue (ProjectTwelve fork)

ProjectTwelve adaptation: The canonical task queue is wiki tickets at docs/wiki/tickets/README.md, each with frontmatter linking to a GitHub issue. This fork replaces the upstream GitHub Project Stage workflow. Do not use board Stage field IDs.

When to use

The user asks to pick the next task, start work, or "what's next".
The user asks to file a new backlog item.
A PR is being prepared and needs a Closes #N reference.
A task has hit a blocker or is ready for review.
An agent picks up a task without a corresponding issue — stop and file one first (or run python3 scripts/sync_wiki_tickets_to_github.py if the ticket exists but issue is missing).

The five-step contract

Every contributor (human or AI) follows the same five steps.

1. Pick from open wiki tickets

Run the compiled recommender (or use pick-next-task):

python scripts/pick_next_task.py

It ranks open tickets by phase (P0 → P5) then ticket id. If nothing is ready, stop and ask the maintainer. Do not invent new work.

2. Claim the linked GitHub issue

Use /task-claim <issue-number> (preferred) or:

gh issue edit <N> --repo synthet/project-twelve --add-assignee @me

Update the ticket markdown frontmatter status to claimed (or in_progress on first commit).

3. Mark in progress on first commit

Update ticket frontmatter status: in_progress when you push the first commit for the task.

4. If blocked, comment on the issue

gh issue comment <N> --repo synthet/project-twelve --body "Blocked: <reason + what would unblock>."

Update ticket frontmatter status: blocked.

5. PR references the issue

Your PR description must contain Closes #<N> when the PR completes the ticket. Use Refs #<N> only for partial work that leaves the issue open.

In the same PR (or an immediate follow-up before calling the task done):

Set ticket frontmatter status: done (canonical values: open | claimed | in_progress | blocked | done).
Update the matching row in docs/wiki/tickets/README.md.
Check exit-evidence boxes in the ticket body when the acceptance criteria are met.

After merge, confirm GitHub auto-closed the issue. If the PR used Refs by mistake, close the issue manually with a comment citing the merge commit.

Filing a new task

Add a ticket markdown file under docs/wiki/tickets/ following existing frontmatter conventions.
Update docs/wiki/tickets/README.md index.
Create the GitHub issue (manually or via scripts/sync_wiki_tickets_to_github.py).
Link the issue URL in the ticket frontmatter (github_issue).

Label conventions

When creating issues, prefer:

spec-driven — all backlog items
Phase labels matching ticket prefix (e.g. p0, p1)
type:spec, type:bug, type:chore as appropriate

Human reference

Full contract: docs/project/00-backlog-workflow.md.