marketplace/bundles/plan-marshall/skills/task-implementation/SKILL.md
Domain-agnostic implementation task execution with two-tier skill loading
npx skillsauth add cuioss/plan-marshall task-implementationInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Role: Domain-agnostic workflow skill for executing implementation tasks (profile=implementation). Loaded by plan-marshall:phase-5-execute skill when task.profile is implementation.
Key Pattern: Agent loads this skill via resolve-workflow-skill --domain {domain} --phase implementation. Skill executes a generic workflow: understand context → plan → implement → verify. Domain-specific knowledge comes from task.skills (loaded by agent).
MANDATORY: Follow the execution contract defined in:
| Contract | Location | Purpose |
|----------|----------|---------|
| Task Contract | plan-marshall:manage-tasks/standards/task-contract.md | Task structure and fields |
| Task Format | plan-marshall:manage-tasks/standards/task-format.md | TOON file format specification |
See ref-workflow-architecture:skill-loading for the complete two-tier skill loading pattern with visual diagrams.
Summary: Agent loads Tier 1 (system skills) automatically, then Tier 2 (domain skills from task.skills). This workflow skill defines HOW the agent executes.
| Parameter | Type | Required | Description |
|-----------|------|----------|-------------|
| plan_id | string | Yes | Plan identifier |
| task_number | number | Yes | Task number to execute |
status: success | error
plan_id: {echo}
task_number: {echo}
execution_summary:
steps_completed: N
steps_total: M
files_modified: [paths]
verification:
passed: true | false
command: "{cmd}"
next_action: task_complete | requires_attention
message: {error message if status=error}
Read the task file to understand what needs to be done:
python3 .plan/execute-script.py plan-marshall:manage-tasks:manage-tasks get \
--plan-id {plan_id} \
--number {task_number}
Extract key fields:
domain: Domain for this taskprofile: Should be implementationskills: Domain skills to apply (already loaded by agent)description: What to implementsteps: File paths to work onverification: How to verify successdepends_on: Dependencies (should be complete)Read the compatibility approach from marshal.json project configuration:
python3 .plan/execute-script.py plan-marshall:manage-config:manage-config \
plan phase-2-refine get --field compatibility --trace-plan-id {plan_id}
No fallback — if field not found, fail with error and abort task. This ensures project is configured correctly.
Extract compatibility from the output. Apply throughout all subsequent steps:
@Deprecated markers. Add new code alongside old. Provide migration notes in commit messages.Before implementing, understand the codebase context:
Read affected files (from steps):
# For each step (file path)
Read {step.target} # If file exists
Read related files:
# Find related components
Grep "{component_name}" --type {language}
Glob {pattern}
Read {related_file}
Apply domain knowledge:
For each step (file path), determine:
Note: Steps are executed sequentially. No explicit "in_progress" marker needed - proceed directly to implementation.
For each step (file path):
Create new file:
Write {file_path}
# Apply patterns from domain skills
# Follow project conventions
Modify existing file:
Edit {file_path}
# Apply changes following domain skill patterns
# Maintain existing code style
Apply domain patterns:
After each step:
python3 .plan/execute-script.py plan-marshall:manage-tasks:manage-tasks finalize-step \
--plan-id {plan_id} \
--task {task_number} \
--step {N} \
--outcome done
After all steps complete, run task verification:
# Execute verification commands from task
{verification.commands[0]}
{verification.commands[1]}
...
Verification (implementation tasks verify compilability only — full test execution belongs to module_testing profile):
Execute the verification commands from task.verification.commands. Every task SHOULD have commands populated by the plan phase (copied from the deliverable).
Safety net (should never trigger in normal operation): If verification commands are missing, log a WARN and resolve from architecture:
python3 .plan/execute-script.py plan-marshall:manage-logging:manage-log \
work --plan-id {plan_id} --level WARN --message "[VERIFY] (plan-marshall:task-implementation) TASK-{N} missing verification — falling back to architecture resolve"
python3 .plan/execute-script.py plan-marshall:manage-architecture:architecture \
resolve --command compile --name {module} \
--trace-plan-id {plan_id}
If verification passes:
python3 .plan/execute-script.py plan-marshall:manage-tasks:manage-tasks update \
--plan-id {plan_id} \
--number {task_number} \
--status done
If verification fails:
If still failing after 3 iterations:
python3 .plan/execute-script.py plan-marshall:manage-tasks:manage-tasks update \
--plan-id {plan_id} \
--number {task_number} \
--status blocked
Note: Record details in work.log using manage-log.
On issues or unexpected patterns:
python3 .plan/execute-script.py plan-marshall:manage-lessons:manage-lesson add \
--component "plan-marshall:task-implementation" \
--category improvement \
--title "{issue summary}" \
--detail "{context and resolution}"
Valid categories: bug, improvement, anti-pattern
status: success
plan_id: {plan_id}
task_number: {task_number}
execution_summary:
steps_completed: {N}
steps_total: {M}
files_modified:
- {path1}
- {path2}
verification:
passed: true
command: "{verification command}"
next_action: task_complete
1. Determine target path from step
2. Check if parent directory exists
3. Create file with proper structure
4. Apply domain patterns:
- Package/module declaration
- Imports/dependencies
- Class/function structure
- Documentation
5. Format according to project style
1. Read existing file
2. Identify modification points
3. Apply changes using Edit tool
4. Preserve existing style
5. Update related components if needed
6. Update documentation if needed
1. Run verification command
2. If pass → complete
3. If fail → analyze output
4. Identify failing assertion/error
5. Fix specific issue
6. Re-run verification
7. Repeat (max 3 times)
8. If still failing → block task
If a file depends on code not yet implemented:
If verification command hangs:
If changes conflict with existing code:
Invoked by: plan-marshall:phase-5-execute skill (when task.profile = implementation)
Skill Loading: Agent loads this skill via resolve-task-executor --profile implementation
Script Notations (use EXACTLY as shown):
plan-marshall:manage-tasks:manage-tasks - Task operations (get, update, finalize-step)plan-marshall:manage-config:manage-config - Read compatibility from project configplan-marshall:manage-lessons:manage-lesson - Record lessons (add)Domain Skills Applied (loaded by agent from task.skills):
pm-dev-java:java-core, pm-dev-java:java-cdi, etc.pm-dev-frontend:javascript, etc.development
Domain-owned OpenRewrite log-line finding parser for the java-cui domain — parses the
development
Domain-owned OpenRewrite marker detection for the java-cui domain — scans Java/Kotlin sources for cui-rewrite TODO markers, categorizes them by recipe, and fails the gate on any detected marker
development
Operator control surface for the marshalld build server — enrol/drop a project in the machine-global registry (the opt-in enable signal and anti-laundering wall), manage the daemon lifecycle (start, stop, drain, status, install, upgrade) version-pinned to the verified bundle copy, and inspect the daemon's per-project interaction-audit log (read-only)
tools
The tiny build-consumption client for the marshalld build server — submit a build job, bounded long-poll for its result, ping the daemon identity, and preflight registry-plus-liveness in one call; consumption only, never provisioning or enrolment