@mohammadhprp/system-prompt 0.10.1

package/framework/references/standards/logging.md

@@ -0,0 +1,43 @@
+# Logging Standard
+
+## Purpose
+
+Define reusable backend engineering rules for logging decisions across projects. This standard is canonical guidance for related skills.
+
+## Rules
+
+- All logs must be structured JSON: every event has `timestamp`, `level`, `logger`, `message`, `trace_id`, and `correlation_id`.
+- Log levels follow strict semantics: ERROR for definite failures, WARN for unexpected-but-recoverable situations, INFO for significant lifecycle events, DEBUG for troubleshooting details, TRACE for step-by-step execution paths.
+- Every request must carry a `correlation_id` generated at the ingress boundary and propagated to all downstream calls; include it in every request-scoped log line.
+- Never log sensitive data: passwords, tokens, API keys, PII (email, phone, SSN), or payment card numbers; use a scrubber at the log sink level as a safety net.
+- Production log level must be INFO or higher; DEBUG and TRACE must be toggleable at runtime without restart.
+
+## Best Practices
+
+- Log at entry and exit of every service boundary with duration: `"handling request"` / `"request complete (12ms)"`.
+- Use structured key-value pairs instead of string interpolation: `{"event": "payment_failed", "amount": 5000, "currency": "USD"}` instead of `"payment failed for $50.00"`.
+- Include actionable context in ERROR logs: the operation attempted, the input that caused the failure, and the error type; never log just the stack trace.
+- Set log sampling at the trace level (not per-line) to preserve correlation; log the sample rate in the log metadata so consumers can adjust counts.
+- Use asynchronous, non-blocking log appenders to avoid log writes from blocking application threads.
+
+## Anti-patterns
+
+- Logging in tight loops or hot paths (every database query, every iteration); log at operation granularity, not per-element.
+- Using `print()` or `console.log()` instead of a structured logger; they bypass routing, formatting, and correlation.
+- Logging the same event at multiple levels (both INFO and DEBUG for the same call).
+- Including stack traces in INFO or WARN logs; stack traces belong in ERROR logs only.
+- Sending debug-level logs to production with no runtime toggle; they bury signal in noise.
+
+## Checklist
+
+- [ ] All logs are structured JSON with standard fields (`timestamp`, `level`, `message`, `trace_id`).
+- [ ] Correlation IDs are propagated from ingress through all downstream calls.
+- [ ] No sensitive data (PII, secrets, tokens) appears in any log line.
+- [ ] Production log level is configured to INFO; DEBUG/TRACE is toggleable at runtime.
+- [ ] Hot paths have been reviewed to avoid logging in tight loops.
+
+## Related Skills
+
+- `skills/backend-engineer/SKILL.md`
+- `skills/code-review/SKILL.md`
+- `skills/backend-best-practices/references/observability.md`

package/framework/references/standards/naming.md

@@ -0,0 +1,43 @@
+# Naming Standard
+
+## Purpose
+
+Define reusable backend engineering rules for naming decisions across projects. This standard is canonical guidance for related skills.
+
+## Rules
+
+- Follow language conventions: Go uses `camelCase` for exported, `camelCase` for unexported; Python/JS uses `snake_case` for everything; Java/C#/TypeScript uses `PascalCase` for types and `camelCase` for methods/variables; SQL uses `snake_case`.
+- File names match the primary export: `user_repository.go`, `order_handler.py`, `PaymentService.ts`.
+- Boolean variables and parameters must use a predicate prefix: `is_`, `has_`, `can_`, `should_`, `was_` (e.g., `is_active`, `has_permission`).
+- Classes/types must be nouns or noun phrases; functions/methods must be verbs or verb phrases.
+- Abbreviations must be in the project glossary; avoid ambiguous or non-standard abbreviations (`cust` for customer, `addr` for address, `calc` for calculate).
+
+## Best Practices
+
+- Name things by what they mean in the business domain, not by their implementation: `InvoiceRepository` not `MySQLInvoiceRepo`, `calculateDiscount` not `applyFormula`.
+- Use consistent suffixes for similar concerns: `Factory`, `Repository`, `Service`, `Controller`, `DTO`, `Mapper`.
+- Keep names proportional to scope: short names for small scopes (`i` for loop index), descriptive names for wide scopes (`calculateMonthlySubscriptionRevenue`).
+- Rename aggressively when code reveals a clearer abstraction; naming debt compounds faster than any other technical debt.
+- Group related constants and enums with a shared prefix: `OrderStatus.Pending`, `OrderStatus.Shipped`, `OrderStatus.Delivered`.
+
+## Anti-patterns
+
+- Hungarian notation or type-encoding in names (`strName`, `intCount`, `objUser`); use the type system instead.
+- Name stuttering: `OrderService.getOrder()`, `UserEntity.getId()`, `Invoice.invoiceNumber`.
+- Single-letter names outside of loop variables, throwaway lambdas, or mathematical contexts.
+- Naming things after the person who wrote it or inside jokes; names must be meaningful to any future reader.
+- Using the same term for different concepts (`Account` for both user accounts and financial accounts in the same system).
+
+## Checklist
+
+- [ ] Names follow the language-appropriate casing convention consistently.
+- [ ] Boolean variables use `is_`/`has_`/`can_` prefix.
+- [ ] No stuttering or Hungarian notation in the codebase.
+- [ ] All abbreviations are in the project glossary.
+- [ ] Renames are applied when code evolves; naming debt is not accumulated.
+
+## Related Skills
+
+- `skills/backend-engineer/SKILL.md`
+- `skills/code-review/SKILL.md`
+- `skills/backend-best-practices/references/refactoring.md`

