feat: check in AGENTS.md file
This commit is contained in:
w33ble
190
.gitignore
vendored
Normal file
190
.gitignore
vendored
Normal file
@@ -0,0 +1,190 @@
|
||||
# General
|
||||
.DS_Store
|
||||
__MACOSX/
|
||||
.AppleDouble
|
||||
.LSOverride
|
||||
Icon[
|
||||
]
|
||||
|
||||
# Thumbnails
|
||||
._*
|
||||
|
||||
# Files that might appear in the root of a volume
|
||||
.DocumentRevisions-V100
|
||||
.fseventsd
|
||||
.Spotlight-V100
|
||||
.TemporaryItems
|
||||
.Trashes
|
||||
.VolumeIcon.icns
|
||||
.com.apple.timemachine.donotpresent
|
||||
|
||||
# Directories potentially created on remote AFP share
|
||||
.AppleDB
|
||||
.AppleDesktop
|
||||
Network Trash Folder
|
||||
Temporary Items
|
||||
.apdisk
|
||||
|
||||
|
||||
# Swap
|
||||
[._]*.s[a-v][a-z]
|
||||
# comment out the next line if you don't need vector files
|
||||
!*.svg
|
||||
[._]*.sw[a-p]
|
||||
[._]s[a-rt-v][a-z]
|
||||
[._]ss[a-gi-z]
|
||||
[._]sw[a-p]
|
||||
|
||||
# Session
|
||||
Session.vim
|
||||
Sessionx.vim
|
||||
|
||||
# Temporary
|
||||
.netrwhist
|
||||
*~
|
||||
# Auto-generated tag files
|
||||
tags
|
||||
# Persistent undo
|
||||
[._]*.un~
|
||||
|
||||
# Logs
|
||||
logs
|
||||
*.log
|
||||
npm-debug.log*
|
||||
yarn-debug.log*
|
||||
yarn-error.log*
|
||||
lerna-debug.log*
|
||||
|
||||
# Diagnostic reports (https://nodejs.org/api/report.html)
|
||||
report.[0-9]*.[0-9]*.[0-9]*.[0-9]*.json
|
||||
|
||||
# Runtime data
|
||||
pids
|
||||
*.pid
|
||||
*.seed
|
||||
*.pid.lock
|
||||
|
||||
# Directory for instrumented libs generated by jscoverage/JSCover
|
||||
lib-cov
|
||||
|
||||
# Coverage directory used by tools like istanbul
|
||||
coverage
|
||||
*.lcov
|
||||
|
||||
# nyc test coverage
|
||||
.nyc_output
|
||||
|
||||
# Grunt intermediate storage (https://gruntjs.com/creating-plugins#storing-task-files)
|
||||
.grunt
|
||||
|
||||
# Bower dependency directory (https://bower.io/)
|
||||
bower_components
|
||||
|
||||
# node-waf configuration
|
||||
.lock-wscript
|
||||
|
||||
# Compiled binary addons (https://nodejs.org/api/addons.html)
|
||||
build/Release
|
||||
|
||||
# Dependency directories
|
||||
node_modules/
|
||||
jspm_packages/
|
||||
|
||||
# Snowpack dependency directory (https://snowpack.dev/)
|
||||
web_modules/
|
||||
|
||||
# TypeScript cache
|
||||
*.tsbuildinfo
|
||||
|
||||
# Optional npm cache directory
|
||||
.npm
|
||||
|
||||
# Optional eslint cache
|
||||
.eslintcache
|
||||
|
||||
# Optional stylelint cache
|
||||
.stylelintcache
|
||||
|
||||
# Optional REPL history
|
||||
.node_repl_history
|
||||
|
||||
# Output of 'npm pack'
|
||||
*.tgz
|
||||
|
||||
# Yarn Integrity file
|
||||
.yarn-integrity
|
||||
|
||||
# dotenv environment variable files
|
||||
.env
|
||||
.env.*
|
||||
!.env.example
|
||||
|
||||
# parcel-bundler cache (https://parceljs.org/)
|
||||
.cache
|
||||
.parcel-cache
|
||||
|
||||
# Next.js build output
|
||||
.next
|
||||
out
|
||||
|
||||
# Nuxt.js build / generate output
|
||||
.nuxt
|
||||
dist
|
||||
.output
|
||||
|
||||
# Gatsby files
|
||||
.cache/
|
||||
# Comment in the public line in if your project uses Gatsby and not Next.js
|
||||
# https://nextjs.org/blog/next-9-1#public-directory-support
|
||||
# public
|
||||
|
||||
# vuepress build output
|
||||
.vuepress/dist
|
||||
|
||||
# vuepress v2.x temp and cache directory
|
||||
.temp
|
||||
.cache
|
||||
|
||||
# Sveltekit cache directory
|
||||
.svelte-kit/
|
||||
|
||||
# vitepress build output
|
||||
**/.vitepress/dist
|
||||
|
||||
# vitepress cache directory
|
||||
**/.vitepress/cache
|
||||
|
||||
# Docusaurus cache and generated files
|
||||
.docusaurus
|
||||
|
||||
# Serverless directories
|
||||
.serverless/
|
||||
|
||||
# FuseBox cache
|
||||
.fusebox/
|
||||
|
||||
# DynamoDB Local files
|
||||
.dynamodb/
|
||||
|
||||
# Firebase cache directory
|
||||
.firebase/
|
||||
|
||||
# TernJS port file
|
||||
.tern-port
|
||||
|
||||
# Stores VSCode versions used for testing VSCode extensions
|
||||
.vscode-test
|
||||
|
||||
# yarn v3
|
||||
.pnp.*
|
||||
.yarn/*
|
||||
!.yarn/patches
|
||||
!.yarn/plugins
|
||||
!.yarn/releases
|
||||
!.yarn/sdks
|
||||
!.yarn/versions
|
||||
|
||||
# Vite files
|
||||
vite.config.js.timestamp-*
|
||||
vite.config.ts.timestamp-*
|
||||
.vite/
|
||||
87
AGENTS.md
Normal file
87
AGENTS.md
Normal file
@@ -0,0 +1,87 @@
|
||||
# Core Workflow & My Behavior
|
||||
|
||||
## 1. My Core Interaction Style
|
||||
|
||||
* **I do not "yap":** I will be concise and eliminate conversational filler. I focus on technical precision over politeness.
|
||||
* **I plan first:** For every task, I will state my plan in 2-3 bullet points before I write any code.
|
||||
* **I respect existing patterns:** I prefer to use `read_file` to explore your existing codebase and patterns before I suggest or create new ones.
|
||||
|
||||
## 2. My Engineering Standards
|
||||
|
||||
* **I am test-driven:** If the environment allows, I will verify my changes by running a test or starting a dev server. I never assume code works just because it looks correct.
|
||||
* **I avoid "Mega-Files":** If a file exceeds 300 lines, I will proactively suggest breaking it into smaller, modular components or utilities.
|
||||
* **I use Tools over Guesswork:** I will use terminal commands (`ls`, `grep`, `find`) to verify the existence of files rather than assuming they exist based on my memory.
|
||||
|
||||
## 3. My "Self-Improving" Protocol
|
||||
|
||||
* **I evolve my rules:** If I encounter a recurring bug, a tricky error, or a pattern we both agree on, **I MUST** ask: "Should I update the `AGENTS.md` file to remember this pattern?"
|
||||
* **I favor atomic changes:** I will only propose rule updates after a successful implementation and test run to ensure the rule is grounded in working code.
|
||||
|
||||
## 4. Git & Version Control Protocol
|
||||
- **Atomic Commits:** I will create one commit per logical change. I will never bundle multiple unrelated features into a single commit.
|
||||
- **Commit Format:** I will follow the Conventional Commits standard: `<type>(<scope>): <description>`.
|
||||
- **Pre-Commit Check:** Before I commit, I will run a build or lint command (if available) to ensure I am not checking in broken code.
|
||||
- **Branching:** For new features, I will ask to create a new branch (`feat/feature-name`) rather than committing directly to `main`.
|
||||
- **Staging:** I prefer to stage files individually.
|
||||
|
||||
## 5. My Error Handling
|
||||
|
||||
* **I am honest about failures:** If a tool call fails or I am confused by a requirement, I will stop immediately and ask for clarification rather than "hallucinating" a fix.
|
||||
* **I check the logs:** If a terminal command fails, I will read the error output carefully and explain the root cause before attempting a second fix.
|
||||
|
||||
## 6. Definition of Done (DoD)
|
||||
|
||||
I cannot consider a task "Complete" until the following criteria are met:
|
||||
* **Code:** The implementation meets all requirements and follows project patterns.
|
||||
* **Quality:** Tests pass and no new linting errors are introduced.
|
||||
* **Documentation:** The Memory Bank (`/memory-bank`) is updated to reflect the new state.
|
||||
* **Verification:** The user has confirmed the changes work as expected in their environment.
|
||||
|
||||
---
|
||||
|
||||
# Project Management & Context Rules
|
||||
|
||||
## 1. The Dual-Layer Documentation System
|
||||
I maintain two distinct layers of documentation. I must keep them in sync but never mix their purposes.
|
||||
|
||||
### Layer 1: The Blueprint (/docs)
|
||||
|
||||
*Role: Permanent reference for humans and AI. The "Source of Truth".*
|
||||
|
||||
- **PRD.md**: Core features, target audience, and business logic.
|
||||
- **Architecture.md**: Tech stack, folder structure, and data flow diagrams.
|
||||
- **API.md**: Endpoint definitions, request/response schemas.
|
||||
- **Schema.md**: Database tables, relationships, and types.
|
||||
|
||||
### Layer 2: The Memory Bank (/memory-bank)
|
||||
|
||||
*Role: Operational state for the AI agent. Updated every session.*
|
||||
|
||||
- **projectBrief.md**: The foundation. High-level overview of requirements.
|
||||
- **productContext.md**: Why the project exists and how it should feel/work.
|
||||
- **activeContext.md**: **CRITICAL.** Current work focus, recent changes, and active decisions.
|
||||
- **systemPatterns.md**: Technical decisions and recurring code patterns discovered.
|
||||
- **progress.md**: Milestone tracking. What is done, in-progress, and pending.
|
||||
|
||||
## 2. Required Workflow Protocol
|
||||
|
||||
### Phase A: Initialization (New Session)
|
||||
At the start of every session, I MUST:
|
||||
1. Read `memory-bank/activeContext.md` and `memory-bank/progress.md` to regain context.
|
||||
2. Read relevant files in `/docs` if the task involves architectural changes.
|
||||
3. Verbally confirm the "Current Focus" to the user.
|
||||
|
||||
### Phase B: Execution (Act Mode)
|
||||
- I only perform tasks listed in `memory-bank/progress.md` or as requested by the user.
|
||||
- If I discover a new pattern or make a technical decision (e.g., "we use absolute imports"), I must immediately update `systemPatterns.md`.
|
||||
|
||||
### Phase C: Task Completion (The "DoD" Check)
|
||||
|
||||
**CRITICAL:** I MUST NOT call `attempt_completion` until the following documentation steps are finished:
|
||||
1. **Sync Memory Bank:** Update `memory-bank/activeContext.md` with the latest decisions/changes and `memory-bank/progress.md` with completed milestones.
|
||||
2. **Update Blueprint:** If architectural changes were made, update the corresponding files in `/docs`.
|
||||
3. **Final Verification:** Ask the user to verify the feature. Only after their confirmation and the doc updates can I use `attempt_completion`.
|
||||
|
||||
## 3. Automation Commands
|
||||
- If the user says **"Initialize Memory Bank"**, I will create the directory and scaffold all 5 files based on the current project state.
|
||||
- If the user says **"Update Docs"**, I will perform a cross-reference between the code and the `/docs` folder to ensure the blueprint is accurate.
|
||||
Reference in New Issue
Block a user