NamHT4Devlop
UserMOVED → github.com/NamHT4Devlop/claude-code-workflow-kit (same code, new name). This repo is kept for existing clones.
Categories
Indexed Skills (30)
namht-ask
Answer natural-language questions about a codebase grounded in the Knowledge Base (business meaning) and real source (technical detail) — never invented — for a mixed business+technical audience: a plain-language explanation, a fitting Mermaid diagram, and the precise technical detail with real file/field/endpoint citations. Use when the user asks "/ask", "how does X work", "which module handles Y", "where is Z implemented", or any Q&A about the project.
namht-build
Implement a feature or change end-to-end with a disciplined spec-driven pipeline: clarify → size → plan (impact + business flow) → safety net → generate code → independent multi-lens review → tests (incl. regression) → verify against a baseline → evidence report → update the Knowledge Base → hand off. Use when the user asks to "build", "implement", "add a feature", "/build", or wants a production-ready change that respects the existing architecture and business rules. Reads the repo's knowledge-base/ for grounding.
namht-design-review
Review UI/UX, visual quality and accessibility of a running app (via browser screenshots) or frontend components — catches "AI slop" (generic/inconsistent UI), spacing/alignment/hierarchy issues, responsive breakage, and a11y problems (contrast, alt, labels, keyboard, ARIA) against the project's design system if documented. Use when the user says "/design-review", "review the UI/design", "is this UI good", "check accessibility", "design QA". Read-only.
namht-document
Write a precise technical document for a feature, entity, or module that maps BUSINESS concepts to CODE at the field level — business overview, a field-by-field business↔code mapping table, business flows mapped to functions, business rules with enforcement locations, API/entry points, and assumptions/gaps — grounded in the Knowledge Base and real source, written so BOTH a non-technical reader and an engineer understand it (plain-language summary + glossary + precise technical tables). Use when the user asks to "/document", "write a doc for X", "document the Y module", or wants business↔code documentation anyone can follow.
namht-drift
Audit the whole repo for DRIFT between what the documents claim and what the code actually does — stale or wrong Knowledge Base entries, code that no document describes, acceptance criteria from past stories/plans that were never implemented, and violations of the documented architecture invariants. Read-only: produces a ranked drift report with an owner and a fix route for every item. Use when the user says "/drift", "converge", "is the KB still accurate", "what's out of sync", "what did we plan but never build", "audit docs vs code", or before a release / after a long stretch of unreviewed work.
namht-fix-bug
Diagnose and fix a bug from a symptom OR a QA bug report (expected-vs-actual, repro steps, the environment, a failing test case / acceptance criterion): TRIAGE whether it's really a code defect (vs a config / env-var / data / migration / feature-flag / deploy-skew / spec-ambiguity issue), reproduce (environment-aware), find the ROOT CAUSE, assess blast radius, write a failing regression test tied to the broken AC, apply a minimal surgical fix, verify (tests + build) with rollback, and produce a hotfix report — then close the loop back to QA. Use when the user says "fix bug", "QA found a bug", "bug on staging/prod", "hotfix", "/fix-bug", "this is erroring", "incident", or pastes an error / a failing test case.
namht-issues
Turn a plan or a set of user stories into real tracker issues — GitHub issues via the gh CLI, or Jira/Linear through a connected MCP — one issue per story with its acceptance criteria as a checklist, parent/child links, labels and estimates. Previews everything and requires an explicit yes before creating anything; re-running updates instead of duplicating. Use when the user says "/issues", "create tickets from this plan", "push the stories to GitHub/Jira", "turn the user stories into issues", or "sync the backlog".
namht-map
Generate an INTERACTIVE HTML dependency graph of a codebase (Cytoscape.js) — nodes are files/classes/routes, edges are real imports, dependency injection, inheritance (extends/implements) and method calls, colored by architecture layer, with zoom/pan, click-to-highlight-neighbors, search, layer filters and hub highlighting. Opens in the browser. Use when the user asks to "/map", "map the codebase", "show the dependency graph", "code graph", or "visualize architecture".
namht-migrate
Change a shared contract without breaking anyone — an API field/endpoint, a DB schema (Flyway/ActiveRecord), an SQS/event message shape, or a library version. Uses the parallel-change (expand → migrate → contract) pattern with a rollback per step and a deprecation window, and finds every consumer across services first. Use when the user says "/migrate", "deprecate X", "schema change", "breaking change", "version bump", "upgrade <lib>". Edits code — change-discipline applies.
namht-observe
Make a service answerable in production — add structured logging, a correlation ID that flows across HTTP and SQS, the four golden signals as metrics, and error context rich enough to group by. Emits fields that match the team's Splunk schema so queries and dashboards actually work. Use when the user says "/observe", "add logging", "instrument this", "add metrics/tracing", "structured logs", or wants a service to be queryable/monitorable. Edits code — change-discipline applies.
namht-pdf
Export a report to PDF — take a Markdown or HTML file (e.g. a namht Kit report/doc under namht-sessions/, or any .md) and produce a PDF, rendering Markdown + Mermaid first if needed. Use when the user says "/pdf", "export to PDF", "make a PDF", "save this as PDF", "PDF the report/doc".
namht-perf
Make it faster on evidence, not hunches — measure the baseline, fix the single biggest bottleneck, re-measure to prove the win. Targets N+1 queries, missing indexes and full scans, over-fetching, blocking/sequential calls, chatty service hops, and missing caching or pagination. Use when the user says "/perf", "optimize performance", "this is slow", "N+1", "reduce latency", or "high memory/CPU". Edits code — change-discipline applies.
namht-plan-review
Critique an implementation plan or user-story plan BEFORE building, through multiple lenses — Product (right thing? simpler? scope creep), Architecture/Eng (fits existing patterns, blast radius, risk), Risk/QA (what breaks, regression, edge cases), DevEx (complexity, maintainability) — grounded in the KB, ending with a verdict (proceed / revise) + concrete fixes. Use when the user says "/plan-review", "review this plan", "is this plan good", or after /namht-plan.
namht-plan
Act as a Product Owner / Business Analyst — turn an Epic (title + description) into Features → per-feature Impact Analysis (old flow ↔ new flow) → a stakeholder Confirmation Checklist → User Stories with Given/When/Then acceptance criteria and story points → a Sprint Plan, grounded in the Knowledge Base, with a plain-language executive summary so non-technical stakeholders and the dev team both follow it. Use when the user asks to "/plan", "plan user stories", "break down this epic", or wants PO/BA artifacts.
namht-pr
Prepare or review a Pull Request. PREPARE mode: from the current branch's diff + commits, draft a PR title and description (what/why, changes, risk + blast radius, tests done, checklist). REVIEW mode: given a PR number/URL, pull its diff (gh pr diff) and run a two-phase review (quality checklist + business consistency vs KB) with blast-radius (callers) analysis. Use when the user says "/pr", "prepare a PR", "write PR description", "review PR 123", "review this pull request". Does not push/merge.
namht-qa-integration
EXECUTE integration / end-to-end QA against a RUNNING app via a real browser: take test cases (from /namht-qa) or a user story + a URL, drive the browser (navigate, log in, fill, click), assert expected results from the DOM/screenshots, run both the new-flow and regression cases, and produce a pass/fail report with screenshots. Use when the user says "/qa-integration", "run QA on <url>", "test the app live", "e2e test", "integration test against staging". Needs a browser.
namht-qa
Turn a user story (role/action/benefit + acceptance criteria) into a complete QA test plan: derive test cases for the NEW flow (happy/alternate/error/edge/ negative/permission/state) AND regression cases for the EXISTING (old) business flows the change touches — grounded in the Knowledge Base — with a traceability matrix (AC ↔ case ↔ flow), Gherkin + a manual test-case table. Use when QA receives a story and needs test cases, or the user says "/qa", "write test cases", "test plan", "QA for this story", "cover old and new flow".
namht-rails-to-spring
Port a service (or a chosen set of endpoints) from one language/stack to another while PRESERVING its contract and business behavior — e.g. Ruby on Rails + GraphQL → Java Spring Boot. Contract-first and parity-verified: freeze the contract, extract the business behavior from the source with parallel multi-lens agents, capture golden/shadow tests of the real responses, re-implement on the target stack, and prove byte-for-byte parity with an INDEPENDENT reviewer before cutover — endpoint by endpoint (strangler). Use when the user says "/port", "migrate to another language", "rewrite in <language>", "Rails to Spring", "port these resolvers/APIs". Edits code — change discipline applies.
namht-rescan
Incrementally update an existing Knowledge Base after code changes — re-analyze only what changed (via git diff) and refresh the affected knowledge-base/ docs, modules, and Section 14 review rules, instead of regenerating everything. Use when the user asks to "rescan", "/rescan", "update the KB", or "refresh the knowledge base after my changes".
namht-retro
Run an engineering retrospective over a time window from git history (read-only): what shipped, recurring themes/pain, what went well vs poorly, risk/quality signals, and concrete action items for next period. Use when the user says "/retro", "weekly retro", "what did we ship", "retrospective", "sprint review".
namht-review
Review a file or a diff in two phases — code quality against a comprehensive universal checklist (architecture, security, error handling, performance, observability, testing, data integrity, API design, code quality) AND business consistency against the project's Knowledge Base (business rules intact, no logic removed, valid state transitions, API contract preserved). Use when the user asks to "review", "/review", "check this file", or audit a change.
namht-runbook
Produce an operational runbook a teammate can follow at 2am — health checks, deploy and rollback, symptom→diagnosis→fix playbooks for the failures this system actually has, alert-to-action mapping, data recovery (migrations, DLQ replay), and escalation. Grounded in the Knowledge Base, the real deploy/CI config and the error handling in the code; anything only a human knows is marked as a gap, never invented. Use when the user says "/runbook", "make a runbook", "on-call guide", "operations doc", "what do we do when X breaks", or wants the KB turned into something the team can operate from.
namht-scan
Generate a deep, business-aware Knowledge Base for a codebase by analyzing it into 16 structured docs (structure, tech stack, entry points, business domain, domain model, modules, architecture, database, auth, core flows, API, conventions, business rules, integrations, errors, architecture patterns) plus a review-skills.md and per-module docs. Use when the user asks to "scan", "/scan", "generate KB", "build a knowledge base", or onboard onto a new repo.
namht-security-audit
Run a whole-repo security audit: sweep the codebase for vulnerabilities by category (input validation, injection, broken authn/authz & IDOR, secrets & crypto, sensitive-data exposure, dependency risk, and AI/LLM-specific issues), grounded in the project's review-skills checklist + auth model (KB) + the code (entry points = attack surface, blast radius). Use when the user says "/security-audit", "security review of the repo", "find vulnerabilities", "OWASP audit", "is this secure", or before a release/pentest. Read-only.
namht-simplify
Make existing code easier to read and change WITHOUT changing what it does — guarded by tests, one small refactor at a time. Removes dead code, flattens nesting, extracts and renames for intent, kills duplication, and deletes needless abstraction. Use when the user says "/simplify", "refactor for clarity", "reduce complexity", "clean up this code", or "this is too complex". Edits code — change-discipline applies. Behavior must not change.
namht-skillify
Scaffold a NEW namht-* skill (and its command) from a description, following this toolkit's conventions, so the user can self-extend the kit. Use when the user says "/skillify", "create a new skill", "add a skill for X", "turn this workflow into a skill", "make a command for …".
namht-splunk-report
Query Splunk for errors/exceptions per app over a time window (default: today), aggregate the findings into one table (app · total · top error · severity), and post it to a Slack channel. Use when the user says "/splunk-report", "splunk error report", "daily error digest", "query splunk errors and send to slack", or wants a per-app error summary from Splunk for the day.
namht-system-map
Build a SYSTEM-LEVEL map across multiple microservice repos in one workspace folder: discover the services, stitch each service's exposed endpoints (KB 11-api-docs) to the others' outbound calls (KB 14-integrations) into a cross-service dependency graph, trace END-TO-END business flows that span services (with sequence diagrams), and catalog shared events/contracts + risks. Use when the user asks to "/system-map", "map the microservices", "end-to-end flow across services", "how do the services call each other", or works in a folder containing several service repos that call each other.
namht-user-story
Deeply investigate a requirement — typed by the user, OR reconstructed by COMPREHENDING a Slack thread they point to (decision timeline, participants/authority, reactions, linked canvases/files — not just reading messages) — then write Agile features and INVEST user stories in exhaustive detail: role/action/ benefit, and MAXIMALLY GRANULAR Given/When/Then acceptance criteria (one atomic, testable assertion per AC, with concrete values), plus story points, priority, dependencies and assumptions, grounded in a real investigation of the Knowledge Base and source. Use when the user says "/user-story", "create user stories", "write detailed stories/ACs", "turn this Slack thread into stories", or pastes a requirement or a Slack link.
namht-discover
Product/requirement discovery BEFORE planning — interrogate a fuzzy idea with forcing questions (who has the pain, a concrete real example, the smallest valuable version, what's explicitly out, the success metric, what existing flow/data it touches), push back on weak framing, and output a SHARPENED problem statement + scope + success criteria ready for /namht-plan. Use when the user says "/discover", "office hours", "I want to build…", or brings a vague idea.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.