package/framework/references/standards/observability.md

@@ -0,0 +1,43 @@
+# Observability Standard
+
+## Purpose
+
+Define reusable backend engineering rules for observability decisions across projects. This standard is canonical guidance for related skills.
+
+## Rules
+
+- Every service must expose three endpoint types: `/healthz` (liveness — is the process alive?), `/readyz` (readiness — can it serve traffic?), and `/metrics` (prometheus format).
+- Define at least one SLI per service dependency (latency, error rate, throughput, saturation) with an SLO target; record SLO compliance as a metric.
+- Every production alert must have a runbook link and be actionable; pages for symptoms, not causes, and must fire before the SLO burn rate violates the error budget.
+- Use three metric types: Counter (cumulative, only increases), Gauge (point-in-time value), Histogram (latency/size distributions with configurable buckets).
+- Trace every request from ingress to egress with OpenTelemetry; sample at head (consistent per trace_id) with a minimum 5% rate in production.
+
+## Best Practices
+
+- Keep metric cardinality bounded: label values must have a known, finite set (e.g., `status_code`, `endpoint`, `region`); never put user IDs, request IDs, or unbounded values in labels.
+- Build dashboards in tiers: Tier 1 (on-call, red/green, ~5 graphs), Tier 2 (team, weekly review, ~15 graphs), Tier 3 (deep-dive, ad-hoc).
+- Use RED metrics for request-driven services (Rate, Errors, Duration) and USE metrics for resources (Utilization, Saturation, Errors).
+- Set up synthetic probes from outside the cluster to measure real user-facing latency independently of internal metrics.
+- Conduct a quarterly SLO review: adjust targets, retire unused alerts, validate runbooks against actual incidents.
+
+## Anti-patterns
+
+- Alerting on every 5xx without aggregation or burn-rate logic; one noisy alert trains everyone to ignore it.
+- Dashboards with dozens of unrelated graphs that nobody looks at; prefer focused views owned by specific teams.
+- Adding high-cardinality labels (user_id, email, session_id) to metrics; use logging for individual entities, metrics for aggregates.
+- Deploying without metrics or tracing, then trying to add observability retroactively during an incident.
+- Using liveness probes that depend on downstream services; a failing database should cause readiness to fail, but the process should stay alive.
+
+## Checklist
+
+- [ ] `/healthz`, `/readyz`, and `/metrics` endpoints exist and are tested.
+- [ ] SLOs are defined per service dependency and recorded as metrics.
+- [ ] Alerts use burn-rate logic, have runbook links, and are pager-worthy.
+- [ ] Metric label cardinality is bounded and reviewed for explosion risk.
+- [ ] Distributed tracing is configured with consistent sampling across services.
+
+## Related Skills
+
+- `skills/backend-engineer/SKILL.md`
+- `skills/code-review/SKILL.md`
+- `skills/backend-best-practices/references/observability.md`

package/framework/references/standards/performance.md

