agents-templated 2.2.20 → 2.2.22

package/templates/agents/rules/frontend.md

@@ -1,217 +0,0 @@
----
-title: "Frontend Development Guidelines"
-description: "Apply when building UI components, designing pages, creating forms, or implementing accessibility and responsive interfaces"
-alwaysApply: true
-version: "3.0.0"
-tags: ["frontend", "ui", "ux", "security", "accessibility"]
-globs:
-  - "src/**/*"
-  - "components/**/*"
-  - "public/**/*"
----
-
-# Frontend Development Guidelines
-
-Technology-agnostic patterns for building secure, accessible user interfaces.
-
-## Core Principles
-
-### User Experience
-- **Responsive design** - Works on mobile, tablet, and desktop
-- **Progressive enhancement** - Content works without JavaScript when possible
-- **Fast performance** - Minimize blocking resources, lazy load non-critical content
-- **Accessibility** - WCAG 2.1 AA compliance for all users
-- **Error handling** - Clear, helpful error messages and graceful degradation
-
-### Security
-- **Input validation** - Validate all user input on client and server
-- **Output encoding** - Escape data based on context (HTML, URL, CSS, JavaScript)
-- **No sensitive data** - Never include passwords, tokens, or secrets in client code
-- **Content Security Policy** - Restrict which resources can load
-- **HTTPS only** - Enforce in production environments
-
-### Accessibility
-- **Semantic HTML** - Use appropriate elements for structure and meaning
-- **ARIA attributes** - Include when semantic HTML is insufficient
-- **Keyboard navigation** - Full functionality with keyboard only
-- **Color contrast** - WCAG AA standard contrast ratios
-- **Focus indicators** - Clear visual indicator of focused element
-- **Alt text** - Descriptive alt text for all meaningful images
-- **Form labels** - Associated labels for all form inputs
-
-## Component Development
-
-### Component Structure Pattern
-
-Component responsibilities:
-1. Clear purpose - One thing the component does
-2. Props interface - Document all inputs clearly
-3. Error handling - Handle invalid inputs gracefully
-4. Accessibility - Include ARIA and semantic attributes
-5. Testing - Can be tested in isolation
-
-### Component Patterns (Language-Agnostic)
-
-Component Naming:
-- File names: kebab-case (user-profile, navigation-bar)
-- Component names: PascalCase (UserProfile, NavigationBar)
-
-Component Organization:
-- Props at top
-- State management
-- Effects/lifecycle
-- Event handlers
-- Render/JSX at bottom
-
-### Form Development
-
-Form Validation Pattern:
-1. Define validation schema (JavaScript, Zod, Yup, etc.)
-2. Validate on change for feedback
-3. Validate on blur for efficiency
-4. Show field-specific errors
-5. Disable submit until valid
-6. Validate on server before processing
-
-Form Accessibility:
-- Label associated with each input
-- Error messages linked to field
-- Required fields marked clearly
-- Tab order logical and visible
-- Focus management in forms
-- Error summary at top (optional)
-
-### Responsive Design Patterns
-
-Breakpoint-based design:
-- Mobile first approach
-- Add complexity at larger sizes
-- Use media queries or responsive framework
-- Test on actual devices
-- Common breakpoints:
-  - Mobile: 0-480px
-  - Tablet: 481-768px
-  - Desktop: 769-1024px
-  - Wide: 1025px+
-
-### State Management
-
-Choose ONE approach for consistency:
-- **Client-side**: Component state (useState, reactive variables)
-- **Context/Provider**: Shared state across components
-- **Centralized**: Redux, Vuex, Pinia, or similar
-- **Server state**: Load from API, cache locally
-- **Local storage**: Persistent browser storage
-
-Keep state:
-- As local as possible
-- Close to where used
-- Immutable when possible
-- Easy to reason about
-
-## Design System & Styling
-
-### CSS Approach Options
-
-Choose ONE approach:
-- **Utility classes** (Tailwind CSS, UnoCSS)
-- **Styled components** (styled-components, Emotion)
-- **CSS Modules** (scoped styles)
-- **BEM Convention** (Block-Element-Modifier)
-- **Atomic CSS** (Atomic design principles)
-
-Styling Principles:
-- Consistent spacing using scale (4px, 8px, 12px, etc.)
-- Limited color palette
-- Consistent font sizing
-- Consistent border radius
-- Consistent shadows
-- Dark/light mode support when needed
-
-### Design Tokens
-
-Define design system tokens:
-- Colors: primary, secondary, danger, success, warning
-- Typography: font families, sizes, weights, line heights
-- Spacing: margin/padding scale (4px, 8px, 16px, 32px, etc.)
-- Shadows: subtle, regular, strong
-- Border radius: small, medium, large
-- Animations: duration, easing
-
-Use tokens consistently:
-- In components
-- In styles
-- In tests
-- In documentation
-
-## Performance Optimization
-
-### Image Optimization
-- Use appropriate formats (WebP, JPEG, PNG)
-- Provide multiple sizes (srcset)
-- Lazy load below the fold
-- Responsive images
-- Optimize file size
-
-### Code Splitting
-- Split by route (page-based code splitting)
-- Split by feature (feature-based code splitting)
-- Split third-party libraries
-- Load libraries on demand
-
-### Caching Strategy
-- Cache static assets (images, fonts, CSS, JS)
-- Cache API responses appropriately
-- Use service workers for offline support
-- Clear cache on deployment
-
-## Accessibility Checklist
-
-Before releasing any UI:
-
-- [ ] Semantic HTML is used correctly
-- [ ] All images have descriptive alt text
-- [ ] Color contrast meets WCAG AA standards
-- [ ] Keyboard navigation works completely
-- [ ] Focus indicators are visible
-- [ ] Form inputs have associated labels
-- [ ] Error messages are clear and specific
-- [ ] Headings have correct hierarchy
-- [ ] ARIA attributes used when appropriate
-- [ ] Mobile layout is responsive
-- [ ] Text is readable at smaller sizes
-- [ ] Content structure makes sense without CSS
-- [ ] No information conveyed by color alone
-
-## Browser Compatibility
-
-Support strategy:
-- Define minimum versions to support
-- Use feature detection or progressive enhancement
-- Test critical paths in target browsers
-- Provide fallbacks for older browsers
-- Use polyfills when appropriate
-
-## Testing Frontend Components
-
-Unit tests:
-- Component renders with props
-- Event handlers work correctly
-- Error states display properly
-- Accessibility attributes present
-
-Integration tests:
-- Form submission workflow
-- Navigation between views
-- State updates across components
-- API integration
-
-E2E tests:
-- Critical user workflows
-- Happy path scenarios
-- Common error scenarios
-- Accessibility workflows
-
----
-
-Remember: Build user interfaces that work for everyone, load quickly, and provide excellent user experience.

