All authors
Claude Skills by HoangNguyen0403
github.com/HoangNguyen04031,434 skills30 installs1,975 views
- Common OwaspThis is a **P0 security misconfiguration** under OWASP **A05/API8**. `Access-Control-Allow-Origin: *` must not be used on authenticated routes. Remediate by: - Replacing `*` with an explicit origin allowlist, e.g. `https://app.example.com`. - Enabling `Access-Control-Allow-Credentials: true` only when required, never alongside `*`. - Keeping authentication and authorization enforced server-side; CORS is not an authorization control. - Using an opaque session securely or JWTs with an `exp` cla...Votes: 0GitHub stars: 549
- Common OwaspAssumption: Node.js + Express, bcrypt password hashes, and a server-side session store. ```ts import express from "express"; import cors from "cors"; import bcrypt from "bcrypt"; import rateLimit from "express-rate-limit"; const app = express(); app.use(express.json()); app.use(cors({ origin: ["https://app.example.com"], credentials: true, })); const loginRateLimit = rateLimit({ windowMs: 15 * 60 * 1000, limit: 10, standardHeaders: true, legacyHeaders: false, }); app.post("/login", loginRateL...Votes: 0GitHub stars: 549
- Common Pentest MethodologyObtain written authorization before testing and run all dynamic probes only against an agreed local or staging environment, never production. Record the test window, source IPs/devices, test accounts, data-handling rules, rate limits, and emergency stop contact. Use a grey-box approach where API documentation, mobile builds, test credentials, and architecture/dependency inventories are available. In scope are the API, authentication and authorization flows, API integrations used by the mobile apVotes: 0GitHub stars: 549
- Common Pentest MethodologyConfirm written authorization, the target domains and environments, test accounts, permitted test window, rate limits, data-handling rules, and exclusions. Direct all dynamic probes to local or staging systems; do not test production or third-party dependencies without explicit authorization. Define whether the assessment is black-box, grey-box, or white-box, and record browser versions, authenticated roles, feature flags, and build identifiers.Votes: 0GitHub stars: 549
- Common Performance EngineeringStart with a baseline: measure endpoint latency (including p50/p95/p99), database query count and duration, CPU, memory, and payload size for representative users and order counts. The observed bottleneck is an N+1 query pattern. Replace per-order product lookups with a bounded batch operation: 1. Fetch the user’s orders with pagination and a stable ordering. 2. Extract the distinct product IDs from those orders. 3. Fetch all required products in one query, for example `WHERE id IN (...)`, or...Votes: 0GitHub stars: 549
- Common Performance EngineeringFirst establish a baseline for the page: navigation-to-interactive and largest-contentful-paint timings, JavaScript and network waterfalls, CPU and memory profiles, bundle sizes, table-render time, and scroll/input latency. Test with the real 5000-row dataset on representative hardware and network conditions. The likely bottleneck is rendering and retaining 5000 rows during initial load. Virtualize the table so only the visible viewport plus a small overscan window is mounted. Prefer a table/...Votes: 0GitHub stars: 549
- Common Performance EngineeringDo not preemptively optimize every function. The performance standard requires a baseline and profiling before changes: measure relevant CPU, memory, latency, throughput, and I/O behavior, then identify the highest-impact bottleneck. Premature optimization spends complexity budget on code that may not matter and can introduce regressions. Use a lightweight prevention process instead: - Define SLIs/SLOs for critical paths, such as p95 latency, throughput, memory ceiling, startup time, or inter...Votes: 0GitHub stars: 549
- Common Product Requirements**Proposed file:** `docs/prd/prd-user-notifications.md` **Status:** Draft — pending product and business validation **Feature slug:** `user-notifications`Votes: 0GitHub stars: 549
- Common Product Requirements**Proposed file:** `docs/prd/prd-app-performance.md` **Feature status:** Draft — pending Discovery decisions **Linked BRD objective:** TBD **Product owner:** TBD **Engineering owner:** TBD **QA/release owner:** TBDVotes: 0GitHub stars: 549
- Common Product Requirements**Proposed file:** `docs/prd/prd-payment-checkout.md` **Slug:** `payment-checkout` **feature_status:** Draft — discovery assumptions require Product approval.Votes: 0GitHub stars: 549
- Common Product RequirementsCurrent status: `partial/unverified`. Existing code is implementation evidence only; without a PRD and acceptance criteria, it is not ready for product or QA sign-off. Assumptions: this is one feature, no linked BRD objective or business success metric is available, and ownership is TBD. Before approval, complete Discovery: 1. What outcome and BRD objective does this feature support? a) Revenue/conversion b) Retention/engagement c) Operational efficiency 2. Which channels are in scope? a) Web...Votes: 0GitHub stars: 549
- Common Product Requirements`feature_status: Discovery — not implementation-ready` Assumptions: the feature name, BRD objective, personas, business metric, and exact behavior are TBD. Planning covers web and mobile until the channel decision is confirmed. Offline behavior is assumed out of scope unless required.Votes: 0GitHub stars: 549
- Common Protocol EnforcementDo not mark the feature complete yet. Apply a fresh protocol check: 1. Confirm the active skills and project workflows were loaded before the implementation was written. 2. Perform an adversarial audit for standard defaults where project-specific rules should apply. 3. Inspect the current diff and the resulting file contents, then compare them with the active skill anti-patterns. Fix any violation immediately. 4. Run the relevant tests, checks, or validation commands against the current state...Votes: 0GitHub stars: 549
- Common Protocol EnforcementRun the self-scan against the current source and current diff; do not rely on memory or an earlier inspection. - Protocol state: verify the applicable skills and workflows were loaded before writing. - Adversarial audit: search for standard defaults where repository-specific rules should exist. - Diff/content audit: read the changed files immediately after the write and compare them with every active skill anti-pattern. - Execution-bias audit: look for local mocks instead of shared fakes, har...Votes: 0GitHub stars: 549
- Common Protocol EnforcementBefore marking a task complete, check all of the following: 1. Active skills and workflows were retrieved and loaded before any source was written. 2. An adversarial audit found no standard defaults where project rules should govern behavior. 3. The current diff and file contents were freshly read after the write and checked against the active skills' anti-patterns. 4. Relevant tests, linters, builds, or other validation were run on the current state, including meaningful edge or failure case...Votes: 0GitHub stars: 549
- Common Protocol EnforcementI cannot call it done without fresh verification. A tiny diff still requires the protocol: inspect the current diff and file contents, run the relevant validation, perform the adversarial and execution-bias audits, and confirm the concrete command or artifact that proves completion. Also verify the skills were loaded before writing. If the post-write scan finds an anti-pattern, fix it and repeat the checks. Only then can the task be marked complete.Votes: 0GitHub stars: 549
- Common Protocol EnforcementI cannot skip reopening the skill or checking the current diff. The protocol explicitly prohibits relying on memory: reload the source-of-truth skill and inspect the current files/diff. Then perform the adversarial audit, compare the post-write content with the active anti-patterns, and run fresh validation. Earlier inspection is stale evidence, and the task must not be called complete until the current checks pass.Votes: 0GitHub stars: 549
- Common Security AuditTreat this as a release gate, not just a grep exercise. The audit should produce evidence, owners, and remediation status for every finding.Votes: 0GitHub stars: 549
- Common Security AuditThis is a P0/critical finding. The skill assigns P0 to any hardcoded secret, and a database password can directly expose production data, enable modification or deletion, and permit lateral movement depending on the account privileges. The severity remains critical even if the file is not currently imported: it may exist in Git history, artifacts, logs, caches, or developer clones. Immediate actions: 1. Revoke and rotate the password now. Assume it is compromised; inspect database authenticat...Votes: 0GitHub stars: 549
- Common Security AuditIDOR is an authorization failure: the API accepts an object identifier supplied by one user and returns or changes an object that user is not entitled to access. Test every read, update, delete, download, export, and action endpoint—not only `GET` endpoints.Votes: 0GitHub stars: 549
- Common Security StandardsAssumption: the app uses TypeScript, a server-side API, PostgreSQL through an ORM, and browser sessions. Implement these endpoints: - `POST /auth/register` - `POST /auth/login` - `POST /auth/logout` - `GET /auth/me` - `POST /auth/mfa/verify` Store only the minimum required fields: ```prisma model User { id String @id @default(uuid()) email String @unique passwordHash String mfaRequired Boolean @default(true) createdAt DateTime @default(now()) } model Session { id ...Votes: 0GitHub stars: 549
- Common Security StandardsAssumption: your application receives PII through APIs, processes it in an application service, and must later decrypt it for authorized use. Implement this flow: 1. Validate and sanitize PII at every trust boundary: API, UI, CSV, and webhook. 2. Encrypt PII in the application before persistence using authenticated AES-256 encryption, preferably AES-256-GCM. 3. Store encryption keys only in a secret manager or environment-backed key-management system—never hardcode or commit them. 4. Use TLS ...Votes: 0GitHub stars: 549
- Common Security StandardsThe code is vulnerable to SQL injection because untrusted `userName` is concatenated into a raw SQL string. It also omits quotes around the value. Use a parameterized query or ORM instead: ```js const result = await db.query( 'SELECT * FROM users WHERE name = $1', [userName] ); ``` For drivers using `?` placeholders: ```js const result = await db.query( 'SELECT * FROM users WHERE name = ?', [userName] ); ``` Also: - Treat `userName` as untrusted at the API/UI boundary; validate expected type,...Votes: 0GitHub stars: 549
- Common Session RetrospectiveCorrection count: 3, based on your report. The individual correction moments are unavailable, so exact specifics cannot be cited. - Root causes: undetermined among Skill Missing, Incomplete, Example Contradicts Rule, Workflow Gap, or Trigger Miss. - Skills changed: none; repository maintenance was not explicitly authorized. - Trigger misses: undetermined. Each requires the skill ID, indirect phrase, and a targeted trigger-keyword fix. - Learning log: `AGENTS_LEARNING.md` was not modified. Wit...Votes: 0GitHub stars: 549
- Common Session RetrospectiveAssuming the missed skill is `common-security-standards`, add these trigger keywords: ```yaml keywords: - api endpoint - api endpoints - endpoint - rest api - http handler - route - controller - middleware - authentication - authorization - input validation - request validation - security ``` Trigger miss: - Skill: `common-security-standards` - Indirect phrase: “writing API endpoints” - Fix: add API/route/controller aliases to the skill’s keyword triggers. Apply the change across configured a...Votes: 0GitHub stars: 549
- Common Session RetrospectiveSession retrospective: - Correction loops: 0 - Root causes: none identified - Trigger misses: none detected - Skills changed: none - `AGENTS.md`: no update warranted - `AGENTS_LEARNING.md`: no entry appended because no correction loop occurred - Estimated rounds saved: 0 Assumption: no additional session feedback was supplied beyond this request. Future feedback should record the exact correction, classify it as Skill Missing, Incomplete, Example Contradicts Rule, Workflow Gap, or Trigger Mis...Votes: 0GitHub stars: 549
- Common Skill CreatorCreate a compact skill with frontmatter using a precise What + When description. Cover NestJS GraphQL subscription resolvers, WebSocket transport, typed async iterators, PubSub topic ownership, connection authentication, subscription-time authorization, tenant isolation, event publication after commit, unsubscribe/disconnect cleanup, multi-instance broker choice, observability, and integrated transport tests. Use surgical triggers such as `*.resolver.ts`, `graphql subscriptions`, `PubSub`, an...Votes: 0GitHub stars: 549
- Common Skill CreatorAudit result: structural failure. - 150 lines exceeds the 100-line body limit; compress repeated prose and move detailed material to `references/`. - A 20-line code block violates progressive disclosure; extract it to a focused reference and leave a short link or invocation. - Keep frontmatter under 100 words with third-person What + When capabilities and surgical triggers. - Remove generic explanations, duplicated frontmatter, and untested guardrails; preserve only project-specific, actionab...Votes: 0GitHub stars: 549
- Common Skill CreatorA 40% trigger rate is below the ≥80% target (the checklist targets ≥90% activation). Treat it as an activation-evaluation problem. 1. Rewrite the description as third-person What + When: name 5–8 concrete capabilities, user phrases, file types, and artifacts; keep it under 100 words. 2. Build labeled should-trigger and should-not-trigger queries covering direct terms, synonyms, abbreviations, file cues, and adjacent domains. 3. Run the trigger evaluation and inspect false negatives and false ...Votes: 0GitHub stars: 549
- Common Skill CreatorDo not skip the baseline. The standard requires a with-skill versus without-skill comparison for new skills, and pressure hardening requires evidence rather than intuition. Even a “simple” skill needs intent capture, activation description, implementation rules, baseline and with-skill runs, comparison of assertions/tokens/time, and iteration on observed failures. For discipline skills, record rationalizations, red flags, stop conditions, and behavior assertions in evals. If time is constrain...Votes: 0GitHub stars: 549
- Common Skill CreatorDo not skip trigger testing. A good-sounding description is not evidence; the standard requires ≥80% trigger rate and the checklist targets ≥90% activation. Create should-trigger and should-not-trigger queries with synonyms, abbreviations, adjacent domains, and file/keyword cues. Run the evaluation, inspect false positives and negatives, revise the What + When description with surgical triggers, and rerun until the measured result meets target without unacceptable over-triggering. Record the ...Votes: 0GitHub stars: 549
- Common Software Requirements**Status:** Draft **Owner:** Checkout Platform **Scope:** Prevent duplicate checkout side effects while allowing safe retries after transient failures. No linked BRD, PRD `REQ-*`, or `AC-*` identifiers were supplied; the trace entries below are therefore explicit placeholders and require product confirmation before approval.Votes: 0GitHub stars: 549
- Common Software Requirements**Status:** Draft **Scope:** Make synchronous API calls and asynchronous event delivery resilient to transient failure while preserving ordering, deduplication, and observability. No source PRD or acceptance criteria were provided, so `BRD-OBJ-TBD`, `REQ-TBD`, and `AC-TBD` must be replaced before approval.Votes: 0GitHub stars: 549
- Common Software RequirementsBlocked. The request asks for technical implementation design, but the PRD has no `AC-*` IDs. Under the software-requirements standard, implementation scope must not be inferred from code or invented from an underspecified product request.Votes: 0GitHub stars: 549
- Common Store ChangelogWhat's New in Version 2.5 • Search hands-free with the new voice input option. • Scrolling through your timeline is now smoother and faster. • Fixed a login issue that could unexpectedly sign you out on iOS 17. • Added dark-mode support to the settings screen.Votes: 0GitHub stars: 549
- Common Store Changelog• Search hands-free with new voice input. • Enjoy smoother, faster timeline scrolling. • Stay signed in more reliably on iOS 17. • Use dark mode in Settings.Votes: 0GitHub stars: 549
- Common Store Changelog• Fixed incorrect cart totals when discounts are applied. • Save your delivery address for faster repeat checkout. • Fixed avatar loading for users on slow connections.Votes: 0GitHub stars: 549
- Common Store Changelog• Get started faster with the new onboarding flow. • Fixed a camera crash affecting some Android 14 users. • Reduced battery use during background sync.Votes: 0GitHub stars: 549
- Common System DesignCommon anti-patterns in system design usually come from blurred boundaries, hidden coupling, and failure-unaware integrations. The first anti-pattern is the god class or god module. This happens when one service or component owns too many responsibilities such as validation, orchestration, persistence, and external integrations all at once. It becomes hard to test, hard to change safely, and impossible to scale selectively. Another major anti-pattern is tight synchronous coupling between serv...Votes: 0GitHub stars: 549
- Common System DesignHere is a quick-start example for common system design using a simple order-processing feature. Suppose a user places an order in an e-commerce system. A clean starting design is: - `OrderController`: accepts the HTTP request and validates the transport shape - `PlaceOrderUseCase`: contains the business workflow - `OrderRepository`: interface for saving orders - `PaymentGateway`: interface for charging payment - `InventoryService`: interface for reserving stock - `OrderRepositoryImpl`, `Strip...Votes: 0GitHub stars: 549
- Common TddUnder strict TDD, the correct sequence is Red-Green-Refactor: 1. Red: write a minimal failing test for a valid email such as `user@example.com` and confirm it fails for the expected reason, not because of a typo or missing setup. 2. Green: implement the smallest possible `isValidEmail(email)` logic needed to make that single test pass. 3. Refactor: clean up naming or parsing logic while keeping the tests green. 4. Repeat with additional failing tests for invalid inputs like missing `@`, missi...Votes: 0GitHub stars: 549
- Common TddThis does not comply with TDD as stated. If the implementation already exists and the plan is to add tests afterward for coverage, the skill requires stopping and resetting to a Red-Green-Refactor flow. Correct response under this skill: - Do not treat post-implementation coverage work as TDD. - If the new code was written before a failing test, that code should not be considered valid TDD evidence. - Reconstruct the work by defining the expected behavior in a failing test first. - Verify the...Votes: 0GitHub stars: 549
- Common TddUse a four-test TDD sequence for the order service, with one behavior per test and AAA structure in each case. Recommended order: 1. Happy path first - Arrange: create a valid order request, stub dependencies that must succeed, and define the expected created order result. - Act: call the order service method once. - Assert: verify the returned order is created correctly and the expected side effects occur. 2. Error scenario: inventory unavailable - Arrange: valid request, but inventory depen...Votes: 0GitHub stars: 549
- Common TddNo. Urgency and size do not waive the TDD rule. If the fix was written before the failing test, the skill treats that as a stop condition. The compliant response is: - stop, - discard the assumption that “tests after” is acceptable, - write the smallest failing test that exposes the bug, - verify the failure is real and expected, - re-implement the minimal fix to make that test pass, - refactor only while the suite stays green. The reason is simple: adding tests after the code may document th...Votes: 0GitHub stars: 549
- Common TddNo. Manual browser testing does not replace the Red step. Under this skill, verification requires a failing automated test first, because manual testing cannot reliably prove that: - the intended behavior was encoded before implementation, - the failure condition is reproducible, - the regression will be caught again later, - the check can run consistently in CI. The correct TDD path is to express the endpoint behavior in an automated failing test, confirm the failure is for the expected reas...Votes: 0GitHub stars: 549
- Common TelemetryCall `get_session_cost` before the final handoff, passing workflow, model, token/cache/reasoning usage, and rates when available. Then append the usage metrics as a Markdown table to `artifacts/session-cost.md`; if token counts are unavailable, record MCP-observed telemetry and mark model-token cost unavailable.Votes: 0GitHub stars: 549
- Common TelemetryRecord session cost metrics in `artifacts/session-cost.md`, using `get_session_cost` to collect the telemetry first.Votes: 0GitHub stars: 549
- Common Ui DesignAssumptions: the SaaS product is named “Orbit,” targets operations teams, and needs a responsive single-page landing page. The chosen aesthetic is retro-futuristic: deep navy, electric lime, distinctive typography, and an orbital command-surface visual that users will remember. ```html <!doctype html> <html lang="en"> <head> <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> <title>Orbit — Your business, in motion</title> <style> @import url("htt...Votes: 0GitHub stars: 549
- Common Ui DesignAssumption: Next.js App Router with React and CSS Modules. The dashboard serves an operations team tracking growth, conversion, and channel performance. Design direction: - Purpose: provide a fast daily view of business health and anomalies. - Tone: industrial/utilitarian, dark, dense, and precise. - Differentiation: an acid-lime “signal rail” that highlights the most important metric. - Typography: Space Grotesk for display text and IBM Plex Sans for readable data labels. `app/dashboard/page...Votes: 0GitHub stars: 549
- Common Ui DesignAgreed. I’ll move away from the generic AI aesthetic and commit to an editorial/magazine direction. Assumption: this is an AI product interface intended to feel thoughtful, premium, and opinionated. - **Color:** deep ink background (`#111313`) with warm paper panels (`#F1EBDD`), vermilion accent (`#E65336`), and acid-lime highlights (`#C7F36B`). Define them as `--color-primary` and `--color-accent`. - **Typography:** use a distinctive display serif such as `DM Serif Display` paired with `IBM ...Votes: 0GitHub stars: 549