Nova implement plan
Skill lliangcol/llm-plugins-fusion/nova-plugin/skills/nova-implement-plan
AI engineering workflow framework for coding assistants, delivered through nova-plugin.
npx -y skills add lliangcol/llm-plugins-fusion --skill nova-implement-planAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Implement the resolved execution profile. The default approved-plan profile requires PLAN_INPUT_PATH and PLAN_APPROVED=true.
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
9.9 KB, as published. Nobody here has run it
Shared Execution Policy
This file is the supporting behavioral contract for /nova-plugin:implement-plan and the deprecated /nova-plugin:nova-implement-plan compatibility entrypoint. Prefer the direct command; the compatibility name remains only for the current major-version migration window.
- Resolve natural-language and explicit
KEY=valueinputs using../_shared/parameter-resolution.md; explicit non-conflicting values take precedence. - Apply
../_shared/safety-preflight.mdbefore side effects. Never infer approval, destructive scope, credentials, or output destinations. - Follow
../_shared/output-contracts.mdand../_shared/artifact-policy.md; report completed, skipped, and blocked validation truthfully. - Respect the frontmatter tool boundary. Missing inputs, unavailable dependencies, overlapping user changes, or repository-policy conflicts are blockers rather than permission to broaden scope.
Execution
- Parse
$ARGUMENTSagainst the workflow-specific inputs below. - Read only the context required for the requested scope.
- Apply the workflow contract and its strict output format.
- Stop before unauthorized side effects; otherwise validate in proportion to risk and report residual risk.
Workflow Contract
<!-- BEGIN GENERATED BEHAVIOR CONTRACT -->Generated from
workflow-specs/behaviors.v2.json. This block is authoritative. Runnode scripts/generate-behavior-surfaces.mjs --writeafter changing the IR; if explanatory text below conflicts, fail closed.
Generated Behavior Index
- Purpose: Execute an explicitly approved plan step by step with traceability and minimal deviation.
- Canonical inputs:
PLAN_INPUT_PATH(required aliases=PLAN_PATH);PLAN_APPROVED(required aliases=APPROVED exact=true,"true");EXECUTION_PROFILE(optional exact="lite","standard","codex-review-fix") - Resolved variant authority:
{"EXECUTION_PROFILE":"codex-review-fix"} normalized={"EXECUTION_PROFILE":"codex-review-fix"} -> runtime/contracts/codex-review-fix.json;{"EXECUTION_PROFILE":"lite"} normalized={"EXECUTION_PROFILE":"lite"} -> runtime/contracts/implement-lite.json;{} normalized={} -> runtime/contracts/implement-plan.json;{"EXECUTION_PROFILE":"standard"} normalized={"EXECUTION_PROFILE":"standard"} -> runtime/contracts/implement-standard.json. Declared selector defaults are applied before matching. An exact normalized override wins; a non-exact combination that triggers an alias specialization stops as conflicting, and only a valid combination that triggers no specialization uses the canonical fallback. The complete resolved runtime contract is authoritative and no field falls back to canonical prose. - Claude static-entrypoint gate: Native command and Skill frontmatter are static. A matching command wrapper may continue after it has verified that its invoked command id equals
resolvedWorkflowId; this canonical Skill must not re-resolve or reject that validated wrapper. Only when this canonical Skill is itself the Claude native invoked entrypoint and no validated wrapper gate exists mustresolvedWorkflowIdequalimplement-plan. Otherwise STOP before tools or side effects and invoke the exact direct command/nova-plugin:<resolved commandEntrypoint.directCommandId>; never execute the specialized contract under unmatched canonical frontmatter. Generic and Codex adapters may execute the resolved contract directly under adapter enforcement. - Decision entries: 2.
- Workflow steps:
validate-approval→load-plan→execute→verify→trace - Output: mode=
workspace-and-chat; order=implemented changes→plan-step trace→validation→deviations; severity=none. - Deviation/failure: mode=
approval-required; failure order=status→completed plan steps→blocked plan step→blocker→safe next action. - Full IR:
runtime/contracts/implement-plan.json#behaviorContractembeds the complete decision table, invariants, stops, field definitions, validation, and failure contract from the same source. Detailed guidance below may not override it.
Purpose
Execute approved plan steps with minimal deviation and clear traceability.
Inputs
Resolve EXECUTION_PROFILE first, then use only the required-input set from
the matched runtime contract:
| Resolved profile | Selector | Required inputs |
|---|---|---|
| Approved-plan default | {} | PLAN_INPUT_PATH, PLAN_APPROVED |
| Lightweight implementation | {"EXECUTION_PROFILE":"lite"} | REQUEST |
| Standard implementation | {"EXECUTION_PROFILE":"standard"} | REQUEST |
| Codex review/fix loop | {"EXECUTION_PROFILE":"codex-review-fix"} | REVIEW_SCOPE |
PLAN_INPUT_PATH and PLAN_APPROVED=true apply only to the default {}
approved-plan contract. They are not requirements of the three specialized
profiles.
Outputs
- Code changes aligned to approved plan.
- Implementation summary + deviation notes.
Workflow
- Validate both required parameters and
EXECUTION_PROFILEwhen supplied. - Read plan as source of truth.
- Implement step-by-step within scope.
- Run plan-required verification.
Examples
- Natural trigger:
Use implement-plan with the approved plan in docs/plans/login.md. - Explicit trigger:
implement-plan PLAN_INPUT_PATH=docs/plans/login.md PLAN_APPROVED=true.
Safety
- Medium-risk write operations.
- Stop on non-trivial deviation; request plan update.
Detailed Contract
The approved-plan procedure below applies only to the default {} profile.
Specialized profiles follow their resolved runtime contract and required-input
set above.
CONTROLLED EXECUTION
You are Claude Code acting as a disciplined software engineer.
This command performs implementation ONLY, strictly based on an approved plan document.
No exploration. No redesign. No scope expansion.
TASK MODE
IMPLEMENT CODE STRICTLY BASED ON AN APPROVED PLAN
- The plan is the decision authority
- This step is execution-focused
- Deviations are exceptional and must be justified
REQUIRED INPUT EXTRACTION
From $ARGUMENTS, extract:
1. Plan Input Path (Required)
PLAN_INPUT_PATH: <PLAN_INPUT_PATH>
If PLAN_INPUT_PATH is missing:
- STOP immediately
- Ask the user to explicitly provide it
2. Plan Approval Flag (Required)
PLAN_APPROVED: <PLAN_APPROVED>
Rules:
- Must be present
- Must be exactly:
true(case-sensitive)
If PLAN_APPROVED is missing or not exactly true:
- STOP immediately
- State clearly that implementation is blocked
- Explain that
PLAN_APPROVED=trueis required to proceed
EXECUTION RULES (STRICT)
You MUST:
- Read the plan file at
PLAN_INPUT_PATHbefore any implementation - Treat the plan as the single source of truth
- Implement changes step by step, following the plan structure
- Respect all goals, non-goals, constraints, and assumptions in the plan
You MUST NOT:
- Redesign the solution
- Introduce new features or scope
- Optimize beyond what the plan specifies
- Resolve unplanned issues by inventing solutions
DEVIATION POLICY (EXCEPTION-BASED)
Deviation is allowed ONLY if:
- A clear correctness, feasibility, or safety issue is discovered
- The issue prevents faithful implementation of the plan
If a deviation occurs, you MUST:
- Explicitly explain the blocking issue
- Describe the exact deviation from the plan
- Indicate whether:
- The plan should be updated and re-approved
- Or the deviation is a minor corrective adjustment
If deviation is non-trivial:
- Prefer stopping execution
- Request plan revision instead of silently proceeding
IMPLEMENTATION GUIDELINES
While implementing, you MUST:
- Follow existing project conventions and style
- Preserve backward compatibility unless the plan explicitly allows breaking changes
- Consider:
- Concurrency and thread-safety
- Idempotency
- Failure modes and error handling
- Add, update, or adjust tests only as specified in the plan
You MUST NOT:
- Add “nice-to-have” improvements
- Refactor unrelated code
- Change behavior not covered by the plan
TRACEABILITY REQUIREMENTS
Implementation should maintain clear traceability:
- Each significant change should map to a specific step or section in the plan
- If helpful, reference plan section numbers in commit messages or comments
OUTPUT RULES
Provide the following in chat output:
-
Implemented code changes
- Clearly organized
- Only changes required by the plan
-
A short implementation summary
- What was implemented
- Confirmation that the plan was followed
-
Explicit deviation notes (if any)
- Or state clearly: “No deviations from the approved plan”
Do NOT:
- Restate the plan
- Re-justify design decisions
- Introduce new analysis or recommendations
4.0 VARIANT PROFILES
- Default: execute an explicitly approved plan.
EXECUTION_PROFILE=lite|standardreplacesimplement-liteandimplement-standard.EXECUTION_PROFILE=codex-review-fixruns the retained review/fix/verify closure assets underskills/nova-codex-review-fix/; it requires explicit shell, network, credentials, and write approval and may not broaden repository scope.
Compatibility presets never satisfy PLAN_APPROVED or other approval inputs.