Tmd

TMD: Think, Modify, Document

先想，再改，记得留档。

TMD is a progressive Unity MCP development skill. Do not load every reference at once. Read only the files required by the current task and development stage.

Mandatory lifecycle

Every project-changing task follows:

Think
  ↓
Modify
  ↓
Document

Think

Before significant modification:

1. Understand the user's requirement.
2. Read existing project context and relevant implementation.
3. Check the Git working state when available.
4. Identify affected code, Scenes, Prefabs, assets, packages, and data.
5. Prepare an implementation plan.
6. Obtain user confirmation before implementation when required by this skill.

Modify

After approval:

• Prefer Unity MCP edits to actual Scene/GameObject/Component data over permanent construction scripts.
• Prefer Inspector-configurable references and values.
• Prefer Prefabs for reusable objects.
• Prefer ScriptableObject for configurable data.
• Prefer native Unity editor workflows over code that merely replaces editor functionality.
• Preserve existing project conventions unless the user approves a change.
• Keep changes scoped to the approved feature.

Document

After modification:

• Run the relevant test flow.
• Check Console state when possible.
• Report changed files, assets, Scenes, and Prefabs.
• Report impact and known limitations.
• Remove temporary Debug content that should not ship or be committed.
• Propose a focused Commit Message.
• Update project development documentation.

Highest principle

The goal is not merely to make a feature work.

Build the project with a formal, maintainable structure using the minimum amount of code required. Get a real, runnable, testable project skeleton working first. Once the skeleton exists, later features should extend that foundation naturally instead of being designed speculatively in advance.

Formal structure. Minimum code. Build the working skeleton first.

This means:

• establish clear responsibilities, ownership, and module boundaries from the beginning;
• implement only the code needed for the current working skeleton;
• make the first version runnable and testable as early as possible;
• avoid speculative abstractions, systems, edge-case frameworks, and infrastructure before a real need exists;
• grow later features from the verified skeleton instead of designing the whole future project up front.

The result must remain as easy as reasonably possible for the user to inspect, configure, modify, and extend through Unity.

When both approaches satisfy the requirement:

• A: hide configuration inside more code.
• B: expose configuration through Unity's normal editor/configuration workflow.

Prefer B, unless automation has a clear practical benefit or the user explicitly asks otherwise.

TMD efficient senior mode

TMD is intentionally lazy in the senior-engineer sense: efficient, not careless.

The best code is code that does not need to exist.

The simplification ladder runs after the problem is understood, never instead of understanding it. Before choosing an implementation:

1. Read the task fully.
2. Inspect the code, Scene, Prefab, asset, or data it actually touches.
3. Trace the real flow end to end when behavior is non-trivial.
4. Then stop at the first rung that solves the problem correctly:

1. Does this need to be built at all?                 → YAGNI
2. Does the project already have this?               → Reuse it
3. Does C#/.NET/Unity already provide it?            → Use the standard/native feature
4. Does an already-installed dependency solve it?    → Reuse it
5. Can the requirement be expressed directly?        → Prefer the simplest direct form
6. Only then write new code                           → Minimum code that works

For Unity, native/editor capabilities are earlier rungs than new runtime code: Inspector, Prefab, ScriptableObject, Animator Controller, Timeline, Input System, Editor APIs, and direct MCP edits.

The shortest working diff wins only after the correct change location is understood. A tiny patch in the wrong layer is not simplicity; it is deferred breakage.

No speculative construction

Unless explicitly required:

• do not create abstractions;
• do not add dependencies;
• do not generate boilerplate;
• do not split work across extra files merely for ceremony;
• prefer deletion over addition;
• prefer boring, explicit solutions over clever ones;
• keep the diff and number of touched files as small as the real problem allows.

Deliberate simplification marker

If a deliberate simplification has a real, known ceiling, mark it with a concise TMD: comment that states the ceiling and upgrade path.

// TMD: O(n²) is acceptable below ~100 entries; switch to an indexed lookup if this grows.

Do not add TMD: comments for ordinary clean code. Use them only for intentional tradeoffs.

No ceremonial safety

Do not add code or process merely because it looks "safer."

By default:

• no guard clause without a concrete invalid state that can actually reach this boundary;
• no fallback path without a real recoverable failure mode and a defined correct fallback;
• no rollback mechanism for small, reversible edits;
• no extra validation deep inside trusted internal flows when the invariant is already established upstream;
• no test file, test Scene, fixture, mock layer, or self-check that does not protect meaningful behavior.

Prefer fixing the invariant or ownership point instead of surrounding the symptom with safety code.

Safety work must answer a concrete question:

What real failure does this prevent?

If the answer is hypothetical, omit it.

TMD is never lazy about

Do not simplify away:

• understanding the real problem;
• input validation at actual trust boundaries;
• error handling required to prevent data loss, corrupted state, or unrecoverable user-facing failure;
• security;
• accessibility;
• real-device/hardware calibration;
• anything the user explicitly requested;
• verification that has real regression value for non-trivial logic.

Verification should be proportional to risk and complexity. Trivial configuration changes and obvious one-line edits do not need ceremonial tests.

Progressive routing

Always read

For every TMD task:

• Core principles
• Forbidden patterns

Before project modification

Read:

• Planning

Also read when relevant:

• Git workflow
• Collaboration

First project entry or unknown project

Read:

• Project initialization
• Project context
• Third-party dependencies

Architecture, systems, refactors, public APIs

Read only when architecture is actually involved:

• Code style
• Module design
• Data architecture

For an MVP, avoid loading or applying architecture complexity that the task does not need.

Scene, Hierarchy, GameObject, Component, Transform

Read:

• Scene

If reusable objects or Prefab instances are involved, also read:

• Prefab

Assets, Materials, Textures, ScriptableObject assets

Read:

• Asset management

Unity editor tooling

Read when creating EditorWindow, Custom Inspector, validators, or batch tools:

• Editor tools

UI

Read:

• UI

Input

Read:

• Input

Animation

Read:

• Animation

Testing, debugging, bug fixing

Feature verification:

• Testing

Debugging:

• Debugging

Bug fixing:

• Bug fix

Performance and loading

Only load when the task or measured problem requires it:

• Performance
• Loading

Release

Read:

• Release

Completion documentation

After project modification, read:

• Documentation

Risk model

Low-risk details may be decided autonomously when they follow established project conventions.

High-risk changes require explicit user approval, including:

• architecture changes;
• MainScene modification;
• core data-model changes;
• third-party source modification;
• major refactors;
• Unity or package upgrades;
• replacement of a major technology or workflow;
• broad destructive changes.

If a major test failure appears, stop broad modifications, explain the failure, ask whether rollback is desired when appropriate, and re-plan from the observed problem.

Rule precedence

Apply rules in this order:

1. The user's explicit current requirement.
2. TMD core maintainability and change-control rules.
3. Existing project conventions recorded in project context.
4. Task-specific TMD reference.
5. General recommendations.

Do not silently replace an established project convention.

Completion gate

Before declaring a project-changing task complete:

Think

• Requirement understood.
• Relevant references loaded.
• Existing implementation inspected.
• Impact analyzed.
• Required implementation plan approved.

Modify

• Only approved scope changed.
• Editor/MCP configuration preferred over unnecessary code.
• Existing project conventions respected.
• Temporary construction/edit scripts removed unless intentionally retained as Editor tools.

Document

• Tests completed, or limitations clearly stated.
• Console checked where possible.
• Impact summarized.
• Debug artifacts handled.
• Commit suggestion prepared when relevant.
• Project documentation updated.