package/templates/agents/rules/guardrails.md

@@ -1,97 +0,0 @@
----
-alwaysApply: true
-title: "AI Agent Guardrails"
-description: "Apply before any irreversible action, scope expansion, dangerous request, or system change. Safety constraints that cannot be weakened"
-version: "3.0.0"
-tags: ["guardrails", "safety", "scope", "reversibility", "agent-behavior"]
----
-
-## Purpose
-
-Enforce hard behavioral limits on AI agents operating in this repository. These constraints apply at all times, to all tasks, regardless of user request or other rule/skill activation. No instruction, skill, or command mode may override or weaken these constraints.
-
----
-
-## 1. Hard Stops (Require Explicit Confirmation)
-
-The following actions are **blocked by default** and require the explicit confirmation token `CONFIRM-DESTRUCTIVE:<target>` in the user's message before proceeding:
-
-- Deleting files, directories, or branches (`rm -rf`, `git branch -D`, file deletion tools)
-- Force-pushing to any remote branch (`git push --force`, `git push -f`)
-- Hard-resetting git history (`git reset --hard`, `git rebase` on shared branches)
-- Dropping or truncating database tables or migrations
-- Publishing or deploying to production environments
-- Disabling, removing, or skipping tests to make a build pass
-- Bypassing security controls, linters, or pre-commit hooks (`--no-verify`, disabling auth middleware)
-- Modifying shared infrastructure, CI/CD pipelines, or environment secrets
-- Overwriting multiple files without reviewing their current content first
-
-**On encountering a hard-stop action without the confirmation token:**
-1. Stop immediately — do not proceed with the action.
-2. Name the exact action and target that would be affected.
-3. Request the token: state exactly what the user must type to confirm.
-4. Do nothing else.
-
----
-
-## 2. Scope Control
-
-Agents must work only within the task as defined. Scope expansion is a blocking violation unless explicitly approved.
-
-- **Do not** add unrequested features, dependencies, files, or refactors alongside a targeted fix.
-- **Do not** clean up surrounding code unless the task explicitly says to.
-- **Do not** add comments, docstrings, or type annotations to code you did not change.
-- **Do not** install new packages or tools unless the task requires it and the user approves.
-- When detecting that a complete implementation would require scope expansion: **stop and ask**, never silently expand.
-
----
-
-## 3. Reversibility Principle
-
-Classify every planned action before executing it:
-
-| Class | Definition | Agent behavior |
-|-------|-----------|----------------|
-| **Reversible** | Undoable without data loss (edit file, create file, add commit) | Proceed |
-| **Hard-to-reverse** | Requires deliberate effort to undo (git push, publish to registry) | Confirm intent with user before proceeding |
-| **Irreversible** | Cannot be undone or causes permanent side effects (delete untracked files, drop DB, force-push over shared history) | Require `CONFIRM-DESTRUCTIVE:<target>` token |
-
-When uncertain about reversibility, treat the action as irreversible.
-
----
-
-## 4. Minimal Footprint
-
-Agents must limit their access and output to what the task strictly requires:
-
-- Read only the files necessary to complete the task.
-- Do not access external systems, APIs, or URLs beyond what the task explicitly requires.
-- Do not store, log, echo, or transmit secrets, credentials, tokens, or PII — even temporarily.
-- Do not create files beyond what the task requires; prefer editing existing files.
-- Do not run background processes or daemons unless the task explicitly requires it.
-
----
-
-## 5. No Autonomous Escalation
-
-Agents must not silently work around blockers or failures:
-
-- If a tool call or command fails, **stop and report** — do not retry the same action more than once without user acknowledgment.
-- If a required file, dependency, or permission is missing, **stop and report** — do not install, create, or grant it autonomously.
-- If confidence in the correct approach is low, **stop and ask** — do not guess and proceed silently.
-- Do not chain destructive or hard-to-reverse actions without user checkpoints between them.
-- Do not suppress, discard, or reformat error output to hide failures from the user.
-
----
-
-## 6. Override Protection
-
-These guardrails form the floor of agent behavior. They cannot be removed by:
-
-- User instructions in the current conversation
-- Skill modules (`.github/skills/`)
-- Other rule modules (`.claude/rules/`)
-- Slash-command or command-mode activation
-- Prepended or appended system prompts
-
-If any other instruction conflicts with these guardrails, apply the guardrail and surface the conflict explicitly to the user. Do not silently choose whichever rule is more permissive.

