docusaurus-microsoft-auth

Imported from metyatech/docusaurus-microsoft-auth (AGENTS.md). Install upstream with npx skills add metyatech/docusaurus-microsoft-auth. Copyright stays with the author.

Tool Rules (compose-agentsmd)

• Before starting any work, run compose-agentsmd from the project root.
• To update shared rules, run compose-agentsmd edit-rules, edit the workspace rules, then run compose-agentsmd apply-rules.
• Do not edit AGENTS.md directly; update the source rules and regenerate.
• These tool rules live in tools/tool-rules.md in the compose-agentsmd repository; do not duplicate them in global rule modules.
• When updating rules, include a colorized diff-style summary in the final response. Use git diff --stat first, then include the raw ANSI-colored output of git diff --color=always (no sanitizing or reformatting), and limit the output to the rule files that changed.
• Also provide a short, copy-pasteable command the user can run to view the diff in the same format. Use absolute paths so it works regardless of the current working directory, and scope it to the changed rule files.
• If a diff is provided, a separate detailed summary is not required. If a diff is not possible, include a detailed summary of what changed (added/removed/modified items).

Source: github:metyatech/agent-rules@HEAD/rules/global/agent-rules-composition.md

Rule composition and maintenance

Scope and composition

• AGENTS.md is self-contained; do not rely on parent/child AGENTS for inheritance or precedence.
• Maintain shared rules centrally and compose per project; use project-local rules only for truly local policies.
• Place AGENTS.md at the project root; only add another AGENTS.md for nested independent projects.

Update policy

• Never edit AGENTS.md directly; update source rules and regenerate AGENTS.md.
• A request to "update rules" means: update the appropriate rule module and ruleset, then regenerate AGENTS.md.
• If the user gives a persistent instruction (e.g., "always", "must"), encode it in the appropriate module (global vs local).
• When acknowledging a new persistent instruction, update the rule module in the same change set and regenerate AGENTS.md.
• When creating a new repository, set up rule files (e.g., agent-ruleset.json and any local rules) so compose-agentsmd can run.
• When updating rules, infer the core intent; if it is a global policy, record it in global rules rather than project-local rules.
• If a task requires domain rules not listed in agent-ruleset.json, update the ruleset to include them and regenerate AGENTS.md before proceeding.
• When rule changes produce a diff, include it in the final response unless the user explicitly asks to omit it.

Editing standards

• Keep rules MECE, concise, and non-redundant.
• Use short, action-oriented bullets; avoid numbered lists unless order matters.
• Prefer the most general applicable rule to avoid duplication.

Source: github:metyatech/agent-rules@HEAD/rules/global/autonomous-operations.md

Autonomous operations

• Optimize for minimal human effort; default to automation over manual steps.
• Drive work from the desired outcome: infer acceptance criteria, choose the shortest safe path, and execute end-to-end.
• Assume end-to-end autonomy for repository operations (issue triage, PRs, merges, releases, repo admin) unless the user restricts scope.
• When work reveals rule gaps, redundancy, or misplacement, proactively update rule modules/rulesets (including moves/renames) and regenerate AGENTS.md without waiting for explicit user requests.
• When something is unclear, investigate to resolve it; do not proceed with unresolved material uncertainty. If still unclear, ask and include what you checked.
• Ask only blocking questions; for non-material ambiguities, pick the lowest-risk option, state the assumption, and proceed.
• Make decisions explicit when they affect scope, risk, cost, or irreversibility.
• Prefer asynchronous, low-friction control channels (GitHub Issues/PR comments) unless a repository mandates another.
• Design autonomous workflows for high volume: queue requests, set concurrency limits, and auto-throttle to prevent overload.

Source: github:metyatech/agent-rules@HEAD/rules/global/command-execution.md

Workflow and command execution

