Menu
Execute exactly one explicitly requested and developer-approved step from an OttoNet HTML implementation plan in a .NET repository. Use only after plan approval and never advance to future steps automatically.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Coordinate OttoNet's gated .NET company-task workflow from workspace inspection through final delivery review while preserving developer control over clarification, plan approval, each implementation step, commits, and push.
Perform a full evidence-based final delivery review for a completed .NET company task after all approved steps are reviewed. Use before the developer manually pushes; this skill never pushes code.
Create a detailed, developer-approved, stepwise HTML implementation plan for a resolved .NET company task. Use only after requirement-gap analysis confirms that no blocking clarification remains.
Extract repository rules, architecture guidance, and operational instructions before reading a BA task or exploring .NET business implementation. Use after workspace inspection in an OttoNet company-task workflow.
Map the active .NET base code, its actual module responsibilities, and request execution flows after project documentation is understood. Use before analyzing a BA task to build evidence-based project understanding without assuming an architecture.
Compare a BA task with .NET repository rules, code, and team patterns to resolve technical conventions, expose business ambiguity, and create clarification questions before planning. Use after task-context investigation.
| name | dotnet-step-executor |
| description | Execute exactly one explicitly requested and developer-approved step from an OttoNet HTML implementation plan in a .NET repository. Use only after plan approval and never advance to future steps automatically. |
Implement one approved plan step within its stated scope, validate it, and report the resulting diff without committing or advancing the plan.
Use only when the developer explicitly requests a numbered step from an approved HTML plan, for example: “Read the implementation plan and execute Step 3 only.”
dotnet-workspace-inspector behavior first. Record current branch, local changes, staged files, conflicts, and protection boundaries.AWAITING_STEP_REQUEST state, requested step, protected paths, and latest continuity event with the current workspace. Stop on a mismatch that could make the step unsafe. Read the requested step from the HTML plan, including goal, files, actions, references, dependencies, risks, validation, and expected result. Confirm the plan was approved.AWAITING_REVIEW or BLOCKED), cited evidence IDs, and new evidence paths; the orchestrator records it. Leave commit and HTML-plan-status updates to explicit developer instruction.Use this order for any interpretation: 1) resolved task requirements, 2) original task requirements, 3) repository instructions and documentation, 4) approved merge requests, 5) resolved review comments, 6) recent merged code, 7) repeated current project patterns, 8) similar implementations, 9) generic .NET practices. Generic practices never override explicit task or project rules.
Stop before editing if plan approval or the requested step is unclear, dependencies are incomplete, a blocking requirement remains, expected files conflict with uncommitted work, or repository instructions prohibit the change. Stop after the requested step is complete; wait for review and developer commit decision.
Produce a Step Execution Report containing the requested step, workspace status, files inspected and changed, requirements covered, validation commands actually executed and results, diff summary, deviations, blockers, and a recommendation to proceed to review. Do not label it ready for commit until the reviewer completes.
Pass the execution report, plan step, changed-file diff, and supporting requirements to dotnet-step-reviewer.