メニュー
Operate ODA GitHub Issues and the ODA Board consistently. Use when creating, updating, listing, moving, or reclassifying tracked work in GitHub for this repository.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
Assess likely downstream impact, decide what should be reconciled now versus carried forward explicitly, and keep the repository coherent without sweeping every related surface.
Apply, review, improve, or maintain a repository's Copilot customization with the Ownership-Driven AI Customization Architecture and the latest official GitHub Copilot docs. Use when shaping or auditing a repository's customization map, governance files, supporting docs, and safeguards for drift, health, weak controls, outdated assumptions, or when deciding how a specific customization problem should be handled.
Investigate inconsistent or incorrect behavior with a structured workflow.
SOC 職業分類に基づく
| name | oda-task-tracking |
| description | Operate ODA GitHub Issues and the ODA Board consistently. Use when creating, updating, listing, moving, or reclassifying tracked work in GitHub for this repository. |
Use this skill for operational work with repository issues and the ODA Board.
This is a workflow for task tracking, not a path-specific coding rule.
Repository: HenriqueCotta/ownership-driven-ai-customization-architecture
Project: ODA Board
Project owner: HenriqueCotta
Project number: 4
A tracked task is a repository issue that may also be represented by the same issue as a project item.
The project Status field is the board status. Use only Todo, In Progress, or Done.
Use existing repository labels when they fit. Do not invent a label taxonomy or create new labels unless the user explicitly asks.
There is no board Area field. Do not simulate one in issue text unless the user asks for a planning convention change.
Interpret board authority according to ownership/repository/oda-board.instructions.md.
Search for existing issues before creating a new tracked task.
When creating or rewriting an issue, keep the body concise and actionable with outcome, context, acceptance criteria, and verification.
After a create or update operation, keep the issue body, labels, project status, and linked updates coherent.
When moving a task, update the project status to the requested valid value or the closest valid value. Ask one focused question only when ambiguity would change the result.
When listing work or answering what is next, prefer open Todo items and explain the priority briefly from board state and repository context.
If GitHub issue access is unavailable, do not create or update task state.
If project access is unavailable but issue access works, update only the issue when that still satisfies the request and clearly report that board synchronization is blocked.
If the board state could change the answer, treat that part as verification-blocked instead of guessing.
Never delete issues or project items.
Do not close or mark work Done unless the user asks for that change or the repository evidence clearly supports it.
If this tracking workflow changes materially, update ownership/repository/oda-board.instructions.md and the oda-board supporting-source entry when they carry the same policy.