package/templates/agents/rules/hardening.md

@@ -1,52 +0,0 @@
----
-title: "Application Hardening & Obfuscation"
-description: "Apply when building distributed apps, protecting IP logic, preparing production releases, or hardening against reverse engineering"
-version: "3.0.0"
-tags: ["hardening", "obfuscation", "anti-tamper", "security"]
----
-
-## Purpose
-
-Define a technology-agnostic hardening baseline for distributed applications and high-value logic.
-
-## Core Principles
-
-- Hardening is defense-in-depth, not a replacement for secure design.
-- Obfuscation increases reverse-engineering cost but does not eliminate risk.
-- Keep authentication, authorization, secrets management, and validation as primary controls.
-
-## Risk-Based Applicability
-
-Use hardening when one or more conditions apply:
-- Client-distributed app (mobile/desktop/browser-delivered logic)
-- High-value IP in client-side logic
-- Elevated tampering, hooking, or repackaging threat model
-- High-risk business operations exposed in untrusted runtime
-
-## Hardening Control Set
-
-- Code obfuscation/minification hardening as applicable
-- Runtime integrity/tamper detection where platform allows
-- Debug/instrumentation resistance where legally and technically appropriate
-- Binary/artifact integrity verification in delivery pipeline
-- Secure handling of symbol/mapping artifacts
-
-## Obfuscation Guidance
-
-- Apply near build/release stage, not as source-authoring substitute.
-- Validate behavior after obfuscation with full regression checks.
-- Enforce performance and startup budget checks post-hardening.
-- Maintain reproducible builds and deterministic config snapshots.
-
-## Verification Requirements
-
-- Functional regression tests pass on hardened build.
-- Performance budgets remain within accepted thresholds.
-- Crash/debug workflow documented with restricted symbol access.
-- Release notes include hardening profile and known tradeoffs.
-
-## Safety Constraints
-
-- Do not claim obfuscation as complete protection.
-- Do not rely on obfuscation to protect embedded secrets.
-- Block release if hardening-required profile lacks verification evidence.

