Disciplined engineering

Disciplined Engineering

Own the outcome from intent through verification. Use the smallest process that provides enough clarity and evidence. Keep one root agent accountable for scope, integration, and delivery.

1. Frame the work

1. Read repository instructions, current Git state, relevant domain docs, and nearby implementation before proposing work.
2. Classify the request: explain, diagnose, change, review, or deliver. Do not turn diagnosis or review into an implementation without authorization.
3. Establish what outcome is required, what evidence would support it, and which delivery actions are allowed.
4. Handle clear, bounded work directly. Add planning or clarification only when it changes the result.

For ambiguous features, multi-step changes, or large efforts, read planning-and-design.md.

2. Decide proportionally

• Discover facts from the codebase, tools, and primary sources. Ask the user only for decisions or unavailable facts.
• Reuse the repository's language, architecture, testing seams, and established workflow.
• Compare alternatives when a decision is consequential or hard to reverse.
• Keep scope changes explicit when new evidence changes the work.

3. Delegate only when useful

The root agent owns dispatch, integration, and final verification. Delegate only when the work:

• is independent and does not overlap shared mutable state;
• has a bounded deliverable and an objective way to check it;
• benefits materially from parallel execution or an independent perspective;
• can be reconciled by the root agent.

Give each child a concrete goal, allowed scope, shared-state constraints, expected artifact, and verification. Do not delegate delegation decisions, final integration, branch completion, or the whole task. Prevent recursive delegation unless the user explicitly requests a hierarchy. Treat child reports as inputs, not proof.

4. Execute through tight feedback loops

• Prefer small vertical slices and fast observable feedback for behavior changes.
• Reproduce the reported symptom before fixing a bug when a trustworthy reproduction is feasible.
• Run narrow checks during the work and preserve unrelated user changes.

Read testing-and-debugging.md when changing behavior or diagnosing a failure.

5. Review and finish

Review the result on separate axes:

• Spec: required behavior, omissions, incorrect behavior, and scope creep.
• Standards: repository rules, maintainability, architecture, tests, and security implications.

Read review-and-delivery.md before responding to review feedback, claiming completion, or changing branch/remote state.

Treat this skill as the owner of the general engineering process. Do not invoke another general-purpose engineering workflow for stages already covered here. Use specialized tool, platform, artifact, or security skills only when they add a capability this workflow does not provide, then return control here.