Menu
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.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
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.
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.
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.
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.
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.
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".
| 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. |
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.
Closes #N reference.python3 scripts/sync_wiki_tickets_to_github.py if the ticket exists but issue is missing).Every contributor (human or AI) follows the same five steps.
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.
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).
Update ticket frontmatter status: in_progress when you push the first commit for the task.
gh issue comment <N> --repo synthet/project-twelve --body "Blocked: <reason + what would unblock>."
Update ticket frontmatter status: blocked.
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):
status: done (canonical values: open | claimed | in_progress | blocked | done).docs/wiki/tickets/README.md.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.
docs/wiki/tickets/ following existing frontmatter conventions.docs/wiki/tickets/README.md index.scripts/sync_wiki_tickets_to_github.py).github_issue).When creating issues, prefer:
spec-driven — all backlog itemsp0, p1)type:spec, type:bug, type:chore as appropriateFull contract: docs/project/00-backlog-workflow.md.