openspec-task-loop
OpenSpec Task Loop
Subagent Architecture
This skill uses a strictly sequential pipeline of subagents, where each iteration accumulates context and depends on the previous step. Pattern: E (Staged Pipeline) + C (Review Loop).
Agents
| Agent | Role | Trigger |
|---|---|---|
| spec-scaffolder | Create all OpenSpec artifacts (proposal.md, design.md, tasks.md, specs/) | After task selection |
| implementer | Implement scoped task, update checkboxes, run validation | After spec scaffolding |
| verifier | Independently check quality gate: scope atomicity, acceptance criteria, spec-to-test alignment | After implementation complete |
| archiver | Merge spec deltas, move to archive, update parent tasks.md | After verification passed |
Sequential Dependency
- No Parallelism: Step N+1 depends on Step N completion
- Context Accumulation: Each agent reads previous artifacts and extends understanding
- Quality Gates: Verifier ensures each stage is solid before proceeding
Why Sequential: Multiple task iterations (5-10) degrade reasoning quality significantly without this staged approach. Each step builds confidence and catches issues early.
Environment Check
Before executing:
- Verify git access to repository
- Confirm write permissions to openspec/ directory
- Check for existing task lists in project root (tasks.md)
- Ensure references/openspec-task-templates.md is available
Repo Sync Before Edits (mandatory)
Before creating/updating/deleting files in an existing repository, sync the current branch with remote:
branch="$(git rev-parse --abbrev-ref HEAD)"
git fetch origin
git pull --rebase origin "$branch"
If the working tree is not clean, stash first, sync, then restore:
git stash push -u -m "pre-sync"
branch="$(git rev-parse --abbrev-ref HEAD)"
git fetch origin && git pull --rebase origin "$branch"
git stash pop
If origin is missing, pull is unavailable, or rebase/stash conflicts occur, stop and ask the user before continuing.
Overview
Run OpenSpec as one task = one change. Keep scope tight, generate artifacts, implement, verify, and archive before moving to the next task.
Workflow Decision
- If
/opsx:*commands are supported in the current coding tool: use native OPSX flow. - If not supported: use manual fallback by creating files under
openspec/changes/<change-id>/.
Core Loop (Single Task)
For each selected task from tasks.md:
-
Select exactly one task
- Keep one atomic unit of value (usually 1–3 dev days).
- If too large, split before proceeding.
-
Create a task-scoped change
- Use change id format:
task-<task-id>-<short-slug>(example:task-2-3-pin-crud).
- Use change id format:
-
Plan with OpenSpec artifacts
proposal.md: intent, scope, acceptance criteria, out-of-scope.specs/.../spec.md: requirements and GIVEN/WHEN/THEN scenarios.design.md: implementation approach and tradeoffs.tasks.md: implementation checklist for this single task.
-
Implement only this task scope
- Do not include unrelated refactors.
- Update checkboxes as work completes.
-
Verify before archive
- Validate completeness, correctness, coherence.
- Fix critical mismatches before archive.
-
Archive and sync
- Merge delta specs if needed.
- Archive change folder.
- Mark the parent project task complete.
Native OPSX Command Path
Use this sequence per task:
/opsx:new task-<task-id>-<slug>
/opsx:ff <change-id> # or /opsx:continue for stepwise control
/opsx:apply <change-id>
/opsx:verify <change-id>
/opsx:archive <change-id>
Rules:
- Prefer
/opsx:continuewhen requirements are still unclear. - Prefer
/opsx:ffwhen scope is clear and small. - If implementation reveals drift, update artifacts before continuing.
Manual Fallback Path (No /opsx Support)
If slash commands are unavailable:
- Ensure OpenSpec tree exists (
openspec/changes,openspec/specs). - Scaffold one change folder with:
proposal.mddesign.mdtasks.mdspecs/<capability>/spec.md
- Read
references/openspec-task-templates.mdbefore scaffolding task artifacts. - Implement task and update checkboxes.
- Run local validation/tests.
- Merge spec deltas into
openspec/specs/and move change toopenspec/changes/archive/<date>-<change-id>/.
Quality Gate (must pass before archive)
- Scope remained single-task and atomic
- Acceptance criteria satisfied
- Spec scenarios reflected in tests or executable checks
- No unrelated files changed
- Parent
tasks.mdupdated with completion state - Archive note includes what changed and why
Output Format for Updates
When reporting progress, use:
Task: <id + title>
Change: <openspec change id>
Status: planning | implementing | verifying | archived
Done:
- ...
Next:
- ...
Risks/Notes:
- ...
Expected Output
For each completed task iteration you should see:
- An OpenSpec change folder at
openspec/changes/<change-id>/containingproposal.md,design.md,tasks.md, andspecs/<capability>/spec.md - Implemented code with all task checkboxes checked off
- A verifier report confirming scope atomicity, acceptance criteria met, and spec-to-test alignment
- The change folder moved to
openspec/changes/archive/<date>-<change-id>/ - Parent
tasks.mdupdated with the completed task marked done - A progress report in the Output Format block showing
Status: archived
Edge Cases
- Task is too large: Split into smaller atomic subtasks (1–3 dev days each) before proceeding; do not start implementation on an oversized task.
- No
/opsxcommand support: Fall back to manual file scaffolding underopenspec/changes/and follow the Manual Fallback Path steps. - Missing
references/openspec-task-templates.md: Warn the user and proceed with minimal artifacts; request the templates file to improve scaffold quality. - Verifier finds critical mismatch: Block archiving, surface the specific gap, and fix before re-verifying; never archive a failing quality gate.
- Merge conflicts during rebase: Stop, surface the conflict to the user, and do not auto-resolve changes in spec or implementation files.
- Tasks.md does not exist: Ask the user to provide or create a task list before entering the loop.
Step Completion Reports
After completing each major step, output a status report in this format:
◆ [Step Name] ([step N of M] — [context])
··································································
[Check 1]: √ pass
[Check 2]: √ pass (note if relevant)
[Check 3]: × fail — [reason]
[Check 4]: √ pass
[Criteria]: √ N/M met
____________________________
Result: PASS | FAIL | PARTIAL
Adapt the check names to match what the step actually validates. Use √ for pass, × for fail, and — to add brief context. The "Criteria" line summarizes how many acceptance criteria were met. The "Result" line gives the overall verdict.
Selection (step 1 of 4)
◆ Selection (step 1 of 4 — task scoping)
··································································
Task identified: √ pass — task-2-3-pin-crud selected
Scope bounded: √ pass — 1-3 dev days, atomic unit
Dependencies clear: √ pass — no blockers in tasks.md
[Criteria]: √ 3/3 met
____________________________
Result: PASS
Planning (step 2 of 4)
◆ Planning (step 2 of 4 — spec scaffolding)
··································································
Spec artifacts created: √ pass — proposal.md, design.md, tasks.md, spec.md
Implementation planned: √ pass — approach and tradeoffs documented
[Criteria]: √ 2/2 met
____________________________
Result: PASS
Implementation (step 3 of 4)
◆ Implementation (step 3 of 4 — code delivery)
··································································
Code written: √ pass — all checkboxes updated
Tests pass: × fail — 1 unit test failing
Scope respected: √ pass — no unrelated files changed
[Criteria]: √ 2/3 met
____________________________
Result: PARTIAL
Archive (step 4 of 4)
◆ Archive (step 4 of 4 — completion and sync)
··································································
Artifacts synced: √ pass — specs merged into openspec/specs/
Quality gate passed: √ pass — all 6 criteria met
[Criteria]: √ 2/2 met
____________________________
Result: PASS
Resources
references/openspec-task-templates.md— proposal/spec/design/tasks templates for manual mode.scripts/new_task_change.sh— optional scaffold script for manual mode.
More from luongnv89/skills
ollama-optimizer
Optimize Ollama configuration for the current machine's hardware. Use when asked to speed up Ollama, tune local LLM performance, or pick models that fit available GPU/RAM.
126logo-designer
Generate professional SVG logos from project context, producing 7 brand variants (mark, full, wordmark, icon, favicon, white, black) plus a showcase HTML page. Skip for raster-only logos, product illustrations, or full brand-guideline docs.
122code-optimizer
Analyze code for performance bottlenecks, memory leaks, and algorithmic inefficiencies. Use when asked to optimize, find bottlenecks, or improve efficiency. Don't use for bug-hunting code review, security audits, or refactoring without a perf goal.
76code-review
Review code changes for bugs, security vulnerabilities, and code quality issues — producing prioritized findings with specific fix suggestions. Don't use for performance tuning, writing new features from scratch, or generating test cases.
75idea-validator
Evaluate app ideas and startup concepts across market viability, technical feasibility, and competitive landscape. Use when asked to validate, review, or score a product idea. Don't use for writing a PRD, detailed go-to-market plans, or financial/investor pitch decks.
70test-coverage
Generate unit tests for untested branches and edge cases. Use when coverage is low, CI flags gaps, or a release needs hardening. Not for integration/E2E suites, framework migrations, or fixing production bugs.
63