AI Coding Tools - lesson 2 | HackIndia Skills

Key point

One idea

Do not make every AI chat start from zero. Put your project rules inside the repo so the assistant sees the same context when it helps you code or review.

Good instructions say what the app does, how to run checks, what patterns to follow, and what risks to watch.

Why this matters

AI coding assistants use more than your typed prompt. For example, Copilot Chat can use the current file and chat history, and supported instruction files can be added automatically to requests.

That means your repo can guide the assistant before you ask anything. This is useful in a hackathon team where one person works on React, another on API routes, and another on database code.

Your to-do

Pick instruction files

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Use .github/copilot-instructions.md for repo-wide Copilot coding standards and review criteria.
Use AGENTS.md in the repo root for architecture, risky areas, testing, and intentional design choices.
Use .github/instructions/**/*.instructions.md for path-specific rules, such as backend or payment files.
Use CLAUDE.md if your team uses Claude Code for shared project instructions.
Avoid relying on one file for every tool; support differs across products and editors.

0 of 5 done

Example

Repo-wide example

Start with a small file. You can improve it later. The goal is not to impress the AI. The goal is to reduce wrong assumptions.

File: .github/copilot-instructions.md

Project context:
This is a hackathon project for college students to split group expenses and settle using UPI outside the app.

Coding rules:
- Use TypeScript for new app code.
- Keep functions small and named by intent.
- Do not add new dependencies unless the README explains why.
- Do not hardcode API keys, tokens, phone numbers, or UPI IDs.

Review rules:
- Check for input validation in API handlers.
- Check for hardcoded secrets or test credentials.
- Check that generated code matches installed packages.
- If a change affects settlement logic, ask for or add a small test case.

Verification:
- Run the existing test command before saying work is complete.
- If tests are missing, write manual verification notes in the pull request or README.

Example

Path-specific example

Use path rules when one part of the repo needs extra care. Auth, payments, database migrations, and admin panels are common examples.

File: .github/instructions/backend.instructions.md

Apply to: backend/**

Backend rules:
- Validate request body fields before using them.
- Return safe error messages. Do not expose stack traces to users.
- Keep database writes inside clear service functions.
- For settlement or money-like amounts, use integer paise, not floating point rupees.
- Add a test or manual verification note for every API behavior change.

Common mistake

Beginners write vague rules like “write clean code” or “make it secure”. The assistant cannot apply that well during review.

Write rules you can check. For example: “Do not hardcode secrets” is checkable. “Use integer paise for amounts” is checkable.

Tip

Use AI to draft

Ask your AI tool to draft instructions after it reads your actual repo files. Then edit the result. Do not accept rules for tools, scripts, or folders that do not exist.

A useful prompt is: “Read the README, package files, and main source folders. Draft concise repo instructions for coding and review. Do not speculate about files you have not opened.”