Knowledge index

Free disk space is not the same as available memory for running applications.

Report which screen you reached, the exact message, and what changed beforehand.

Give AI your operating system when asking for instructions, and distinguish a file from a running process.

Seeing a change and saving a change are two separate things to check.

Record when the issue occurs, what it affects, and which actions change it.

Start with concrete inputs and expected results.

Define the goal and environment before selecting an implementation language.

Trace code with a concrete input instead of guessing its behavior.

Ask how the data is organized before asking for a line-by-line syntax lesson.

For a startup problem, report the system, project directory, command, and full error.

Writing code is only part of the job. Running it, inspecting changes, and checking behavior matter too.

Networked programs need waiting and failure behavior as well as a successful path.

First distinguish your local network from other networks; protocol details can come later.

Keep the full address and startup output, including the port, when reporting connection problems.

Connected to Wi-Fi means one part of the connection is working.

When asking whether a service is reachable, say from which device and network.

Provide the full URL instead of saying only “that website.”

Ask what was requested, what came back, and how the interface handled it.

Report evidence and leave the cause open to investigation.

Check both “I can open it” and “the intended user can use it.”

Choose services from the actual requirements of your first version.

When asking to save data, specify where, for how long, and who can access it.

Sketch the fields and relationships before choosing a storage solution with AI.

Distinguish filtering, updating, and deleting in your requirements.

Explain what data exists, how it relates, and how you usually query it before choosing a database.

Measure performance rather than adding technology in response to a vague feeling of slowness.

Identify the single-machine limitation before introducing a distributed design.

Consider both parallelizable work and coordination overhead.

For repeated queries, consider preparation and caching before adding machines.

Define the question before deciding which events to collect.

Spend complexity on a problem you have actually established.

Evaluate models on real tasks and unseen examples.

Think of a neural network as a trainable computational structure, not a tiny human brain.

Understand tokens as processing units; use the relevant tokenizer for exact counts.

Separate generated claims from actions that tools actually performed.

Provide key constraints explicitly and verify important results independently.

Find out what the assistant can actually see and do.

Use your own task to evaluate a model.

More computation doesn't replace missing information or acceptance conditions.

A handoff should explain the present state and next action, not repeat the entire past.

Professionalism comes from precise information and checkable results, not jargon.

Describe the workflow and output criteria before choosing tools.

Find the source of the data before automating the interface.

The access method affects reliability and maintenance.

Treat extracted content as data that still needs validation.

Check the result of an automated action, not just that the action happened.

Describe successful, failed, and repeated execution in a professional automation brief.