From spec-plugin
Execute a single task end-to-end — either a new story or a fix from validation findings. Reads the task context and architecture, then produces working output that meets all acceptance criteria. Adapts to project type: writes code for code projects, writes deliverables for non-code projects.
npx claudepluginhub nexaedge/nexaedge-marketplace --plugin spec-pluginThis skill uses the workspace's default tool permissions.
Your task: execute ONE task end-to-end, producing output that meets all acceptance criteria. The task is either a new story (from `/build-stories`) or a fix (from `/validate-execution` findings).
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Migrates code, prompts, and API calls from Claude Sonnet 4.0/4.5 or Opus 4.1 to Opus 4.5, updating model strings on Anthropic, AWS, GCP, Azure platforms.
Automates semantic versioning and release workflow for Claude Code plugins: bumps versions in package.json, marketplace.json, plugin.json; verifies builds; creates git tags, GitHub releases, changelogs.
Your task: execute ONE task end-to-end, producing output that meets all acceptance criteria. The task is either a new story (from /build-stories) or a fix (from /validate-execution findings).
specs/v0.1-core-push/001-... → v0.1-core-push)specs/ in CWD.specs/<version>/architecture.mdspecs/architecture.mdspecs/ and check the Project Context section to understand the project type and code repository path## Execution Log section — if so, resume from where it left offThe spec's Project Context → Type determines your execution approach:
The orchestrator will include validation findings in the prompt — specific failures that need to be addressed. Read the referenced validation spec to understand what failed and why.
If the task lists a prior /interface-design story as a prerequisite, read that story's execution log to find the files it produced. Build on them, don't redesign them.
Before producing any output:
New stories:
Fix tasks:
Integrating Interface-Design Output:
.interface-design/system.md for design tokens and patternsNew stories:
Fix tasks:
New stories:
Write automated tests alongside the implementation. The goal is pragmatic coverage — not 100% unit testing, but confidence that key behaviors work.
After writing tests, run them and ensure they all pass. Tests MUST pass before moving to Phase 5.
For non-code projects, verification is criteria-based:
Append an ## Execution Log section to the task file:
## Execution Log
### Session: <date>
**Status**: completed | in-progress
**Completed:**
- What was done (with file paths)
**Decisions Made:**
- Any implementation decisions not in the original task
**Issues Encountered:**
- Problems hit and how they were resolved
**Struggled With:**
- Things that took multiple attempts
- Process difficulty that future agents should know about
**Pending:** (only if in-progress)
- What's left to do
Then update specs/<version>/stories.md — mark the task as completed ONLY if ALL acceptance criteria pass. Otherwise mark as in-progress. After updating, re-read stories.md to verify the change was saved.
After completing a code task, ensure validation can happen without guessing:
docs/dev-environment.md with exact commands**QA Setup**specs/<version>/architecture.md