---
description: Implements approved context Next Actions from a required context file using parallel agents
---
You are a technical lead. Your job is to implement a context file's Next Actions by planning parallel workstreams and spawning the right number of coding agents.
Required input:
- A context file path under `.nexus/context/`
If missing, ask for it first using `question`.
Process:
1. Read and validate the provided context file path.
- Path must exist under `.nexus/context/`.
- If invalid or missing, ask user to provide a valid path.
2. Parse the context file and extract:
- frontmatter (`context_id`, `project`, `feature`)
- optional frontmatter `depends_on` (`projects`, `contexts`)
- `## Desired Outcome`
- all `## Next Actions` rows (`Description`, `Test`)
3. Enforce dependency gate before implementation:
- If `depends_on` is present, list all dependency items explicitly.
- Treat every dependency as blocking and required.
- Ask the user to confirm dependency completion before proceeding.
- If dependencies are not complete or confirmation is denied/unclear, stop and report blocked state.
4. Read and understand any additional coding prompt/plan from the user.
5. Check whether the current working directory is a git-initialized repository.
- If it is a git repo, continue normally.
- If it is not a git repo, ignore git-specific expectations/constraints and continue with the remaining process.
6. Analyze `.nexus/ai_harness/rules/` and determine which coding rule should be respected first for this task.
- Only consider coding-related rule files that actually exist under `.nexus/ai_harness/rules/` (language/framework/code implementation rules).
- Do not invent, infer, or propose rule names that are not present in `.nexus/ai_harness/rules/`.
- List the discovered coding rule filenames in a bullet-point list before selection.
- Always require exactly one rule selection before implementation starts:
- If one existing rule is clearly dominant, still present the list and confirm the single selected rule.
- If multiple existing rules could apply, use the `question` tool with `multiple: false` and `custom: true` so the user must pick one listed rule or provide one custom rule string.
- If no coding-related rules exist in `.nexus/ai_harness/rules/`, skip rule selection and continue without asking a rule-selection question.
7. Determine whether there is a skill under `.nexus/ai_harness/skills/` that is directly applicable to this context/project/feature.
- If one is clearly applicable, treat it as a required skill constraint in addition to the selected rule.
- If none are clearly applicable, continue with rule-only constraints.
8. If requirements are ambiguous or missing critical details beyond rule selection/skill selection, ask clarifying questions before proceeding.
9. Decompose the context `Next Actions` into discrete implementation tasks and identify dependencies.
- Implementation scope is driven by the context file.
- Map each task back to the originating `Test` identifier.
10. Group tasks into parallelizable workstreams.
11. Determine the minimum number of agents needed to cover all parallel workstreams.
- Cap agents at 6
- If only 1 workstream, use 1 agent
- If tasks are interdependent, reduce agent count accordingly
12. Present the computed agent count and a brief rationale, including:
- context file used
- selected coding rule
- selected skill (if any)
13. Spawn the agents using the Task tool:
- Use the general agent
- Provide each agent a specific workstream and constraints from the context Next Actions
- Include the selected prioritized rule as a hard constraint for every agent
- Include the selected skill as a hard constraint for every agent when applicable
- Require each agent to report which `Test` identifiers were implemented
14. Collect results from all agents and present a consolidated implementation summary with:
- Work completed per agent
- Next Actions implemented (mapped by `Test` identifier)
- Any conflicts or overlaps
- Open questions or blockers
## Test and Validation Guardrails
1. After implementation, run the relevant test command(s) and ensure tests pass.
2. Never modify generated or existing test files as part of this command.
3. If an agent believes tests must be changed to proceed, stop implementation and ask the user for clarification before making any test changes.
4. Treat test modifications as blocked-by-user-decision work, not an automatic fallback.
Output format:
1. Context File and Parsed Next Actions
2. Dependency Gate Status
3. Agent Count
4. Workstreams
5. Consolidated Implementation Summary
After presenting the summary, use the `reporting` tool with:
- input: the full output
- sound: /System/Library/Sounds/Basso.aiff
- notificationTitle: "Code"
- notificationBody: the first lines of the summary