Add /ultraresearch-local for structured research combining local codebase analysis with external knowledge via parallel agent swarms. Produces research briefs with triangulation, confidence ratings, and source quality assessment. New command: /ultraresearch-local with modes --quick, --local, --external, --fg. New agents: research-orchestrator (opus), docs-researcher, community-researcher, security-researcher, contrarian-researcher, gemini-bridge (all sonnet). New template: research-brief-template.md. Integration: --research flag in /ultraplan-local accepts pre-built research briefs (up to 3), enriches the interview and exploration phases. Planning orchestrator cross-references brief findings during synthesis. Design principle: Context Engineering — right information to right agent at right time. Research briefs are structured artifacts in the pipeline: ultraresearch → brief → ultraplan --research → plan → ultraexecute. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
262 lines
9.7 KiB
Markdown
262 lines
9.7 KiB
Markdown
Always use TypeScript for all code
|
|
Use ESLint and Prettier for code formatting.
|
|
Run linting before every commit.
|
|
Keep functions small and focused.
|
|
TODO: fix this linting config
|
|
Write unit tests for all business logic.
|
|
Use dependency injection where possible.
|
|
Avoid global state.
|
|
Always use TypeScript for all code
|
|
Document all public APIs with JSDoc.
|
|
Use interfaces over type aliases for objects.
|
|
Prefer readonly properties when possible.
|
|
Never use var, always use const or let.
|
|
TODO: fix this type definition
|
|
Use async/await instead of raw promises.
|
|
Handle errors explicitly, never swallow them.
|
|
Log errors with full context.
|
|
Use structured logging (JSON format).
|
|
Always use TypeScript for all code
|
|
Validate all inputs at service boundaries.
|
|
Sanitize all outputs before sending to clients.
|
|
Never hardcode secrets or credentials.
|
|
Use environment variables for configuration.
|
|
TODO: fix this environment variable handling
|
|
Always use TypeScript for all code
|
|
Keep configuration separate from code.
|
|
Use feature flags for experimental features.
|
|
Write integration tests for critical paths.
|
|
Use mocks for external dependencies in unit tests.
|
|
Prefer composition over inheritance.
|
|
Keep modules loosely coupled.
|
|
Use dependency inversion principle.
|
|
Separate concerns between layers.
|
|
Use repository pattern for data access.
|
|
Service layer should not know about HTTP.
|
|
Controllers should not contain business logic.
|
|
Use DTOs for data transfer between layers.
|
|
Validate DTOs at the entry point.
|
|
Use class-validator for DTO validation.
|
|
Use class-transformer for serialization.
|
|
Keep response shapes consistent.
|
|
Document API endpoints with OpenAPI.
|
|
Version your APIs from the start.
|
|
Use semantic versioning.
|
|
Tag releases in git.
|
|
Write a changelog for every release.
|
|
Squash commits before merging to main.
|
|
Write meaningful commit messages.
|
|
Use conventional commits format.
|
|
Link commits to issue tracker entries.
|
|
Review your own code before asking for review.
|
|
Use pull requests for all changes.
|
|
Require at least one review before merging.
|
|
Use CI checks to enforce quality gates.
|
|
Run tests in CI on every pull request.
|
|
Use branch protection rules on main.
|
|
Delete branches after merge.
|
|
Keep the main branch always deployable.
|
|
Use feature branches for development.
|
|
Rebase on main before merging.
|
|
Resolve conflicts locally before pushing.
|
|
Keep pull requests small and focused.
|
|
Add screenshots for UI changes.
|
|
Write a test plan in the PR description.
|
|
Reference related issues in pull requests.
|
|
Assign reviewers explicitly.
|
|
Respond to review comments promptly.
|
|
Mark resolved conversations.
|
|
Do not merge your own pull requests.
|
|
Check that all CI checks pass before merging.
|
|
Prefer squash merge strategy.
|
|
Update the changelog after merging.
|
|
Close related issues after merge.
|
|
Deploy after every merge to main.
|
|
Monitor deployments after release.
|
|
Roll back immediately if errors spike.
|
|
Use blue-green deployments for zero downtime.
|
|
Automate deployments using CI/CD pipelines.
|
|
Store infrastructure as code.
|
|
Use Terraform for infrastructure management.
|
|
Review infrastructure changes before applying.
|
|
Use remote state for Terraform.
|
|
Lock Terraform provider versions.
|
|
Document infrastructure decisions in ADRs.
|
|
Keep secrets out of infrastructure code.
|
|
Use a secrets manager for production secrets.
|
|
Rotate secrets regularly.
|
|
Audit access to secrets.
|
|
Use RBAC for authorization.
|
|
Apply least privilege principle.
|
|
Review permissions quarterly.
|
|
Log all privileged operations.
|
|
Use multi-factor authentication everywhere.
|
|
Enforce password policies.
|
|
Use SSO where possible.
|
|
Scan dependencies for vulnerabilities.
|
|
Update dependencies regularly.
|
|
Pin dependency versions in production.
|
|
Use a lock file for all package managers.
|
|
Review licenses of all dependencies.
|
|
Avoid dependencies with no maintenance.
|
|
Prefer smaller, focused packages.
|
|
Check bundle size impact of new dependencies.
|
|
Remove unused dependencies.
|
|
Run npm audit on every CI build.
|
|
Address high severity vulnerabilities immediately.
|
|
Track open vulnerabilities in issue tracker.
|
|
Set up automated dependency update PRs.
|
|
Review Dependabot PRs weekly.
|
|
Test dependency upgrades in a staging environment.
|
|
Keep Node.js version up to date.
|
|
Use LTS versions of Node.js.
|
|
Document the required Node.js version.
|
|
Use .nvmrc or .node-version files.
|
|
Enforce Node.js version in CI.
|
|
Use Docker for local development environments.
|
|
Keep Docker images small.
|
|
Use multi-stage builds for production images.
|
|
Scan Docker images for vulnerabilities.
|
|
Do not run containers as root.
|
|
Use read-only filesystems where possible.
|
|
Set resource limits on containers.
|
|
Use health checks in Docker containers.
|
|
Use named volumes for persistent data.
|
|
Document Docker networking configuration.
|
|
Use docker-compose for local multi-service setups.
|
|
Version docker-compose files.
|
|
Keep docker-compose files out of production.
|
|
Use Kubernetes for orchestration in production.
|
|
Define resource requests and limits for pods.
|
|
Use namespaces for environment separation.
|
|
Apply network policies between services.
|
|
Use readiness and liveness probes.
|
|
Configure horizontal pod autoscaling.
|
|
Use persistent volume claims for stateful services.
|
|
Back up persistent volumes regularly.
|
|
Test backup restoration periodically.
|
|
Monitor disk usage on all nodes.
|
|
Set up alerts for critical system metrics.
|
|
Use a centralized logging solution.
|
|
Retain logs for at least 90 days.
|
|
Archive logs to cold storage after 30 days.
|
|
Set up log-based alerting for errors.
|
|
Use distributed tracing for microservices.
|
|
Correlate logs and traces using request IDs.
|
|
Monitor API latency percentiles.
|
|
Set SLOs for all critical services.
|
|
Track error budget consumption.
|
|
Conduct post-mortems for all incidents.
|
|
Document runbooks for common incidents.
|
|
Keep runbooks up to date.
|
|
Test runbooks regularly.
|
|
Practice chaos engineering.
|
|
Define recovery time objectives.
|
|
Define recovery point objectives.
|
|
Test disaster recovery procedures annually.
|
|
Document on-call procedures.
|
|
Rotate on-call responsibilities.
|
|
Compensate on-call fairly.
|
|
Track on-call incidents and burnout signals.
|
|
Hold regular architecture review meetings.
|
|
Document decisions in architecture decision records.
|
|
Review and update ADRs as systems evolve.
|
|
Share architectural knowledge across the team.
|
|
Hold regular tech debt review sessions.
|
|
Prioritize tech debt alongside features.
|
|
Track tech debt in the issue tracker.
|
|
Set a tech debt budget per sprint.
|
|
Refactor incrementally, not in big bang rewrites.
|
|
Write tests before refactoring.
|
|
Measure test coverage trends over time.
|
|
Aim for meaningful coverage, not 100 percent.
|
|
Use mutation testing to assess test quality.
|
|
Avoid testing implementation details.
|
|
Test behavior, not structure.
|
|
Keep tests independent and isolated.
|
|
Use test data factories for complex objects.
|
|
Reset state between tests.
|
|
Avoid hardcoded test data.
|
|
Use realistic test data where possible.
|
|
Anonymize personal data in test datasets.
|
|
Never use production data in development.
|
|
Use database migrations for schema changes.
|
|
Test migrations before applying to production.
|
|
Make migrations reversible.
|
|
Run migrations in a transaction.
|
|
Seed databases for development and testing.
|
|
Keep seed data minimal and representative.
|
|
Document database schema changes.
|
|
Index columns used in frequent queries.
|
|
Monitor query performance in production.
|
|
Use query explain plans to diagnose slow queries.
|
|
Avoid N+1 queries.
|
|
Cache aggressively but invalidate correctly.
|
|
Use Redis for distributed caching.
|
|
Set TTLs on all cache entries.
|
|
Monitor cache hit rates.
|
|
Warm caches after deployment.
|
|
Use CDN for static assets.
|
|
Enable HTTP/2 and HTTP/3 where possible.
|
|
Compress responses with gzip or brotli.
|
|
Minimize JavaScript bundle sizes.
|
|
Lazy load non-critical resources.
|
|
Measure and budget page load performance.
|
|
Use Lighthouse for performance auditing.
|
|
Set performance regression budgets in CI.
|
|
Monitor Core Web Vitals in production.
|
|
Use server-side rendering for SEO-critical pages.
|
|
Pre-render static pages where possible.
|
|
Use incremental static regeneration when applicable.
|
|
Test accessibility with automated tools.
|
|
Fix all critical accessibility issues before launch.
|
|
Test with real assistive technologies.
|
|
Follow WCAG 2.1 AA guidelines.
|
|
Provide text alternatives for all images.
|
|
Ensure sufficient color contrast.
|
|
Make all interactive elements keyboard accessible.
|
|
Use semantic HTML elements.
|
|
Add ARIA attributes only when necessary.
|
|
Test with users with disabilities when possible.
|
|
Document accessibility decisions.
|
|
Include accessibility in the definition of done.
|
|
Train the team on accessibility basics.
|
|
Review accessibility in code review.
|
|
Track accessibility issues separately.
|
|
Prioritize accessibility issues appropriately.
|
|
Celebrate accessibility improvements.
|
|
Share accessibility learnings across projects.
|
|
Stay up to date with accessibility standards.
|
|
Advocate for accessibility in product planning.
|
|
Perform regular security audits.
|
|
Use static analysis tools for security scanning.
|
|
Integrate SAST into CI pipelines.
|
|
Review OWASP Top 10 annually.
|
|
Train developers on secure coding practices.
|
|
Track security findings in the issue tracker.
|
|
Address critical security issues within 24 hours.
|
|
Address high security issues within one week.
|
|
Conduct penetration testing before major releases.
|
|
Document security threat models.
|
|
Review threat models when architecture changes.
|
|
Use Content Security Policy headers.
|
|
Set security headers on all HTTP responses.
|
|
Use HTTPS everywhere.
|
|
Redirect HTTP to HTTPS.
|
|
Use HSTS with a long max-age.
|
|
Validate and escape all user input.
|
|
Use parameterized queries for database access.
|
|
Avoid SQL string concatenation.
|
|
Use prepared statements.
|
|
Sanitize file paths before using them.
|
|
Use allowlists for file extension validation.
|
|
Never trust client-supplied file names.
|
|
Limit file upload sizes.
|
|
Scan uploaded files for malware.
|
|
Store uploaded files outside the web root.
|
|
Use signed URLs for serving uploaded files.
|
|
Expire signed URLs appropriately.
|
|
Audit file access logs regularly.
|
|
Use rate limiting on all public endpoints.
|
|
@imports/a.md
|
|
@docs/nonexistent.md
|