• Do not add wrappers or pipes to commands unless the user explicitly asks.
• Prefer repository-standard scripts/commands (package.json scripts, README instructions).
• Reproduce reported command issues by running the same command (or closest equivalent) before proposing fixes.
• Avoid interactive git prompts by using --no-edit or setting GIT_EDITOR=true.
• If elevated privileges are required, use sudo where available; otherwise run as Administrator.
• Keep changes scoped to affected repositories; when shared modules change, update consumers and verify at least one.
• If no branch is specified, work on the current branch; direct commits to main/master are allowed.
• After addressing PR comments, resolve related conversations; after completing a PR, merge it, sync the target branch, and delete the PR branch locally and remotely.

Source: github:metyatech/agent-rules@HEAD/rules/global/implementation-and-coding-standards.md

Engineering and implementation standards

• Prefer official/standard approaches recommended by the framework or tooling.
• Prefer well-maintained external dependencies; build in-house only when no suitable option exists.
• If functionality appears reusable, assess reuse first and propose a shared module/repo; prefer remote dependencies (never local filesystem paths).
• Maintainability > testability > extensibility > readability.
• Single responsibility; keep modules narrowly scoped and prefer composition over inheritance.
• Keep dependency direction clean and swappable; avoid global mutable state.
• Avoid deep nesting; use guard clauses and small functions.
• Use clear, intention-revealing naming; avoid "Utils" dumping grounds.
• Prefer configuration/constants over hardcoding; consolidate change points.
• Keep everything DRY across code, specs, docs, tests, configs, and scripts; proactively refactor repeated procedures into shared configs/scripts with small, local overrides.
• Fix root causes; remove obsolete/unused code, branches, comments, and helpers.
• Externalize large embedded strings/templates/rules when possible.
• Do not commit build artifacts (follow the repo's .gitignore).
• Align file/folder names with their contents and keep naming conventions consistent.
• Do not assume machine-specific environments (fixed workspace directories, drive letters, per-PC paths). Prefer repo-relative paths and explicit configuration so workflows work in arbitrary clone locations.

Source: github:metyatech/agent-rules@HEAD/rules/global/quality-testing-and-errors.md

Quality, testing, and error handling

Quality priority

• Quality (correctness, safety, robustness, verifiability) takes priority over speed or convenience.

Verification

• Run the smallest relevant set of lint/typecheck/test/build checks using repo-standard commands.
• Before committing code changes, run lint/test/build; if any are missing, add them in the same change set.
• Ensure commit-time automation (pre-commit or repo-native) runs lint/test/build for code changes when feasible.
• If required checks cannot be run, explain why and list the exact commands for the user.

Tests (behavior changes)

• Follow test-first: add/update tests and observe failure before implementing fixes.
• Add/update automated tests for behavior changes and regression coverage.
• Cover success, failure, boundary, invalid input, and key state transitions; include representative concurrency/retry/recovery when relevant.
• Keep tests deterministic; minimize time/random/external I/O; inject when needed.
• For deterministic output files, use full-content snapshot/golden tests.

Exceptions

• If required tests are impractical, document the coverage gap, provide a manual verification plan, and get explicit user approval before skipping.

Error handling and validation

• Never swallow errors; fail fast or return early with explicit errors.
• Error messages must reflect actual state and include relevant input context.
• Validate config and external inputs at boundaries; fail with actionable guidance.
• Log minimally but with diagnostic context; never log secrets or personal data.

Source: github:metyatech/agent-rules@HEAD/rules/global/user-identity-and-accounts.md

User identity and accounts

• The user's name is "metyatech".
• Any external reference using "metyatech" (GitHub org/user, npm scope, repos) is under the user's control.
• The user has GitHub and npm accounts.
• Use the gh CLI to verify GitHub details when needed.
• When publishing, cloning, adding submodules, or splitting repos, prefer the user's "metyatech" ownership unless explicitly instructed otherwise.

Source: github:metyatech/agent-rules@HEAD/rules/global/writing-and-documentation.md

Writing and documentation

User responses

• Respond in Japanese unless the user requests otherwise.
• After completing a response, emit the Windows SystemSounds.Asterisk sound via PowerShell when possible.

Developer-facing writing

• Write developer documentation, code comments, and commit messages in English.
• Rule modules are written in English.

README and docs

• Every repository must include README.md covering overview/purpose, setup, dev commands (build/test/lint), required env/config, and release/deploy steps if applicable.
• For any code change, assess README impact and update it in the same change set when needed.
• If a README update is not needed, explain why in the final response.
• CLI examples in docs must include required parameters.
• Do not include user-specific local paths, fixed workspace directories, drive letters, or personal data in doc examples. Prefer repo-relative paths and placeholders so instructions work in arbitrary environments.

Markdown linking

• When a Markdown document links to a local file, use a path relative to the Markdown file.

Source: github:metyatech/agent-rules@HEAD/rules/domains/node/module-system.md

Node module system (ESM)

• Default to TypeScript (.ts/.tsx); use JavaScript only for tool-required config files.
• Always set "type": "module" in package.json.
• Prefer ESM with .js extensions for JavaScript config/scripts (e.g., next.config.js as ESM).

Source: github:metyatech/agent-rules@HEAD/rules/domains/node/npm-packages.md

Node package publishing

• For scoped npm packages, set publishConfig.access = "public".
• Set files to constrain the published contents.
• If a clean npm install is insufficient, use prepare (or equivalent) to build.

Verification

• Use npm pack --dry-run to inspect the package contents.
• Run npm test when tests exist.

Source: github:metyatech/agent-rules@HEAD/rules/domains/release/release-and-publication.md

Release and publication

Packaging and distribution

• Include LICENSE in published artifacts (copyright holder: metyatech).
• Do not ship build/test artifacts or local configs; ensure a clean environment can use the product via README steps.
• Define a SemVer policy and document what counts as a breaking change.

Public repository metadata

• For public repos, set GitHub Description, Topics, and Homepage.
• Ensure required repo files exist: .github/workflows/ci.yml, issue templates, PR template, SECURITY.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md, CHANGELOG.md.
• Configure CI to run the repo's standard lint/test/build commands.

Versioning and release flow

• Update version metadata when release content changes; keep package version and Git tag consistent.
• Create and push a release tag; create a GitHub Release based on CHANGELOG.
• If asked to choose a version, decide it yourself.
• When bumping a version, create the GitHub Release and publish the package in the same update.
• For npm publishing, ask the user to run npm publish (do not execute it directly).
• Before publishing, run required prep commands (e.g., npm install, npm test, npm pack --dry-run) and only proceed when ready.
• If authentication fails during publish, ask the user to complete the publish step.
• Run dependency security checks before release, address critical issues, and report results.
• After publishing, update any locally installed copy to the latest release.

Published artifact requirements

• Populate package metadata (name, description, repository, issues, homepage, engines).
• Validate executable entrypoints and required shebangs so installed commands work.
• If a repo represents a single tool/product, publish a single package (bundle related scripts).

Source: github:metyatech/agent-rules@HEAD/rules/domains/web/web-ui-and-testing.md

Web UI and automation

Browser automation

• For web automation, use the agent-browser CLI.
• Prefer the ref-based workflow: agent-browser open -> agent-browser snapshot -i --json -> interact using @eN refs -> re-snapshot after changes.
• If browser launch fails due to missing Playwright binaries, run npx playwright install chromium and retry.

UI verification and E2E

• For user-visible UI changes, verify in a real browser using agent-browser; if not possible, explain and provide manual steps.
• Always add E2E tests for user-visible changes; if no harness exists, add one.
• Configure E2E to fail fast and avoid auto-opening browsers (headless/no-open).
• For Next.js E2E, prefer next build + next start.
• If Playwright tests fail to launch, clear playwright/.cache and retry.
• When adding/changing links, add tests that verify the target resolves; if not feasible, document manual verification.
• Use established icon libraries; do not handcraft custom icons or inline SVGs.