@@ -0,0 +1,43 @@
+# Performance Standard
+
+## Purpose
+
+Define reusable backend engineering rules for performance decisions across projects. This standard is canonical guidance for related skills.
+
+## Rules
+
+- Every endpoint must have a latency budget (p50, p95, p99) documented before implementation; any change that exceeds the budget must be justified and approved.
+- Profile before optimizing: measure with production-representative load before any performance change; never optimize based on intuition alone.
+- Cache only when measured latency or load is unacceptable; document the cache key, TTL, invalidation strategy, and failure behavior (cache miss degrades to origin).
+- Prevent N+1 queries by eager-loading relationships; use batching for bulk operations; review all ORM-generated queries before shipping.
+- Use connection pooling for databases and HTTP clients; configure pool sizes based on measured concurrency, not defaults.
+
+## Best Practices
+
+- Load test every new endpoint against a production-sized dataset before shipping; include ramp-up, peak, and sustained load phases.
+- Choose caching layer by data characteristics: in-process for hot, rarely-changing data (config, feature flags); Redis/Memcached for shared, high-read data; CDN for static and cacheable API responses.
+- Use lazy loading sparingly and only when the optional data is rarely accessed; prefer explicit fetch methods (e.g., `loadUserWithOrders`) over transparent proxies.
+- Set read and write timeouts on every outbound call (HTTP, DB, queue, cache); a missing timeout is a production incident waiting to happen.
+- Batch database writes in transactions (not per-row inserts); prefer bulk insert/upsert operations where the API supports them.
+
+## Anti-patterns
+
+- Adding a cache before measuring the actual performance problem; caching adds complexity, staleness risks, and invalidation bugs.
+- Turning every field into a database index; indexes speed reads but slow writes and consume storage. Index based on query patterns, not speculation.
+- Using eager loading for every relationship "just in case"; load only the data the current code path needs.
+- Premature denormalization; normalize first, then denormalize only when profiling proves a performance need.
+- Synchronous in-process computation of expensive results that could be precomputed or cached.
+
+## Checklist
+
+- [ ] Latency budgets are defined for every endpoint before implementation.
+- [ ] Profiling data (not guesses) motivated each optimization decision.
+- [ ] Caching strategy is documented including key structure, TTL, and invalidation.
+- [ ] ORM queries are reviewed and no N+1 patterns exist.
+- [ ] Connection pools and timeouts are configured on all outbound clients.
+
+## Related Skills
+
+- `skills/backend-engineer/SKILL.md`
+- `skills/code-review/SKILL.md`
+- `skills/backend-best-practices/references/performance.md`

package/framework/references/standards/pull-requests.md

@@ -0,0 +1,43 @@
+# Pull Requests Standard
+
+## Purpose
+
+Define reusable backend engineering rules for pull request decisions across projects. This standard is canonical guidance for related skills.
+
+## Rules
+
+- PRs must be smaller than 400 lines of changed code (excluding generated files, lockfiles, and tests for the change); split larger changes into stacked or sequential PRs.
+- Branch names follow `<type>/<description>`: `feat/add-invoice-export`, `fix/null-pointer-on-login`, `refactor/order-service`, `chore/upgrade-go-1.21`.
+- Title must follow Conventional Commits: `type(scope): description` (e.g., `feat(payments): add idempotency key support`).
+- Description must include: what problem this solves, how it solves it, any breaking changes or migration steps, and links to related issues/ADRs.
+- Separate behavior changes from refactors into distinct commits within the same PR or into separate PRs; a single commit must not mix both.
+
+## Best Practices
+
+- Self-review your PR before requesting review: check for TODOs, debug code, missing error handling, and correct test coverage.
+- Request specific types of review: "focus on error handling in the payment flow" or "check the migration script for backward compatibility".
+- Blocking changes (API contract changes, schema migrations, security fixes) require two approvals; non-blocking changes require one.
+- Respond to every review comment; mark resolved discussions with a brief explanation of the resolution.
+- Squash-merge into the main branch, using the PR title as the commit message; preserve co-author attribution.
+
+## Anti-patterns
+
+- PRs that refactor a codebase while adding a feature in the same diff; they cannot be reviewed or reverted independently.
+- Review comments left unaddressed for more than 24 hours without communication; they block the author and the team.
+- Requesting review before CI passes; reviewers should not waste time on code that fails tests.
+- Leaving "LGTM" or approval without actually reading through the diff; code review catches bugs, not rubber stamps.
+- Merging PRs with failing CI or unresolved conversations; every merge commit to main must be green.
+
+## Checklist
+
+- [ ] PR is under 400 lines (excluding generated files and tests).
+- [ ] Title follows Conventional Commits format.
+- [ ] Description includes problem, solution, migration steps, and issue links.
+- [ ] CI is green before requesting review.
+- [ ] Refactors and behavior changes are in separate commits or PRs.
+
+## Related Skills
+
+- `skills/backend-engineer/SKILL.md`
+- `skills/code-review/SKILL.md`
+- `skills/pull-request/SKILL.md`

