56 lines
2.8 KiB
Markdown
56 lines
2.8 KiB
Markdown
---
|
|
name: execute-tasks
|
|
description: "Execute and complete a specified list of project tasks sequentially. Use when asked to work on, implement, execute, or do a set of task IDs. Supports writing, research, planning, software, and other projects; verifies results, records human review steps, and transitions completed work to testing."
|
|
---
|
|
|
|
# Execute Tasks
|
|
|
|
## Orient
|
|
|
|
1. Read [AGENTS.md](../../../AGENTS.md),
|
|
[project-config.json](../../../project-config.json), and
|
|
[the task tracker](../../../docs/tasks.md).
|
|
2. Load the `task-management` skill and query each requested task with
|
|
`./scripts/get-task <ID>`. Do not assume a prefix or software project.
|
|
3. Confirm tasks are ready for work. If not, explain the status and ask for
|
|
direction; do not silently bypass blocked or unscoped work.
|
|
4. Inspect existing materials and changes. Preserve unrelated work.
|
|
|
|
## Execute Sequentially
|
|
|
|
For each task:
|
|
|
|
1. Transition it to `in_progress` using `update-task`.
|
|
2. Resolve material ambiguities with the user and agree on acceptance criteria.
|
|
3. Complete the requested deliverable using the project's established methods.
|
|
For a novel this may be manuscript edits; for research it may be source
|
|
analysis; for software it may be code. Do not invent a language or platform.
|
|
4. Update directly related documentation and verify acceptance criteria.
|
|
Use configured commands only when applicable. For non-command workflows,
|
|
review deliverables and report what still needs human judgment.
|
|
5. When editing the bundled task tooling, run
|
|
`python3 -m unittest discover -s scripts/tests -v`.
|
|
6. Record step-by-step human verification in `docs/task-verification.md`,
|
|
creating it if needed. Include expected results and limitations.
|
|
7. Transition successful work to `testing` with `--check-all`, then query
|
|
the task again to verify the transition. Never mark your own work `done`.
|
|
8. Record newly discovered work with `add-task`; do not expand scope silently.
|
|
|
|
Stop and explain blockers when an acceptance criterion cannot be met. Do not
|
|
present unverified work as complete.
|
|
|
|
## Persistence
|
|
|
|
- Do not commit unless asked. If asked, inspect `git status` and include the
|
|
task/verification changes relevant to the deliverable. Do not stage unrelated
|
|
edits blindly.
|
|
- Use descriptive commit messages including task IDs and the required
|
|
co-author trailer where applicable.
|
|
- If project-description documents exist, check their last update and refresh
|
|
verification timestamps after major changes or 20 commits. Do not require
|
|
nonexistent project-specific documents.
|
|
- Human reviewers move `testing` to `done` and migrate verification steps to
|
|
`docs/human-tests.md`, creating it when first needed.
|
|
- If CLI tools cannot run, disclose that and agree on a manual workflow with
|
|
the user rather than reporting fabricated checks.
|