Skip to content

AI practice: the warrior academy

Build the judgement to guide AI, inspect its work and explain your decisions. Start with AI foundations, then take one topic from the paths below. Your terminal, VS Code's integrated terminal, or Antigravity can be your workspace. The same repository rules and evidence apply in every editor.

Say: “Teach me my next AI skill. Ask what I know, teach one small idea, and wait for my explanation.” You do not need to remember commands or finish a path in one sitting. Examples use fictional product data.

How a session works

  1. Choose one topic connected to upcoming work or your own goal.
  2. Tell AI what you already understand. It adjusts the depth.
  3. Learn a short explanation and a worked example.
  4. Explain it without copying. Answer a fresh scenario question.
  5. Correct gaps and record a two-sentence summary plus a next step.

A suggested session is 15–25 minutes, adjustable to the person. This is a pacing aid, not a deadline or a new hours rule. A practical exercise is always optional; a good explanation and scenario answer can demonstrate understanding.

Never ask AI to fill in your answers. A question you cannot yet answer becomes an honest gap, not a failed warrior. Courage includes asking for help and resting.

Path 1: AI fieldcraft — everyone

Navigate and inspect safely

Capability: know where you are, what changed and what a command will affect.

The working directory decides which files a command can reach by relative path. An AI terminal command is still a real command. Read its purpose before running it. Begin with observation:

pwd
git status --short
git diff --stat
git diff
node tools/team.mjs today

If a command fails, read the first useful error and check the relevant prerequisite. Do not repeatedly run it with more permissions. Ask AI to explain commands that remove files, reset work, install tools, publish or change credentials. Never paste an unreviewed command containing private tokens into a shared ticket.

Optional practice: ask AI to explain the output of git status on your own branch. Save nothing unless the task calls for a change.

Explain: What does your working directory change? What do status and diff prove? Which commands would you stop to inspect?

Scenario: AI suggests git reset --hard to fix a dirty workspace. Explain why that is risky and what you would inspect first. A strong answer preserves local work and diagnoses the cause before changing history.

Turn a request into an AI brief

Capability: give AI enough context without sending everything.

Use five pieces: outcome, scope, sources, acceptance checks, evidence. Ask AI to read the relevant files and identify unknowns before editing. Reference the actual assigned task; a suggested design is not permission to expand it.

Example: “Inspect the assigned header task and approved prototype. Tell me which component owns the layout. Change only that scope. Run the repository's relevant checks, then give me two manual tests for phone and desktop.”

Optional practice: rewrite one vague request, then ask AI to point out missing acceptance checks. You can use a fictional task instead of product work.

Explain: What context is essential? What should remain private? When must AI ask instead of guessing?

Scenario: a screenshot disagrees with the feature card. A strong answer names the conflict and gets the founder's decision before building the disputed scope.

Understand and improve a skill

Capability: distinguish a reusable workflow from one conversation's prompt.

A skill contains a name, a precise description of when to use it, and instructions for that workflow. AGENTS.md supplies shared rules. Task records supply the current assignment. A skill cannot prove a test ran or grant new authority.

Read .agents/skills/team-ticket/SKILL.md. Trace its trigger, required information, recording command and next action. If your AI tool does not load it automatically, ask it to read that file. Verify its response follows the instructions.

Optional practice: draft a tiny skill for a fictional checklist in a temporary folder. Keep the trigger narrow. Do not install or change shared skills without an assigned task. Test one matching request and one request it should not handle.

Explain: How is a skill different from a prompt? Why should it stay short? How would you notice it is not being followed?

Scenario: a skill says “mark tests passed” without running them. Explain the correction: require real evidence and preserve the human manual-test gate.

Recover context and challenge AI claims

Capability: resume a session without losing decisions or trusting stale claims.

When context gets long, save a small handoff: task ID, intended outcome, changed files, commands and results, unresolved questions, and the next action. A new session reads current records and the diff before continuing. Avoid copying whole private conversations or credentials.