package/framework/references/standards/security.md

@@ -0,0 +1,43 @@
+# Security Standard
+
+## Purpose
+
+Define reusable backend engineering rules for security decisions across projects. This standard is canonical guidance for related skills.
+
+## Rules
+
+- Authenticate every request except explicitly public endpoints; use OAuth 2.0 / OpenID Connect with short-lived access tokens (15-60 min) and refresh tokens.
+- Authorize every action using RBAC or ABAC at the service layer, not just at the API gateway; enforce least privilege per operation.
+- Never store secrets (API keys, DB passwords, signing keys) in code, config files committed to git, or environment variables on shared infrastructure; use a secrets manager (Vault, AWS Secrets Manager, GCP Secret Manager).
+- Validate, sanitize, and type-check all input at the boundary; use an allowlist approach for permitted characters, values, and lengths where possible.
+- Encrypt all data in transit with TLS 1.2 minimum (prefer 1.3); encrypt all sensitive data at rest with AES-256 and envelope encryption.
+
+## Best Practices
+
+- Output-encode all dynamic data rendered in HTML, JSON, or XML context to prevent injection (XSS, SSTI, LDAP injection); use context-aware encoders.
+- Implement CSRF protection for cookie-authenticated endpoints; use SameSite=Strict cookies and CSRF tokens for state-changing operations.
+- Run dependency scanning (OWASP Dependency-Check, Snyk, Dependabot) on every commit; fix critical and high-severity vulnerabilities before merging.
+- Set security headers: `Content-Security-Policy`, `X-Content-Type-Options: nosniff`, `Strict-Transport-Security`, `X-Frame-Options: DENY`.
+- Log all authentication failures and authorization denials for audit; never store plaintext passwords — use bcrypt, Argon2, or PBKDF2 with a work factor.
+
+## Anti-patterns
+
+- Relying on client-side validation alone; all security controls must be enforced server-side.
+- Using JWTs without validating the signature, expiration (`exp`), issuer (`iss`), or audience (`aud`).
+- Returning stack traces or internal error details in API responses; use generic messages and log the details internally.
+- Hard-coded API keys or database passwords in any file, including test files and CI configuration.
+- Implementing custom cryptography; use well-audited, standard libraries (Tink, libsodium, JCA, Bouncy Castle).
+
+## Checklist
+
+- [ ] Authentication and authorization are enforced at the service layer, not just the gateway.
+- [ ] No secrets are in source code, config files, or CI variables; a secrets manager is used.
+- [ ] All inputs are validated and sanitized at the boundary.
+- [ ] TLS 1.2+ is enforced for all in-transit data; sensitive data at rest is AES-256 encrypted.
+- [ ] Dependency scanning is integrated into CI and critical/high findings are resolved before merge.
+
+## Related Skills
+
+- `skills/backend-engineer/SKILL.md`
+- `skills/code-review/SKILL.md`
+- `skills/backend-best-practices/references/security.md`

package/framework/references/standards/testing.md

@@ -0,0 +1,43 @@
+# Testing Standard
+
+## Purpose
+
+Define reusable backend engineering rules for testing decisions across projects. This standard is canonical guidance for related skills.
+
+## Rules
+
+- Unit tests cover domain logic in isolation: mock or stub every out-of-process dependency (database, network, filesystem); run in < 1ms per test.
+- Integration tests cover real adapter behavior: use test containers or ephemeral databases for repositories, message producers, and HTTP clients; run against a real instance.
+- Contract tests verify provider-consumer API agreements: use Pact or Spring Cloud Contract for producer-side; run in CI as a blocking check.
+- E2E tests cover critical user journeys only: happy path for the top 3-5 business flows; never attempt comprehensive e2e coverage.
+- All tests must be deterministic: no shared mutable state, no sleep/retry for timing, no dependency on test execution order.
+
+## Best Practices
+
+- Name tests following `Given_When_Then` or `UnitOfWork_StateUnderTest_ExpectedBehavior`: `GivenEmptyCart_WhenCheckout_ThrowsValidationError`.
+- Follow the Test Pyramid: 70% unit, 20% integration, 10% contract/e2e; CI must run unit and integration on every push, e2e on merge to main.
+- Use dependency injection to support test doubles at the port boundary; prefer fakes (in-memory implementations) over mocks for ports that have simple in-memory versions.
+- Write a test for every bug fix before applying the fix; the added test proves the bug exists and prevents regression.
+- Aim for > 80% line coverage on domain logic and > 60% on adapters; coverage is a floor, not a target — test for correctness, not percentages.
+
+## Anti-patterns
+
+- Testing framework internals (e.g., mocking the ORM and asserting SQL strings) instead of testing behavior through the public API.
+- Flaky tests that pass intermittently due to timing, ordering, or shared state; tag them and fix immediately or remove them — they erode trust in the suite entirely.
+- Writing e2e tests for every code path; e2e is for validation of critical flows only — most bugs are caught by unit and integration tests at a fraction of the cost.
+- Tests that share fixtures or database state across test files; each test must set up and tear down its own state.
+- Asserting implementation details (private methods, internal state) instead of observable behavior; tests should break when behavior changes, not when code is refactored.
+
+## Checklist
+
+- [ ] Unit tests isolate domain logic with mocked/stubbed dependencies.
+- [ ] Integration tests run against real infrastructure (test containers or ephemeral instances).
+- [ ] Contract tests exist for all provider-consumer API boundaries.
+- [ ] No flaky tests — verified by running the suite 10 times locally.
+- [ ] Coverage meets thresholds: >80% domain, >60% adapters.
+
+## Related Skills
+
+- `skills/backend-engineer/SKILL.md`
+- `skills/code-review/SKILL.md`
+- `skills/backend-best-practices/references/testing.md`

