From d010e2ac47fd92002922300b4dc72beed927ea13 Mon Sep 17 00:00:00 2001 From: murashit Date: Tue, 14 Jul 2026 22:23:04 +0900 Subject: [PATCH] docs: streamline agent guidance --- AGENTS.md | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index 6e9e6c5c..17057c63 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -1,8 +1,11 @@ This repository contains the Codex Panel Obsidian plugin. -Jujutsu is the recommended local change-management workflow when available. +## Working Principles -Use Conventional Commits for new commits; see `docs/development.md` for repository rules and local validation. +- Start from evidence. Reproduce defects before fixing them; for product changes, reconstruct the current workflow, user need, alternatives, and losses before deciding what should change. +- Use design documents as context, not as a substitute for current behavior and user expectations. Prefer coherent user-facing behavior and clear ownership, and remove needless abstraction or obsolete compatibility instead of preserving it by default. +- Treat implementation, tests, documentation, lint policy, and final history as one deliverable. Update any drift in the same change and report it. +- Parallelize only substantial concerns that can be implemented and tested independently with little shared-file contention. Keep small, tightly coupled, sequential, or coordination-heavy work together. ## What To Read @@ -12,4 +15,8 @@ Use Conventional Commits for new commits; see `docs/development.md` for reposito - Read `docs/release.md` for release preparation, release notes, preflight, tagging, pushing, and release repair. - Use the repo-local skills in `.agents/skills/` when a task matches a more specific workflow. -When implementation, design, or workflow changes create drift from docs or lint policy, update the affected docs or lint settings in the same change and report that update. +## Changes And Validation + +- Jujutsu is the recommended local change-management workflow when available. Make each final change a coherent review unit with an honest description. +- Before publishing, inspect and reorganize the graph when needed rather than preserving implementation chronology: normally fold corrective follow-ups into the concern they complete, split mixed changes, and keep a follow-up separate only when it remains meaningful on its own. +- Use Conventional Commits for new commits and follow `docs/development.md` for repository rules and validation. Re-run relevant validation after history edits and before handoff or publication.