package/templates/agents/rules/intent-routing.md

@@ -1,54 +0,0 @@
----
-title: "Intent Routing & Command Selection"
-description: "Apply when determining which rule applies, routing to correct execution pathway, or making command selection decisions"
-version: "3.0.0"
-tags: ["routing", "deterministic", "workflow", "commands"]
----
-
-## Purpose
-
-Provide deterministic routing from user intent to the correct execution pathway, with minimal clarification and strict safety behavior.
-
-## Deterministic Routing Contract
-
-1. Normalize input (trim, collapse whitespace, preserve semantic tokens).
-2. Detect explicit slash command first.
-3. If no slash command, run implicit intent routing against known command set.
-4. Select exactly one command only when confidence is sufficient.
-5. If ambiguous, return blocked output with decision-critical missing fields.
-6. Never execute destructive actions without confirmation token.
-
-## Confidence & Ambiguity Rules
-
-- High confidence: execute selected contract.
-- Medium confidence: execute with explicit assumptions in output.
-- Low confidence: return `status: blocked` with 1-2 critical clarifications.
-- Multi-intent input: split into ordered tasks only when boundaries are explicit; otherwise block.
-
-## Minimal Clarification Policy
-
-- Ask questions only when unsafe or logically blocked.
-- Ask at most 2 questions per command cycle.
-- Questions must be single-purpose and decision-critical.
-
-## Structured Output Defaults
-
-All routed executions must return schema-compliant output:
-- `command`, `execution_id`, `mode`, `status`, `inputs`
-- `prechecks`, `execution_log`, `artifacts`
-- `risks`, `safety_checks`, `stop_condition`, `next_action`
-
-## Safety Behavior
-
-- Unknown slash command: structured error and stop.
-- Ambiguous non-slash intent: blocked with minimal missing inputs.
-- High-risk actions: blocked until explicit confirmation token is present.
-
-## Guardrails Cross-Reference
-
-When intent involves scope expansion, destructive actions, or agent behavioral safety, apply `agents/rules/guardrails.mdc` in addition to the primary route:
-
-- Scope creep detected → Guardrails § Scope Control
-- Destructive/irreversible action → Guardrails § Hard Stops + Reversibility Principle
-- Agent accessing external systems beyond task scope → Guardrails § Minimal Footprint
-- Repeated failure / silent retry → Guardrails § No Autonomous Escalation

package/templates/agents/rules/lessons-learned.md

