portfolio

Imported from RIZKI-KUDENG/portfolio (AGENTS.md). Install upstream with npx skills add RIZKI-KUDENG/portfolio. Copyright stays with the author.

AGENTS.md

Instructions and guidelines for AI coding agents working on this repository.

1. Role of This File

This file defines how AI coding agents should work in this repository.

It covers:

• repository architecture
• coding conventions
• implementation constraints
• modification rules
• verification requirements
• design implementation workflow

Visual design decisions are defined separately in DESIGN.md.

Source of Truth

When working on this repository:

1. AGENTS.md defines engineering and implementation rules.
2. DESIGN.md defines visual design direction and UI specifications.
3. Existing source code defines current functionality and behavior.
4. package.json defines the available dependencies and scripts.

Agents must read both AGENTS.md and DESIGN.md before making significant UI changes.

2. Project Overview

This repository is the personal portfolio website for Rizki Kudeng, a Full Stack Developer.

The portfolio showcases:

• professional profile
• technical skills
• experience
• selected projects
• engineering capabilities
• contact information

The website currently supports:

• English / Indonesian language switching
• responsive layouts
• animated UI interactions
• glassmorphic visual elements

The portfolio should position Rizki as a software engineer capable of building and maintaining real-world software systems, rather than simply presenting a list of technologies.

3. Tech Stack

• Framework: Next.js 15
• Architecture: App Router
• Runtime: React 19
• Language: TypeScript 5
• Styling: Tailwind CSS 3
• UI: @creativoma/liquid-glass
• Animation: Framer Motion
• Scroll Animation: AOS
• Particles: @tsparticles/react
• Icons: lucide-react, @tabler/icons-react
• Linter: ESLint 9
• Build: Next.js / Turbopack

Do not introduce new dependencies unless there is a clear technical or UX requirement that cannot reasonably be solved using the existing stack.

4. Repository Structure

porto/
├── public/
│   └── Static assets
│
├── src/
│   └── app/
│       ├── components/
│       │   ├── HeroSection.tsx
│       │   ├── AboutSection.tsx
│       │   ├── ProjectSection.tsx
│       │   ├── TechStackSection.tsx
│       │   ├── ContactSection.tsx
│       │   └── SectionWrapper.tsx
│       │
│       ├── data/
│       │   └── Static and typed portfolio data
│       │
│       ├── globals.css
│       ├── layout.tsx
│       └── page.tsx
│
├── AGENTS.md
├── DESIGN.md
├── eslint.config.mjs
├── next.config.ts
├── package.json
├── postcss.config.mjs
├── tailwind.config.ts
└── tsconfig.json

Do not reorganize the repository structure unless the existing architecture creates a concrete maintenance problem.

5. General Agent Behavior

5.1 Inspect Before Modifying

Before making changes:

1. Inspect the relevant existing components.
2. Inspect related data files.
3. Inspect globals.css and Tailwind configuration when changing visual behavior.
4. Check whether the functionality already exists.
5. Reuse existing components and utilities where appropriate.
6. Read DESIGN.md before implementing visual changes.

Do not blindly rewrite entire components when a targeted modification is sufficient.

5.2 Preserve Existing Functionality

A visual redesign must not accidentally remove working functionality.

Unless explicitly requested, preserve:

• language switching
• navigation behavior
• external links
• project links
• responsive behavior
• accessibility attributes
• metadata
• SEO configuration
• existing animations that remain relevant
• image loading behavior

A redesign is not permission to rewrite the application's architecture.

6. Design Implementation Rules

DESIGN.md is the source of truth for the visual redesign.

When implementing the design:

Priority Order

Use this priority:

1. usability
2. readability
3. accessibility
4. responsive behavior
5. visual consistency
6. animation / decoration

Do not sacrifice usability for visual effects.

6.1 Avoid Generic AI Portfolio Design

Do not produce a generic portfolio consisting of:

Hero
↓
About
↓
Skills
↓
Projects
↓
Contact

unless DESIGN.md explicitly specifies that structure.

The portfolio should communicate:

What Rizki builds, what problems he solves, and the quality of engineering behind the work.

The interface should feel intentional and personal rather than like a generic portfolio template.

6.2 Visual Hierarchy