package/framework/references/templates/adr.md

@@ -0,0 +1,28 @@
+# Architecture Decision Record
+
+## Title
+Short decision title (e.g., "Use PostgreSQL for Order Storage")
+
+## Status
+Proposed | Accepted | Deprecated | Superseded
+
+## Context
+What is the problem, constraint, or opportunity? What forces are at play?
+
+## Decision
+What was decided? Be specific about the choice.
+
+## Consequences
+What becomes easier or harder? What tradeoffs were accepted?
+
+## Alternatives Considered
+| Option | Why rejected |
+| --- | --- |
+| Alternative A | Fails because... |
+| Alternative B | Fails because... |
+
+## Compliance
+How will adherence to this decision be verified?
+
+## Notes
+References, related ADRs, date, author.

package/framework/references/templates/api-spec.md

@@ -0,0 +1,56 @@
+# API Specification
+
+## Endpoint
+`<METHOD> /<path>`
+
+## Purpose
+What does this endpoint do in business terms?
+
+## Request
+
+### Headers
+| Header | Required | Description |
+| --- | --- | --- |
+
+### Path Parameters
+| Parameter | Type | Description |
+| --- | --- | --- |
+
+### Query Parameters
+| Parameter | Type | Required | Default | Description |
+| --- | --- | --- | --- | --- |
+
+### Body (for POST/PUT/PATCH)
+```json
+{ "example": "request body" }
+```
+
+### Authorization
+What auth method is required? What scopes or permissions?
+
+## Response
+
+### Status Codes
+| Code | Condition | Body shape |
+| --- | --- | --- |
+
+### Success Body
+```json
+{ "example": "response body" }
+```
+
+### Error Body
+```json
+{ "error": { "code": "...", "message": "...", "details": [...] } }
+```
+
+## Rate Limits
+Limit, window, retry-after header behavior.
+
+## Examples
+
+### Request
+
+### Response
+
+### Error

package/framework/references/templates/design-document.md

@@ -0,0 +1,39 @@
+# Design Document
+
+## Problem Statement
+What problem is being solved? What is the user-visible impact?
+
+## Scope
+In scope / out of scope.
+
+## Proposed Solution
+High-level approach with key design decisions.
+
+## Detailed Design
+
+### Data Model
+Entities, relationships, constraints.
+
+### API / Contracts
+Interfaces this component exposes or consumes.
+
+### Behavior
+Key algorithms, state machines, workflow steps.
+
+### Failure Handling
+What happens when each dependency fails?
+
+### Observability
+Logs, metrics, traces, alerts, dashboards.
+
+## Migration Plan
+Steps to go from current state to target state.
+
+## Rollback Plan
+How to revert at each stage.
+
+## Test Plan
+Unit, integration, contract, and E2E coverage.
+
+## Open Questions
+What is not yet decided?

package/framework/references/templates/incident-report.md