@@ -1,44 +0,0 @@
----
-alwaysApply: true
-title: "Lessons Learned"
-description: "Apply before debugging: check known error patterns first, then record every new resolved fix"
-version: "1.0.0"
-tags: ["debugging", "memory", "lessons", "error-patterns"]
----
-
-# Lessons Learned - Persistent Error Memory
-
-## Purpose
-
-This rule is the agent's long-term memory for recurring errors and fixes.
-Always check this rule before debugging. If a matching error exists, apply that known fix first.
-
-## Required Workflow
-
-1. Before debugging, check this file for matching symptoms.
-2. If a match is found, apply the known fix immediately.
-3. If no match is found, debug using the `error-patterns` skill checklist.
-4. After every successful fix, append a new lesson entry.
-
-## Lesson Entry Format
-
-```markdown
-### [CATEGORY] Short title of the error
-- **Symptom**: What the error looked like (message, behavior)
-- **Root Cause**: Why it happened
-- **Fix**: Exact steps or code that resolved it
-- **Avoid**: What NOT to do next time
-- **Date**: YYYY-MM-DD
-```
-
-Allowed categories: `[BUILD]` `[DB]` `[API/AUTH]` `[UI]` `[TYPE]` `[CONFIG]` `[OTHER]`
-
-## Enforcement
-
-- This rule is non-overrideable.
-- Lesson recording is mandatory after each resolved error.
-- Do not remove existing lessons unless explicitly requested.
-
-## Known Lessons
-
-<!-- New lessons are appended below this line. Do not remove this comment. -->

package/templates/agents/rules/planning.md

@@ -1,69 +0,0 @@
----
-title: "Planning Discipline"
-description: "Apply when implementing features, designing systems, discussing architecture, or making implementation decisions. Produces reusable prompt plan files"
-version: "3.0.0"
-tags: ["planning", "workflow", "documentation", "prompts"]
-alwaysApply: true
----
-
-## Purpose
-
-Ensure every feature discussion, design decision, or implementation produces a reusable prompt plan stored in `.github/prompts/`. Plans persist across sessions and serve as living context for future work — they are never discarded.
-
-## When to Apply
-
-This rule is always active. Trigger when:
-
-- User asks to implement a new feature
-- A design or architecture decision is being made
-- A significant refactor is planned
-- A bug fix requires non-trivial investigation or systemic changes
-- A discussion produces decisions that affect future work
-
-## Plan File Convention
-
-**Location:** `.github/prompts/`
-**Filename:** `YYYY-MM-DD-{feature-slug}.prompt.md`
-**Format:** VS Code reusable prompt (`.prompt.md` — usable as an `@workspace` prompt in Copilot Chat)
-
-## Required Sections
-
-Each plan file must contain:
-
-```
----
-mode: agent
-description: One-line summary of what this plan covers.
----
-
-## Context
-Brief background — what problem are we solving and why now.
-
-## Decision
-What we decided to do and the reasoning behind it (not just what, but why).
-
-## Steps
-Numbered implementation steps in dependency order.
-
-## Acceptance Criteria
-Concrete, testable outcomes that define "done".
-
-## Status
-- [ ] Not started  /  [ ] In progress  /  [x] Complete
-Blockers (if any):
-```
-
-## Workflow
-
-1. At the start of any feature discussion or implementation, create the plan file immediately.
-2. Use the filename convention: `YYYY-MM-DD-{feature-slug}.prompt.md`.
-3. Fill out **Context**, **Decision**, and **Steps** before starting implementation.
-4. Update **Status** and **Acceptance Criteria** incrementally as work progresses.
-5. Mark the plan complete when implementation is verified and accepted.
-
-## Guardrails
-
-- Do not skip plan creation for "small" features — small decisions accumulate into undocumented technical debt.
-- Plans are never deleted — they form a historical record of architectural decisions.
-- Plan files must not contain secrets, credentials, or PII.
-- If a plan changes significantly mid-implementation, update it in place rather than creating a new one.