executing-project-tasks

Stars13

Forks1

UpdatedJuly 16, 2026 at 02:30

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

Installation

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.

Source

eng-cc

eng-cc/oasis7

View GitHub Repository View Creator Repositories

Download

Related occupationsSOC

Based on SOC occupation classification

Computer Occupations, All OtherComputer and Mathematical Occupations·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.

More from this repository

same repository

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.