HackIndia Logo
HackathonsNewsSkillsGrowth
HackIndia LogoContact: +91 9910125804

General

  • Companies
  • Colleges
  • Board of Advisors
  • Brand Ambassadors
  • FAQ
  • Contact
  • Report a Bug

Hackathons

  • Upcoming Hackathons
  • Judges
  • Mentors
  • Partners
  • Participating Colleges
  • Testimonials

Resources

  • About Us
  • Branding
  • Latest News
  • Growth
  • Skills
  • Builders
  • Ecosystem
  • Forum
  • Ideas
  • Prompt Optimizer
  • Games

© 2026 HackIndia. All rights reserved.

Privacy PolicyTerms of ServiceCode of ConductSitemap

Build 2.139 · 05 Nov 2026, 10:27 UTC

    HackIndia
    HackathonsNewsInternshipsSkillsGrowthPro Perks
    ← Ship faster with Claude Code

    All the reading

    Claude Code

    7 lessons, about 37 minutes. The check's questions come from these.

    Contents
    Installing and starting safely
    1. 1. Install and start safely
    2. 2. Give Claude project context
    Setting context and permissions
    1. 3. Set permissions before coding
    2. 4. Plan multi-file changes first
    Prompting, reviewing, and submitting
    1. 5. Implement with tight prompts
    2. 6. Review before you submit
    3. 7. Submit your project repo

    Installing and starting safely

    1. Install and start safely

    5 min

    In 30 seconds
    • Install or open Claude Code without unsafe shortcuts.
    • Start it from your repo root, not a random folder.
    • Know what Claude can see before you approve commands.
    Key point

    One safe habit

    Start Claude Code only from the repo you plan to ship, and know what it can access before you approve anything.

    Claude can read files under that folder, see git state, use CLAUDE.md, load memory, and ask to run terminal commands.

    Your to-do

    Check Node first

    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.

    0 of 4 done

    node --version
    npm --version
    Your to-do

    Install or open

    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.

    0 of 4 done

    npm install -g @anthropic-ai/claude-code
    claude --version
    
    # Later, when you need to upgrade an npm install:
    npm install -g @anthropic-ai/claude-code@latest
    Common mistake

    2. Give Claude project context

    5 min

    In 30 seconds
    • Create a short CLAUDE.md that tells Claude how your repo works.
    • Use /init, then edit the file by hand so commands and rules are real.
    • Commit project context so your HackIndia repo is Claude Code-ready.
    Key point

    One idea

    CLAUDE.md is the project briefing Claude Code reads every session. Put stable repo facts there: goal, commands, folders, conventions, and workflows.

    What Claude sees

    Run Claude Code from your project root. When run in a directory, it can access files in that directory and subdirectories, and files elsewhere only with permission.

    It can also see git state: current branch, uncommitted changes, and recent commit history. This is why project root matters more than a random folder like src/components.

    Where context lives

    Use ./CLAUDE.md for hackathon repos because teammates and judges can find it easily. ./.claude/CLAUDE.md also works.

    MEMORY.md is different. Claude writes auto memory, and only the first 200 lines or 25KB are loaded at session start. Put must-follow rules in CLAUDE.md, not MEMORY.md.

    Your to-do

    Setting context and permissions

    3. Set permissions before coding

    4 min

    In 30 seconds
    • Pick the right Claude Code permission mode before coding.
    • Deny Claude access to .env files in shared project settings.
    • Verify settings with /status and claude doctor before you continue.
    Key point

    One guardrail

    Claude Code can read your project, see git state, and use your terminal with your user permissions. Set permissions before you ask it to code.

    Your hackathon repo should show this clearly. Commit shared settings that protect secrets, then verify Claude loaded them.

    Pick a mode

    Use Manual for real repo work. It asks before edits or commands and shows diffs for approval.

    Use Accept edits only for small, low-risk changes. It auto-accepts file edits and common filesystem commands like mkdir, touch, and mv, but still asks before other terminal commands.

    Tip

    Prompting, reviewing, and submitting

    5. Implement with tight prompts

    6 min

    In 30 seconds
    • Write prompts that keep Claude Code inside one small task.
    • Name files, constraints, expected behavior, and checks before edits.
    • Approve only scoped diffs, then test and commit the change.
    Key point

    One idea

    A tight prompt says what to change, where to change it, what not to touch, and how you will check it.

    Claude Code can see your current branch, uncommitted changes, recent commits, CLAUDE.md, and files in the project directory. Reduce guesswork before you approve edits.

    Your to-do

    Start clean

    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.

    0 of 5 done

    git status
    claude

    Prompt shape

    10 questions, 7 to pass.

    Sign in to take the test

    Avoid unsafe shortcuts

    Do not run sudo npm install -g for Claude Code. Anthropic warns it can cause permission issues and security risks.

    Do not use bypass permissions as your normal mode. It skips permission prompts and should be used only in disposable sandboxed containers or VMs.

    Your to-do

    Start at root

    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.

    0 of 4 done

    cd ~/code/hackindia-upi-splitter
    pwd
    git status --short
    claude

    What Claude sees

    When Claude Code runs in a directory, it can access files in that directory and subdirectories. Files elsewhere may be accessed only with permission.

    It can see your current branch, uncommitted changes, and recent commit history. It can also use your terminal, read CLAUDE.md, load auto memory, and use configured extensions.

    Tip

    Keep context simple

    CLAUDE.md is the project context file Claude Code reads. It is written by you. Auto memory is written by Claude and stores learnings per repo.

    At session start, auto memory loads the first 200 lines or 25KB of MEMORY.md, whichever comes first. Do not put secrets in memory files. Claude Code reads CLAUDE.md, not AGENTS.md, unless CLAUDE.md imports it with @AGENTS.md.

    Example

    First safe start

    You are building a public HackIndia repo for a UPI expense splitter. Before asking for code changes, add a tiny CLAUDE.md and keep .env private.

    A later lesson will improve project context. For now, this makes the first session less vague.

    cd ~/code/hackindia-upi-splitter
    pwd
    # /Users/you/code/hackindia-upi-splitter
    
    git status --short
    # ?? .env
    # ?? CLAUDE.md
    
    cat > CLAUDE.md <<'EOF'
    Project: HackIndia UPI Splitter
    
    Use this repo as the source of truth.
    Do not read or print secrets from .env files.
    Before suggesting commands, explain what they will do.
    Do not make code changes until I ask for them.
    EOF
    
    git add CLAUDE.md
    git commit -m "Add initial Claude Code project context"
    
    claude
    Your to-do

    Do this now

    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.

    0 of 5 done

    Start with init

    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.

    0 of 5 done

    cd ~/projects/hackindia-campus-pay
    claude
    
    # Inside Claude Code
    /init
    Example

    Useful CLAUDE.md

    Keep it short and specific. Do not write a product pitch. Write what helps Claude make correct edits.

    # CLAUDE.md
    
    ## Project goal
    Campus Pay Split is a HackIndia hackathon project for college students in India.
    The demo flow is: create a group, add members, add a shared expense in rupees, and show who should pay whom.
    Prioritise a working demo over extra features.
    
    ## Stack
    - Next.js app using the app directory.
    - TypeScript for application code.
    - Prisma for database models and queries.
    - UI components live in `components/`.
    - Shared helpers live in `lib/`.
    
    ## Commands
    - Install dependencies: `npm install`
    - Start local dev server: `npm run dev`
    - Build for submission: `npm run build`
    - Lint: `npm run lint`
    - There is no test script yet. Do not claim tests passed unless a test command is added.
    
    ## Code conventions
    - Use TypeScript types for props and data returned from helpers.
    - Keep React components small and readable.
    - Put expense calculation logic in `lib/settlement.ts`, not inside page components.
    - Use rupees for displayed amounts. Format as `₹500`, not `$500`.
    - Prefer clear variable names like `payerId`, `splitAmount`, and `settlements`.
    
    ## Git workflow
    - Check git status before changing files.
    - Keep changes focused on the requested task.
    - Do not edit generated files unless the task requires it.
    
    ## Environment
    - Environment variables are expected in `.env.local`.
    - Never read, print, or commit real secrets.
    - Use placeholder names when documentation needs to mention env vars.
    Common mistake

    Common mistakes

    Do not fill CLAUDE.md with generic lines like “write clean code”. Use repo rules, such as where settlement logic belongs or which command proves the app builds.

    Do not put secrets in CLAUDE.md or MEMORY.md. Use placeholder names like RAZORPAY_KEY_ID or DATABASE_URL, not real API keys, database passwords, UPI credentials, or production tokens.

    Tip

    If AGENTS.md exists

    Claude Code reads CLAUDE.md, not AGENTS.md. If your repo already has AGENTS.md for another agent, import it instead of copying the same text into two files.

    # CLAUDE.md
    
    @AGENTS.md
    
    ## Claude-specific notes
    - Use the commands in package.json.
    - Ask before making broad architecture changes.
    - Keep hackathon demo flow working: create group, add expense, view settlement.
    Your to-do

    Do this now

    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.

    0 of 5 done

    git status
    git diff -- CLAUDE.md
    git add CLAUDE.md
    git commit -m "add Claude project context"

    Use Plan first

    Plan mode lets Claude read files and propose a plan without editing source files until you approve.

    Use it for multi-file changes, unfamiliar code, auth, database work, payment flows, deployment config, or anything that can break your demo.

    claude --permission-mode plan
    
    # Or toggle during a session with Shift+Tab
    # until the status bar shows plan mode on.

    Settings files

    Shared project settings are committed at .claude/settings.json. Use this for team rules, like blocking .env reads.

    Your user settings live at ~/.claude/settings.json. Personal settings for one repo live at .claude/settings.local.json. Keep personal overrides out of commits.

    Deny wins

    Settings precedence is managed settings, command-line arguments, project-local settings, shared project settings, then user settings.

    Deny rules are stronger than allow rules. If a tool is denied at any level, no other setting can allow it back.

    Example

    Block env reads

    Example: your campus food app has a frontend, backend, and local .env with database URLs or test keys. Claude does not need real secrets to build features.

    Add shared settings from the repo root. This protects root .env and files like .env.local, .env.production, and .env.test.

    pwd
    # /Users/you/hackindia-campus-food
    
    mkdir -p .claude
    cat > .claude/settings.json <<'EOF'
    {
      "permissions": {
        "deny": [
          "Read(./.env)",
          "Read(./.env.*)"
        ]
      }
    }
    EOF
    
    git diff -- .claude/settings.json
    
    git add .claude/settings.json
    git commit -m "Add Claude Code safety settings"
    Common mistake

    Avoid broad trust

    Do not run Claude Code from your home folder or Downloads. Run it from the repo root so the workspace stays narrow.

    Do not treat Bypass permissions as a speed boost. It skips permission prompts and should be used only in sandboxed containers or VMs.

    Your to-do

    Do this now

    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.

    0 of 5 done

    # From the repo root
    claude
    
    # Inside Claude Code
    /status
    
    # In your terminal, if settings look wrong
    claude doctor

    4. Plan multi-file changes first

    5 min

    In 30 seconds
    • Use Plan mode before Claude edits a multi-file feature.
    • Ask for a file-based plan with constraints and a manual check.
    • Tighten the plan, then approve only work you understand.
    Key point

    The main idea

    For uncertain or multi-file work, use this order: explore, plan, implement, commit.

    Plan mode lets Claude read files and propose a plan without editing source files until you approve. Your job is to make the future diff predictable.

    Start at root

    Open Claude Code from your project root. Claude can access files in that directory and subdirectories. It can also see git state, including your current branch, uncommitted changes, and recent commits.

    Check your repo first. If you have lab work or teammate changes sitting uncommitted, know that before you ask Claude to plan.

    git status
    claude --permission-mode plan
    Tip

    Toggle if needed

    You can also enter Plan mode during a session. Press Shift+Tab until the status bar shows Plan mode on.

    Use this before a feature touches a route, component, helper, test, or README. It is slower than guessing, but faster than cleaning up random edits.

    Example

    Planning prompt

    A weak prompt says, “Add bookings.” A better prompt names the outcome, files to inspect, constraints, and says not to edit yet.

    This example keeps the canteen app small: one menu item, one pending order, no backend.

    Prompt to Claude in Plan mode:
    
    We are adding a simple canteen pre-order flow.
    Do not edit files yet.
    First inspect these files:
    - package.json
    - src/App.jsx
    - src/pages/Menu.jsx
    - src/lib/orders.js
    - src/lib/menu.js
    
    Then propose a plan for the smallest working change that lets a student select one menu item and create a pending order.
    Constraints:
    - Keep existing component style.
    - No backend yet.
    - Store orders in localStorage through src/lib/orders.js.
    - Include any test or manual check I should run.
    Reference the exact files you plan to change.
    Example

    Tighten the plan

    In Plan mode, use Ctrl+G to open the plan in a text editor. Cut vague steps. Add boundaries Claude must not cross.

    A good plan names exact files, explains the small change, and includes a check you can run before committing.

    Before plan:
    1. Add order management.
    2. Update the menu UI.
    3. Improve styling.
    4. Add storage and tests if needed.
    
    After editing with Ctrl+G:
    1. In src/lib/orders.js, implement getOrders() and createOrder(item) using localStorage key "canteen_orders".
    2. In src/pages/Menu.jsx, add a button beside each item that calls createOrder(item).
    3. In src/pages/Menu.jsx, show "Order saved" after a successful click.
    4. Do not add new dependencies.
    5. Do not change routing, package.json, or src/lib/menu.js.
    6. Manual check: run the app, click Order on Poha, refresh, and confirm getOrders() still returns the saved order.
    Common mistake

    Do not approve fog

    Do not approve a plan that says “improve UI” or “add order management” without file names. Ask Claude to revise it.

    For the canteen example, you expect changes in src/lib/orders.js and src/pages/Menu.jsx. If Claude later wants to change package.json, routing, or unrelated CSS, stop and ask why.

    Example

    Expected shape

    The final code can differ, but the shape should match the plan: a localStorage helper and a small UI action.

    You will review the actual diff in a later lesson. For now, make the plan clear enough that review is easy.

    // src/lib/orders.js
    const STORAGE_KEY = "canteen_orders";
    
    export function getOrders() {
      const saved = localStorage.getItem(STORAGE_KEY);
      return saved ? JSON.parse(saved) : [];
    }
    
    export function createOrder(item) {
      const order = {
        id: crypto.randomUUID(),
        itemId: item.id,
        itemName: item.name,
        price: item.price,
        status: "pending",
        createdAt: new Date().toISOString()
      };
    
      const orders = [...getOrders(), order];
      localStorage.setItem(STORAGE_KEY, JSON.stringify(orders));
      return order;
    }
    Your to-do

    Do this now

    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.

    0 of 5 done

    Use five parts: goal, allowed files, constraints, expected behavior, and check command.

    Do not ask Claude to “improve checkout”. Ask for one behavior you can review in a diff.

    Example

    Tight prompt

    This example is for a Vite React cart page in a campus snack ordering demo. The same shape works for your own app.

    Implement one small change only.
    
    Goal: On the cart page, show a free-delivery message when the cart total is ₹499 or more.
    
    You may edit only:
    - src/components/CartSummary.jsx
    - src/components/CartSummary.test.jsx
    
    Do not edit package.json, routing, CSS framework config, or payment code.
    
    Follow the existing component style. Keep the rupee formatting already used in this file.
    
    Expected behavior:
    - If total is 499 or above, show: Free delivery unlocked
    - If total is below 499, show: Add ₹X more for free delivery
    - X should be 499 - total
    
    Add or update tests for totals 498 and 499.
    
    Before editing, restate the files you will change and the test command you expect me to run.
    Tip

    Use safer modes

    Use Manual mode when you are still learning. It asks before edits or commands and shows diffs for approval.

    Accept edits can be faster for simple file edits, but it still asks before other terminal commands. Do not use bypass permissions as a normal shortcut; use it only in a sandboxed container or VM.

    Example

    Good small diff

    Before approving, check that Claude stayed inside the two allowed files. If it edits package.json or refactors the cart flow, stop and restate the scope.

    // src/components/CartSummary.jsx
    export default function CartSummary({ total }) {
      const freeDeliveryMinimum = 499;
      const amountNeeded = freeDeliveryMinimum - total;
      const deliveryMessage =
        total >= freeDeliveryMinimum
          ? "Free delivery unlocked"
          : `Add ₹${amountNeeded} more for free delivery`;
    
      return (
        <section aria-label="Cart summary">
          <p>Total: ₹{total}</p>
          <p>{deliveryMessage}</p>
          <button>Continue to pay</button>
        </section>
      );
    }
    
    // src/components/CartSummary.test.jsx
    import { render, screen } from "@testing-library/react";
    import CartSummary from "./CartSummary";
    
    test("shows the cart total", () => {
      render(<CartSummary total={250} />);
      expect(screen.getByText("Total: ₹250")).toBeInTheDocument();
    });
    
    test("shows amount needed when total is below free delivery minimum", () => {
      render(<CartSummary total={498} />);
      expect(screen.getByText("Add ₹1 more for free delivery")).toBeInTheDocument();
    });
    
    test("shows free delivery message when total reaches minimum", () => {
      render(<CartSummary total={499} />);
      expect(screen.getByText("Free delivery unlocked")).toBeInTheDocument();
    });
    Common mistake

    Common traps

    “Add checkout” is too broad. Break it into one visible behavior, one route, or one validation rule.

    Do not approve secret reads, .env access, unexpected installs, or broad rewrites during a small task. You are responsible for what enters your public repo.

    Your to-do

    Do this now

    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.

    0 of 5 done

    npm test
    
    git diff -- src/components/CartSummary.jsx src/components/CartSummary.test.jsx
    
    git status
    
    git add src/components/CartSummary.jsx src/components/CartSummary.test.jsx
    git commit -m "Add free delivery message to cart summary"}],
    Your to-do

    Start clean

    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.

    0 of 5 done

    git status
    claude

    Prompt shape

    Use five parts: goal, allowed files, constraints, expected behavior, and check command.

    Do not ask Claude to “improve checkout”. Ask for one behavior you can review in a diff.

    Example

    Tight prompt

    This example is for a Vite React cart page in a campus snack ordering demo. The same shape works for your own app.

    Implement one small change only.
    
    Goal: On the cart page, show a free-delivery message when the cart total is ₹499 or more.
    
    You may edit only:
    - src/components/CartSummary.jsx
    - src/components/CartSummary.test.jsx
    
    Do not edit package.json, routing, CSS framework config, or payment code.
    
    Follow the existing component style. Keep the rupee formatting already used in this file.
    
    Expected behavior:
    - If total is 499 or above, show: Free delivery unlocked
    - If total is below 499, show: Add ₹X more for free delivery
    - X should be 499 - total
    
    Add or update tests for totals 498 and 499.
    
    Before editing, restate the files you will change and the test command you expect me to run.
    Tip

    Use safer modes

    Use Manual mode when you are still learning. It asks before edits or commands and shows diffs for approval.

    Accept edits can be faster for simple file edits, but it still asks before other terminal commands. Do not use bypass permissions as a normal shortcut; use it only in a sandboxed container or VM.

    6. Review before you submit

    6 min

    In 30 seconds
    • Inspect your git diff before you ask Claude to review it.
    • Run test, lint, and build checks from your CLAUDE.md.
    • Commit only the files you mean to submit.
    Key point

    Review is your job

    Claude Code can help you ship faster, but you still own the HackIndia repo you submit.

    Before submission, prove three things: project context exists, safe settings exist, and code changes were reviewed before commit or pull request.

    Your to-do

    Start with git

    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.

    0 of 4 done

    git status
    git branch --show-current
    git diff --stat
    git diff
    Example

    Safe project context

    This example is a college fest UPI expense splitter. The context tells Claude how to check the project and how money should be handled.

    The shared settings deny environment file reads. Permission rules are deny-first, so another allow rule cannot override this deny.

    File: CLAUDE.md
    Project: FestSplit
    
    Commands:
    - npm test
    - npm run lint
    - npm run build
    
    Conventions:
    - Use TypeScript for all app logic.
    - Keep money amounts in paise internally.
    - Display rupees only at the UI boundary.
    - Do not read or modify .env files.
    
    Architecture:
    - src/lib contains pure calculation helpers.
    - src/components contains React UI components.
    - Tests live next to the file as *.test.ts.
    
    File: .claude/settings.json
    {
      "permissions": {
        "deny": [
          "Read(./.env)",
          "Read(./.env.*)"
        ]
      }
    }
    Example

    Review the change

    The old code used rupees and floating point numbers. The new code keeps paise internally and handles remainders.

    Test names should explain the behaviour. This helps your teammate trust the repo during the last hackathon hour.

    Before: src/lib/split.ts
    export function splitAmount(totalRupees: number, people: number): number[] {
      const share = totalRupees / people;
      return Array.from({ length: people }, () => share);
    }
    
    After: src/lib/split.ts
    export function splitAmountPaise(totalPaise: number, people: number): number[] {
      if (!Number.isInteger(totalPaise) || totalPaise < 0) {
        throw new Error("totalPaise must be a non-negative integer");
      }
    
      if (!Number.isInteger(people) || people <= 0) {
        throw new Error("people must be a positive integer");
      }
    
      const baseShare = Math.floor(totalPaise / people);
      const remainder = totalPaise % people;
    
      return Array.from({ length: people }, (_, index) => {
        return index < remainder ? baseShare + 1 : baseShare;
      });
    }
    
    After: src/lib/split.test.ts
    import { describe, expect, it } from "vitest";
    import { splitAmountPaise } from "./split";
    
    describe("splitAmountPaise", () => {
      it("splits an amount evenly", () => {
        expect(splitAmountPaise(9000, 3)).toEqual([3000, 3000, 3000]);
      });
    
      it("distributes remaining paise without losing money", () => {
        expect(splitAmountPaise(10000, 3)).toEqual([3334, 3333, 3333]);
      });
    
      it("rejects invalid people count", () => {
        expect(() => splitAmountPaise(10000, 0)).toThrow("people");
      });
    });
    
    Commands:
    git diff -- src/lib/split.ts src/lib/split.test.ts
    Your to-do

    Run checks

    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.

    0 of 4 done

    npm test
    npm run lint
    npm run build
    
    Focused prompt to Claude Code:
    The command npm test fails after the splitAmountPaise change.
    Only inspect src/lib/split.ts and src/lib/split.test.ts.
    Keep money in paise internally.
    Explain the cause first, then propose the smallest fix.
    Tip

    Ask for review

    After your own pass, run local diff review. The Code Review docs point to the /code-review command for this.

    Use Manual/default for review. It asks before edits or commands and shows diffs for approval. Bypass permissions is only for sandboxed containers or VMs.

    Inside Claude Code:
    /code-review
    
    Follow-up prompt:
    Review the current uncommitted diff for:
    1. logic errors
    2. edge cases in money splitting
    3. mismatch with CLAUDE.md conventions
    4. accidental secret or environment file exposure
    5. changes that are not needed for this feature
    
    Do not edit files yet. Give findings with file names and line-level suggestions where possible.
    Common mistake

    Do not commit junk

    Avoid git add . unless you have checked git status carefully. Do not commit .env, .env.local, API keys, database dumps, generated build folders, or personal notes.

    Claude’s review is not approval. Read the diff again before accepting changes or committing.

    Safer staging:
    git add CLAUDE.md .claude/settings.json src/lib/split.ts src/lib/split.test.ts
    git status
    git diff --staged
    git commit -m "Add paise-based expense splitting"
    Your to-do

    Do this now

    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.

    0 of 5 done

    7. Submit your project repo

    6 min

    In 30 seconds
    • Package your repo so judges and teammates can run and trust it.
    • Add Claude Code context, safe shared settings, and reviewed commits.
    • Submit a public GitHub repo link that opens outside your account.
    Key point

    The proof

    Your HackIndia proof is a public GitHub repo. It should show three things: Claude Code-ready context, safe shared settings, and reviewed code changes through commits or a pull request.

    Do not add a big feature now. Package the work you already built.

    Your to-do

    Final repo checks

    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.

    0 of 6 done

    git status
    git diff
    git log --oneline -5

    What Claude sees

    When Claude Code runs in your repo, it can access files in that directory and subdirectories. It can also see git state, including your current branch, uncommitted changes, and recent commit history.

    That is useful, but it means your final repo should be clean before you submit. Keep .env, API keys, local database dumps, debug logs, and .claude/settings.local.json out of git.

    Example

    Public context example

    Use CLAUDE.md as the operating guide for future Claude Code sessions. Keep it real. Do not list fake commands just to look complete.

    For example, a college fest UPI expense splitter could use this:

    # Claude Code project context
    
    Project: UPI Expense Splitter for college fest teams.
    
    Stack:
    - Client: React in client/
    - Server: Node and Express in server/
    - Data: local JSON storage for hackathon demo
    
    Commands:
    - Install root dependencies: npm install
    - Start dev server: npm run dev
    - Run client build: npm run build
    - Run tests if present: npm test
    
    Conventions:
    - Keep UI text simple for Indian college users.
    - Amounts are stored in rupees as numbers.
    - Do not add paid services or external APIs unless asked.
    - Do not read or modify .env files.
    - For multi-file changes, propose a plan first.
    
    Review checklist:
    - Run npm run build before final commit.
    - Check git diff before committing.
    - Mention any untested area in the commit or PR notes.
    Example

    Safe shared settings

    Shared project settings belong in .claude/settings.json. Personal overrides belong in .claude/settings.local.json and should stay out of git.

    For a public hackathon repo, deny reads of environment files. Claude Code permission rules are deny-first, so a deny rule cannot be allowed back by another settings level.

    mkdir -p .claude
    cat > .claude/settings.json <<'EOF'
    {
      "permissions": {
        "deny": [
          "Read(./.env)",
          "Read(./.env.*)"
        ]
      }
    }
    EOF
    
    cat > .gitignore <<'EOF'
    .env
    .env.*
    node_modules/
    dist/
    build/
    .claude/settings.local.json
    EOF
    
    git status
    Your to-do

    Review and push

    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.

    0 of 5 done

    git diff -- CLAUDE.md .claude/settings.json .gitignore
    npm run build
    
    # In Claude Code, run local review:
    /code-review
    
    # Then commit:
    git add CLAUDE.md .claude/settings.json .gitignore server/routes/expenses.js client/src/pages/GroupSummary.jsx
    git commit -m "Add reviewed CSV export for expense summaries"
    git status
    
    git remote -v
    git push origin main
    Common mistake

    Avoid these mistakes

    Do not submit a private repo. Open the GitHub link in an incognito window or ask a teammate to check it before you paste it into HackIndia.

    Do not assume Claude Code reads AGENTS.md directly. It reads CLAUDE.md. If you already have AGENTS.md, import it from CLAUDE.md.

    # Optional if you already have AGENTS.md
    cat > CLAUDE.md <<'EOF'
    @AGENTS.md
    
    Additional Claude Code rules:
    - Do not read .env or .env.* files.
    - Propose a plan before multi-file changes.
    - Run the listed build or test command before final commits.
    EOF
    Tip

    PR review option

    If you use a GitHub pull request, Claude Code Code Review can post findings as inline comments. A top-level @claude review comment can trigger review where it is configured.

    These findings do not approve or block the PR. You still own the final review.

    Your to-do

    Do this now

    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.

    0 of 5 done