Every section must have a clear hierarchy.

The agent should be able to answer:

• What is the primary message?
• What should the visitor notice first?
• What is secondary information?
• What action should the visitor take?

Avoid giving equal visual weight to every element.

6.3 Glassmorphism

The existing project uses glassmorphic UI.

Do not automatically apply glass effects to every element.

Glass effects should be used selectively for:

• cards
• navigation surfaces
• important interactive containers
• visual grouping

Avoid excessive:

• blur
• transparency
• borders
• shadows
• glowing effects

Text must remain readable over translucent backgrounds.

7. Bilingual Architecture

The application currently uses:

bahasa = false → English
bahasa = true  → Indonesian

Section components receive:

bahasa: boolean

When modifying or adding user-facing content:

• provide English text
• provide Indonesian text
• preserve semantic consistency between both languages

Do not leave one language incomplete.

Avoid awkward literal translations.

English and Indonesian copy should sound natural for their respective audiences.

8. Component Architecture

Prefer small, focused components.

A component should generally have one primary responsibility.

Examples:

HeroSection
ProjectSection
ProjectCard
ExperienceSection
TechStackSection
ContactSection
SectionWrapper

Do not create unnecessary abstraction solely to reduce file length.

At the same time, avoid putting large amounts of repeated JSX into page.tsx.

9. Data Separation

Static portfolio information should preferably live in:

src/app/data/

Examples:

• projects
• technologies
• experience
• social links
• navigation items

Use strongly typed structures.

Example:

interface Project {
  title: string;
  description: string;
  technologies: string[];
  image?: string;
  url?: string;
}

Avoid duplicating the same project or technology information across multiple components.

10. TypeScript Standards

Use strict TypeScript.

Rules:

• avoid any
• define interfaces/types for structured data
• type component props
• use union types where appropriate
• avoid unnecessary type assertions
• prefer inferred types when the type is obvious

Bad:

const data: any = ...

Preferred:

interface Project {
  title: string;
  description: string;
}

const project: Project = ...

11. React & Next.js Rules

Use "use client" only when necessary.

Client components are appropriate when using:

• useState
• useEffect
• browser APIs
• Framer Motion client interactions
• AOS
• interactive UI

Do not turn the entire application into a client component unnecessarily.

Prefer server-rendered components whenever possible.

12. Images

Use Next.js <Image /> whenever practical.

Images should have:

• meaningful alt
• appropriate dimensions
• priority only when necessary
• sensible loading behavior

Hero/LCP images may use:

priority

Do not mark every image as priority.

Do not use unnecessarily large source images when a smaller asset is sufficient.

13. Links

For internal navigation:

import Link from "next/link";

Use:

<Link href="/...">

For external links:

<a
  href="..."
  target="_blank"
  rel="noopener noreferrer"
>

Do not create fake internal routes for external resources.

14. Tailwind CSS Rules

Prefer existing Tailwind utilities.

Avoid adding arbitrary CSS when Tailwind can express the same behavior cleanly.

Use consistent:

• spacing
• typography
• responsive breakpoints
• border radius
• layout patterns

Do not solve every visual issue with arbitrary values.

Avoid excessive classes such as:

blur-[37px]
shadow-[...]
translate-y-[13px]

unless the value is genuinely required by the design.

15. Responsive Design

The portfolio must work across:

• mobile
• tablet
• desktop
• large desktop screens

At minimum, inspect behavior around:

320px
375px
768px
1024px
1440px

Do not treat mobile as a scaled-down desktop.

Consider:

• navigation
• typography
• card layout
• project images
• spacing
• button sizes
• text wrapping
• horizontal overflow
• animation performance

16. Animation Rules

Animation should communicate hierarchy or interaction.

Use animation for:

• entrance
• transition
• hover feedback
• scrolling
• navigation state
• project interaction

Avoid animation that exists only because it looks impressive.

Do not combine AOS and Framer Motion on the same DOM element unless there is a specific reason.

Avoid:

• excessive parallax
• continuous distracting motion
• large-scale layout shifts
• animation that blocks content visibility
• animations that significantly hurt mobile performance

Respect reduced-motion preferences where practical.

17. Accessibility

Interactive elements must be accessible.

Ensure:

• semantic HTML
• keyboard accessibility
• visible focus states
• sufficient text contrast
• meaningful alt text
• buttons are actual <button> elements
• links are actual <a> / <Link> elements
• decorative elements are not announced unnecessarily

Do not use clickable <div> elements when a semantic element is appropriate.

18. SEO & Metadata

Preserve and improve:

• page title
• description
• Open Graph metadata
• Twitter/X metadata where appropriate
• favicon
• semantic headings

There should generally be:

one primary H1

with logical H2/H3 hierarchy.

Do not add keyword stuffing.

The portfolio should be optimized for humans first.

19. Content Rules

Do not invent professional experience, projects, employers, achievements, statistics, or technical claims.

If information is missing:

• preserve existing content
• use a neutral placeholder only when necessary
• do not fabricate credentials

Portfolio copy should be:

• concise
• specific
• credible
• technically accurate

Prefer concrete descriptions over generic claims.

Avoid phrases such as:

Passionate developer who loves creating innovative solutions.

Prefer specific statements describing actual work and engineering responsibilities.

20. Redesign Workflow

When asked to redesign the portfolio, follow this process:

Step 1 — Understand

Inspect:

• existing page
• components
• assets
• data
• global styles
• dependencies

Step 2 — Read Design Specification

Read:

DESIGN.md

Identify:

• design direction
• information architecture
• visual system
• component requirements
• responsive requirements
• animation requirements

Step 3 — Map Existing → New

Before deleting existing sections, determine:

Existing component
        ↓
New design role
        ↓
Keep / modify / replace

Step 4 — Implement Structure

Build the page hierarchy first.

Do not start by polishing shadows, gradients, or animations.

Step 5 — Implement Visual System

Apply:

• typography
• colors
• spacing
• borders
• surfaces
• layout
• responsive behavior

Step 6 — Add Interaction

Only after the static layout is stable:

• hover states
• transitions
• entrance animations
• navigation interactions

Step 7 — Verify

Run:

npm run lint
npm run build

Fix all errors before completion.

21. Safe Modification Rules

Before deleting code, determine whether it provides:

• functionality
• data
• routing
• accessibility
• SEO
• animation
• responsive behavior

Do not remove code merely because it is visually inconvenient.

When replacing a component, preserve useful behavior unless the design explicitly removes it.

Prefer incremental changes over unnecessary rewrites.

22. Dependency Policy

Do not install a new package unless:

1. the requirement cannot reasonably be implemented with the existing stack, and
2. the package provides substantial value, and
3. it does not duplicate existing functionality.

Before adding a dependency, inspect whether an existing dependency already solves the problem.

23. Verification Checklist

Before completing a task:

Functional

• Existing navigation works
• Language switching works
• Project links work
• External links work
• No console errors

TypeScript

• No unnecessary any
• Props are typed
• Data structures are typed
• No broken imports

UI

• Desktop layout works
• Tablet layout works
• Mobile layout works
• No horizontal overflow
• Text remains readable
• Interactive states work

Accessibility

• Images have appropriate alt text
• Interactive elements are keyboard accessible
• Focus states are visible
• Semantic HTML is used
• Contrast is acceptable

Performance

• Images are optimized
• No unnecessary client components
• Animations do not cause major layout shifts
• No unnecessary dependencies

Code Quality

Run:

npm run lint
npm run build

Both should complete successfully before considering the task complete.

24. Definition of Done

A portfolio redesign is complete only when:

1. The implementation follows DESIGN.md.
2. Existing required functionality is preserved.
3. The visual hierarchy is clear.
4. The design works on mobile and desktop.
5. English and Indonesian content remain consistent.
6. Accessibility requirements are respected.
7. No unnecessary dependencies were introduced.
8. npm run lint succeeds.
9. npm run build succeeds.
10. The result feels like a deliberate personal portfolio rather than a generic AI-generated template.

25. Final Principle

The goal is not to make the portfolio contain more effects.

The goal is to make the visitor understand, within a short amount of time:

Who Rizki is, what he builds, how he thinks as an engineer, and why his work is credible.

When visual novelty conflicts with clarity, choose clarity.

When abstraction conflicts with maintainability, choose maintainability.

When animation conflicts with performance, choose performance.