executing-project-tasks

Étoiles13

Forks1

Mis à jour16 juillet 2026 à 02:30

Use when a task has written repo truth and implementation should proceed step by step with evidence.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Source

eng-cc

eng-cc/oasis7

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Métiers associésSOC

Basé sur la classification professionnelle SOC

Autres occupations informatiquesProfessions informatiques et mathématiques·SOC 15-1299

SKILL.md

readonly

name	executing-project-tasks
description	Use when a task has written repo truth and implementation should proceed step by step with evidence.

Executing Project Tasks

Canonical lifecycle: state machine, states, gates.

When to Use

Use when the task already has written scope in prd.md, project.md, a handoff, or GitHub-backed task truth. Do not use for unresolved direction, observed unexplained failures, or finishing.

Procedure

Run a brief plan-gap review before editing: confirm acceptance criteria, dependencies, verification, and out-of-scope items. Do not create a second planning system outside prd.md / project.md / GitHub-backed task truth.
Record ordered steps and required professional slices in GitHub task issue evidence comments.
Implement one bounded step in its declared write scope.
Run the step-level verification and inspect the output. Route commands expected to emit broad logs or search results through ./scripts/pm/bounded-command-output.py; inspect the bounded summary and retain the reported full artifact/digest for debugging.
Append result, evidence, deviation, and next step to the same task issue.
Repeat until scope is implemented and verified, then route to finishing-a-development-branch.

If any command, test, or behavior is unexpected, automatically route to systematic-debugging, resolve the root cause, and resume the same step. Pause only for canonical external_wait or capability_blocked, recording resume authority and instruction from the canonical state contract.

Use ./scripts/pm/append-execution-log.sh when a durable local execution ledger is required. Module verification does not imply integration or release readiness.

Return Contract

completed step and changed paths
fresh verification command/result
GitHub task issue evidence link
remaining steps, or canonical blocker with resume instruction

Guardrails

Preserve declared write scopes and task truth; do not claim broader readiness than the evidence tier.

Known Failure Modes

Large unverified batches; parallel planning truth; continuing after unexplained failures; treating module checks as release proof.

Plus depuis ce dépôt

même dépôt

default-workflow-bootstrap

eng-cc/oasis7

Use when any oasis7 user request starts and must bind the canonical worktree, GitHub-backed task truth, and owner before routing.

2026-07-2613

requesting-repo-owned-review

eng-cc/oasis7

Use when a branch is about to create a PR and needs fresh involved-role review.

2026-07-2613

finishing-a-development-branch

eng-cc/oasis7

Use when implementation is verified and the branch must proceed through review, PR, merge, and cleanup.

2026-07-1613

verification-before-completion

eng-cc/oasis7

Use when about to claim a task is complete, tests passed, a branch is ready for PR, or a PR is ready to merge. Requires fresh verification, direct output inspection, and use of `./scripts/pm/claim-ready.sh` when the claim can be mapped to one verification command.

2026-07-1613

repo-owned-workflow-router

eng-cc/oasis7

Use when a bound oasis7 task needs the next repo-owned workflow phase selected.

2026-07-1513

tpm-production-supervisor

eng-cc/oasis7

Use when assessing or developing the blocked production-supervisor target for a bound oasis7 task spanning multiple lifecycle phases.

2026-07-1213

Executing Project Tasks

When to Use

Use when the task already has written scope in prd.md, project.md, a handoff, or GitHub-backed task truth. Do not use for unresolved direction, observed unexplained failures, or finishing.

Procedure

Run a brief plan-gap review before editing: confirm acceptance criteria, dependencies, verification, and out-of-scope items. Do not create a second planning system outside prd.md / project.md / GitHub-backed task truth.

Record ordered steps and required professional slices in GitHub task issue evidence comments.

Implement one bounded step in its declared write scope.

Run the step-level verification and inspect the output. Route commands expected to emit broad logs or search results through ./scripts/pm/bounded-command-output.py; inspect the bounded summary and retain the reported full artifact/digest for debugging.

Append result, evidence, deviation, and next step to the same task issue.

Repeat until scope is implemented and verified, then route to finishing-a-development-branch.

Use ./scripts/pm/append-execution-log.sh when a durable local execution ledger is required. Module verification does not imply integration or release readiness.

Return Contract

completed step and changed paths

fresh verification command/result

GitHub task issue evidence link

remaining steps, or canonical blocker with resume instruction

Guardrails

Preserve declared write scopes and task truth; do not claim broader readiness than the evidence tier.

Known Failure Modes

Large unverified batches; parallel planning truth; continuing after unexplained failures; treating module checks as release proof.