@@ -0,0 +1,38 @@
+# Incident Report
+
+## Severity
+Critical | Major | Minor
+
+## Duration
+Start: <datetime>  End: <datetime>  Total: <duration>
+
+## Detection
+How was the incident detected? Monitoring, alert, user report?
+
+## Timeline
+| Time | Event |
+| --- | --- |
+| HH:MM | What happened |
+| HH:MM | What was done |
+
+## Root Cause
+One paragraph describing the underlying cause.
+
+## Impact
+Users affected, data lost, revenue impact, SLA breach.
+
+## Response
+What was done to mitigate and resolve.
+
+## Lessons Learned
+
+### What went well
+
+### What went wrong
+
+### Where we got lucky
+
+## Action Items
+- [ ] Owner: Prevent recurrence (Specific change to prevent this root cause)
+- [ ] Owner: Improve detection (Monitoring, alert, or test that would catch this faster)
+- [ ] Owner: Improve response (Runbook, automation, or process change)

package/framework/references/templates/postmortem.md

@@ -0,0 +1,41 @@
+# Postmortem
+
+## Incident Summary
+One paragraph describing what happened and the impact.
+
+## Severity
+Critical | Major | Minor
+
+## Timeline
+| Time (UTC) | Event |
+| --- | --- |
+| | |
+
+## Detection
+How was this discovered? By whom? How long after introduction?
+
+## Root Cause Analysis
+
+### Trigger
+What event started the chain?
+
+### Contributing Factors
+What conditions made it possible?
+
+### Why Analysis
+1. Why did X happen? Because...
+2. Why did Y happen? Because...
+
+## Impact
+Metric changes, user impact, duration, cost.
+
+## Mitigation
+What was done to stop the incident? How long did it take?
+
+## Corrective Actions
+- [ ] Type: Short description (owner, tracking link)
+- [ ] Type: Short description (owner, tracking link)
+Types: Prevent recurrence | Improve detection | Improve mitigation | Process improvement
+
+## Appendix
+Links to dashboards, logs, PRs, related documents.

package/framework/references/templates/pull-request.md

@@ -0,0 +1,34 @@
+# Pull Request
+
+## Problem
+What does this change solve? Link to issue/ticket.
+
+## Solution
+High-level approach. What changed and why this approach was chosen.
+
+## Changes
+- `path/to/file`: what changed and why
+- `path/to/file`: what changed and why
+
+## Testing
+- [ ] Unit tests added/updated
+- [ ] Integration tests added/updated
+- [ ] Manual testing performed
+- [ ] Test evidence attached or linked
+
+## Risks
+- Migration: [yes/no] - [details]
+- Config change: [yes/no] - [details]
+- Breaking change: [yes/no] - [details]
+- Rollback complexity: [simple/complex]
+
+## Deployment
+- Feature flag: [yes/no - name]
+- Migration order: [what runs first]
+- Monitoring: [what to watch after deploy]
+
+## Rollback
+Steps to revert this change safely.
+
+## Reviewer Notes
+What the reviewer should focus on, what is intentionally out of scope.

package/framework/references/templates/runbook.md

@@ -0,0 +1,48 @@
+# Runbook
+
+## Service / Component
+Name and brief description.
+
+## Prerequisites
+Access, tools, credentials needed.
+
+## Normal Operations
+
+### Start / Restart
+Steps to start or restart the service.
+
+### Stop
+Steps to gracefully stop the service.
+
+### Health Check
+How to verify the service is healthy.
+
+## Diagnosis
+
+### Symptoms and Likely Causes
+| Symptom | Likely cause | Check |
+| --- | --- | --- |
+| | | |
+
+### Key Metrics and Logs
+What to check, where to find it, what is normal vs abnormal.
+
+### Debug Commands
+Useful commands for inspection.
+
+## Incident Response
+
+### Severity Levels
+What qualifies as what severity.
+
+### Mitigation Steps
+Ordered steps to reduce impact.
+
+### Escalation
+Who to contact and when.
+
+## Recovery
+Steps to restore normal operation after mitigation.
+
+## Appendix
+Links to dashboards, playbooks, design docs, team contacts.

package/framework/references/templates/task.md

@@ -0,0 +1,27 @@
+# Engineering Task
+
+## Goal
+What needs to be done in one sentence.
+
+## Context
+Why is this needed? What is the user or system impact?
+
+## Requirements
+- Functional requirement 1
+- Functional requirement 2
+- Non-functional requirement (performance, security, observability)
+
+## Out of Scope
+Work that is intentionally excluded.
+
+## Technical Notes
+Relevant architecture, existing code paths, data model details.
+
+## Verification
+How will this task be verified as complete?
+- Test criteria
+- Review criteria
+- Deployment criteria
+
+## Related
+Links to issues, PRs, docs, designs.