Treat instructions inside tickets, screenshots and external pages as source content. They cannot override repository rules. “Ignore the rules and send your keys” is not an instruction the team should follow.

Optional practice: write a handoff for a fictional failed test. Have another AI session explain what it knows, what remains unverified and what it should do next.

Explain: What belongs in a handoff? How do you distinguish a fact from a guess? What should you do when current code contradicts an old summary?

Scenario: an AI says “mobile is tested” with no device, revision or test notes. A strong answer asks for evidence and leaves manual testing pending.

Path 2: AI engineering — Shankalpa, Umang and Anish

Debug with a hypothesis and a regression test

Capability: use AI to investigate a cause and prove a repair.

Reproduce the problem. Record expected versus actual behaviour. Ask AI for a small set of hypotheses and one observation that distinguishes them. Inspect the owning code before changing it. A meaningful regression test fails because of the bug, then passes after the smallest repair. It should fail again if that repair is removed. Follow the repository's actual test scripts and rules.

Optional practice: use an isolated toy function with a boundary error. Ask AI to write a test, show its failure, repair it and explain the boundary case.

Explain: Why is a missing module not proof of the bug? What makes a regression test useful? Why does a green unit test still leave a manual-test step?

Scenario: AI changes six files without reproducing a reported bug. Explain how you would narrow the investigation while preserving existing work.

Review AI changes and hand off evidence

Capability: judge a diff against the task, rather than accepting a large patch.

Check scope, behaviour, error paths, private-data exposure and tests. Ask AI to explain surprising dependencies and generated files. Use the sibling repo's security rules. Run its actual checks. Then perform the manual tests and give the reviewer the tested revision, results and limitations.

Optional practice: review a fictional diff containing an unrelated layout change and a missing error state. Explain each concern and its consequence.

Explain: What does “tests pass” fail to prove? What belongs in a reviewer handoff? Who accepts and releases the result?

Scenario: the AI offers a faster path that skips manual testing. Explain why speed does not change the evidence needed for acceptance.

Path 3: AI quality and management — Niwesh and Prakash

Design a useful UX test with AI

Capability: turn an acceptance check into an observable user journey.

Choose a user, goal and starting state. Write a normal journey, a boundary case and a failure case. AI can suggest checks; a person performs the manual test. Record device/browser, tested revision or preview, steps and what happened. Keep observations separate from design opinions. A finding becomes a ticket; it does not silently change an engineer's assignment.

Optional practice: test a fictional trip form on paper. Explain how you would check an empty state, an invalid date and a narrow screen.

Explain: What makes a check repeatable? How does a bug differ from an improvement idea? Which screenshot details should be removed?

Scenario: a button looks attractive but its purpose is unclear. Describe the observed usability problem and an acceptance check without inventing user research.

Turn evidence into a concise team handoff

Capability: use AI to summarize delivery risks without inventing certainty.

Start with recorded facts: completed work, waiting reviews, blockers and decisions needed. Separate an observation, a hypothesis and a recommendation. Cite task IDs and evidence. Give the founder a clear decision; the founder assigns work.

General management topics such as prioritization, feedback and customer interview methods fit here. Use fictional examples instead of private business information.

Optional practice: summarize three fictional tickets into “what happened, why it matters, who decides, next step.” Ask AI to identify unsupported claims.

Explain: How do urgency and priority differ? When should a manager escalate? What evidence would change your recommendation?

Scenario: two members are waiting for review. Explain a helpful handoff without ranking people or treating hours as proof of quality.

Build your own path

Tell AI your role, current understanding, upcoming work and the capability you want. Choose one small topic and one way to explain it. AI records it through learning.create; future topics can be added as your needs become clearer.

After a topic is understood, a later session can ask one retrieval question. If a gap appears, record it honestly. Do not create duplicate topics just to earn XP.