matt-code-review

Before using this method, read the knowledge and team rules: project knowledge comes from team-knowledge (tw brief).

Two-axis review of the final workspace against the fixed base in the accepted task:

• Standards: does the code conform to this repo's documented coding standards?
• Spec: does the code faithfully implement the originating issue / spec?

Review both axes separately. Use independent subagents when authorized and useful; otherwise keep distinct evidence and conclusions in the current agent.

Use the accepted user goal and the project's existing requirements; a separate task platform is optional.

For a team task, follow the team delivery rules. Record the actual reviewer without imposing a rank or requiring a different person. Simple tasks combine final plan and code approval with the actual code and run references; risks still determine checks. Existing approvals remain valid only for unchanged sections and dependencies. Business acceptance precedes the knowledge update, which ships in the same change; delivery then checks the knowledge disposition.

Process

1. Pin the fixed point

Use the task's full base commit or the user-supplied base. Resolve it before reviewing; ask only if no base can be established from the accepted task.