All authors
Claude Skills by lamngockhuong
github.com/lamngockhuong28 skills0 installs0 views
- Security ReviewComprehensive security review for Termote. Use when reviewing PRs, auditing code, or before releases. Covers auth bypass, request guards (Host/Origin/Content-Type), terminal WebSocket stream, child-process lifetime, command/argument injection (tmux, psmux, herdr), the Go CLI (install layout, saved config, update, service registration, process kill) and container setup.Votes: 0GitHub stars: 57
- BreakdownBreak an epic or a design document into owned, sequenced tasks: one deliverable each, an owner, a dependency order, the parallel lanes that avoid two people editing the same file, and a definition of done per task. Use before a sprint starts, when work has to be shared across several developers, or when a piece of work needs owners and parallel lanes. Work that stays with one person is planned with `atk:plan` instead, however many days it takes. Triggers on: "break down", "breakdown", "chia t...Votes: 0GitHub stars: 8
- CatchupSummarise an epic or a pull request for someone who was not in the conversation that produced it: what the work is and for whom, why now, what is in and out of scope, what the work touches and where each unit sits in the code, who decides, the unfamiliar terms, and where it is easy to go wrong. For an epic it also produces the understanding check the developer answers before writing any code. Use when a person joins work already in flight, picks up an epic they did not help write, or has to r...Votes: 0GitHub stars: 8
- ConventionExtract, record, and enforce the coding conventions a team actually follows: branch and commit rules, naming, layering, error handling, test layout, review etiquette, and the tooling that enforces each rule. Also drafts the collaboration files the project lacks, `CONTRIBUTING.md`, the pull request template, and `CODEOWNERS`, writing only the ones the team picks. Use when a team has no written convention, when the written one no longer matches the code, or when reviews keep repeating the same ...Votes: 0GitHub stars: 8
- Design DocWrite the technical design document a team reviews before coding, plus the ADR that records the decision behind it: current state, options with trade-offs, chosen approach, data and API changes, migration and rollback, risks, and the reviewers who must sign off. Use before implementing anything that touches a schema, a public contract, a shared module, or more than one service. With `--spike`, runs a time-boxed investigation first, for a design that cannot choose until a question is answered....Votes: 0GitHub stars: 8
- EstimateEstimate a backlog and fill a sprint against real team capacity: size each item with a stated basis, mark the confidence, add the risk buffer, subtract leave and meetings, and produce a sprint commitment the team can defend in planning. Use for story points, man-day estimates, sprint planning, capacity checks, and re-estimation after scope change. Triggers on: "estimate", "estimation", "story point", "man-day", "ước lượng", "estimate sprint", "sprint planning", "capacity", "見積", "工数", "how lo...Votes: 0GitHub stars: 8
- FixFix a defect the way a team reviewer will accept: capture the failure verbatim, prove the cause before changing a line, check that the current behaviour is not a decision somebody made on purpose, make the smallest change that removes the cause, verify it by layer, stop after three ruled-out hypotheses with a named person rather than guessing, and write the report that shows what was checked and what was not. Use for a bug report, a failing test, a broken endpoint or screen, or an investigati...Votes: 0GitHub stars: 8
- GitCarry a finished piece of work into version control: read what changed, stage it after scanning for anything that must never be committed, split it into commits that can be reverted one at a time, branch and push on consent, open the pull request with the artifact as its body, and merge only when a person asks for that merge and the pull request is ready. Also repairs a branch, through rebase, conflict resolution and fixup, and drives stacked pull requests. Use after a skill or a person has f...Votes: 0GitHub stars: 8
- HandoverHand work over to another person or team so nothing depends on the leaver's memory: the true state of each item, decisions and why they were made, the traps, the credentials and access to transfer, the contacts, and the questions only the leaver can answer, asked before they go. Use when a member leaves or rotates, when a phase ends, at a vendor-to-client handover, or before a long absence. Triggers on: "handover", "hand over", "bàn giao", "chuyển giao công việc", "takeover", "leaving", "引き継ぎ...Votes: 0GitHub stars: 8
- HelpAnswer which atk skill to run. With no argument it reads the state of the project, meaning the profile, the artifacts on disk and their approval state, the plans, and the branch, then names the next skill with the line to type, the evidence behind it, what the skill needs first, and who approves what it produces, plus what is waiting on which person. Given a question or a situation it routes it to one skill; given a skill name it explains that skill. Use when someone asks which skill fits, wh...Votes: 0GitHub stars: 8
- ImplementWrite the code for a piece of work the way a team will accept it: decide whether the work needs a plan before a line is written, follow the project's own conventions and reference modules, verify by layer with the project's own commands, then call the team review and fix what it blocks on before handing the change over. Use when a ticket, a plan, or a described requirement is ready to be built, and the question left is how to build it rather than what to build. Triggers on: "implement", "code...Votes: 0GitHub stars: 8
- IncidentRun a production incident and close it properly: a timeline built from evidence, impact and severity, the proven root cause, the mitigation actually applied, a blameless postmortem, follow-up actions with owners and dates, and the runbook that makes the next occurrence shorter. Use during an outage, after one, or when writing the runbook for a recurring failure. Triggers on: "incident", "outage", "sự cố", "postmortem", "RCA", "root cause", "production down", "障害", "障害報告", "hotfix", "runbook",...Votes: 0GitHub stars: 8
- InitSet up atk in a project: read the repository to find the build, test, and lint commands, the layer layout, the tracker, and the docs root, confirm what was found, ask only for what no file can answer, and write the profile every other skill reads. Use once when a team first installs atk in a project, and again when the project has moved on from what the profile says. Triggers on: "init", "atk init", "setup atk", "khởi tạo", "cấu hình dự án", "thiết lập atk", "初期設定", "セットアップ", "プロジェクト設定", "get...Votes: 0GitHub stars: 8
- IntakeTurn a raw stakeholder or client request into reviewable requirements: context, user stories, acceptance criteria, out-of-scope list, open questions, and the person who must answer each one. Use when a request arrives as a chat message, a meeting note, a mail, a one-line ticket, or a Figma design, and the team cannot start work from it yet. Triggers on: "intake", "requirement", "làm rõ yêu cầu", "phân tích yêu cầu", "user story", "acceptance criteria", "要件定義", "要求整理", "clarify this request", ...Votes: 0GitHub stars: 8
- OnboardOnboard a new member onto a project team: the access list, the environment setup verified by a command that actually runs, a map of the codebase by ownership, the team's working agreements, and a first-week plan ending in a real contribution the team reviews. Use when someone joins the project, moves between teams, or returns after a long absence. Triggers on: "onboarding", "onboard", "người mới", "hướng dẫn thành viên mới", "new joiner", "getting started for the team", "オンボーディング", "新メンバー", "...Votes: 0GitHub stars: 8
- PlanTurn a piece of work into phases and steps: today's code with file paths, phases that each end in something reviewable, steps that leave the tree working and how each is checked, what is out of scope, and what is unclear with who must answer. Also reviews a written plan against the repository and the request, challenges it with one agent per way it can fail, and records the answers to its open questions. Use before starting work, on work somebody else designed, when work needs stages but one ...Votes: 0GitHub stars: 8
- QaPlan and write the team's testing: a test plan with scope and exit criteria, test cases traced to acceptance criteria, a regression matrix, test data and environment needs, and the handoff a developer owes QA. Afterwards, records a test run, raises its failed cases as bugs, and records the retest of a fixed bug. Also brings existing cases level with a changed spec. Use when a feature reaches QA, when a release needs a regression pass, when a team has no written test cases, when the spec chang...Votes: 0GitHub stars: 8
- ReleaseRun a team release: assemble the change list from the diff, write release notes for the audience that reads them, produce the pre-flight and post-deploy checklist with an owner per step, state the rollback path, and record who approved the go decision. Use before deploying to staging or production, when cutting a version, or when writing notes for a client. Triggers on: "release", "deploy checklist", "release note", "phát hành", "ghi chú phát hành", "cut a version", "go live", "リリース", "リリースノー...Votes: 0GitHub stars: 8
- RetroRun a sprint retrospective on evidence rather than memory, and write the status report that goes up: what the data says about the sprint, what the team says, the few actions worth taking with an owner each, and whether last retro's actions actually happened. Use at the end of a sprint, a milestone, or a phase, and when a status report is due to a PM or a client. Triggers on: "retro", "retrospective", "họp retro", "tổng kết sprint", "sprint review", "status report", "振り返り", "レトロスペクティブ", "weekl...Votes: 0GitHub stars: 8
- ReviewReview a teammate's pull request the way a team reviewer should: against the requirement, the design, and the team conventions, with findings ranked by severity, each one citing a line and stating the failure it causes, and blocking issues separated from preferences. Use before approving a PR, when reviewing a colleague's branch, or when a review needs a second opinion. Triggers on: "review PR", "code review", "review this branch", "review giúp", "duyệt code", "check PR", "レビュー", "approve thi...Votes: 0GitHub stars: 8
- SecurityReview the security of a change, a release, or a feature the way a team has to answer for it: the assets and trust boundaries in scope, the project's own scanners run, threats walked per boundary, every finding verified against the code with the path from entry point to impact, a checklist from the client or the company answered item by item with evidence, and the residual risk left for a named person to accept. Also keeps the threat model of a feature current. Use before a release that touch...Votes: 0GitHub stars: 8
- SpecWrite and keep current the reference documents a team reads long after the work merged: the API contract per resource, the schema per table, the behaviour of a feature, and a screen's components as its Figma design draws them. Also reports where they drift from the code, and a screen from its design. In a contract-first project, writes them from the design before the code exists. Use when a project has no written contract, when a merged change left one behind, or when the contract has to exis...Votes: 0GitHub stars: 8
- TailorWrite down how this team wants a skill to behave, as a file in the project rather than an edit to the kit: read the shipped skill, ask what the team does differently and why, refuse the parts that would let a skill decide what a person owns, and write the override file with the person who approved it named in it. Use when a team keeps repeating the same correction to a skill's output, when a client or an internal standard adds a step the kit does not know about, or when an override written ea...Votes: 0GitHub stars: 8
- VerifyConfirm a change works by running the real thing: start the app the way the project starts it, exercise it with real requests, assert the side effect in the data rather than the status code, compare the screen against the design when asked, and stop after three rounds with a named person rather than patching indefinitely. Use when the suite is green and nobody has yet seen the feature work, before handing a ticket to QA, or before a release goes out. Triggers on: "verify", "verify this works"...Votes: 0GitHub stars: 8
- Run CasesExecute approved test cases against a deployed DEV or staging environment through the browser: refuse production and the local stack, recon the accounts and data, triage every case as automatable, semi-automatable, manual, or blocked, naming the person who clears any obstacle the run cannot clear itself, agree the scope with the person before any case runs, run in at most three rounds, and write only the results it observed into a run record the QA lead approves and `atk:qa --bug` reads. Use ...Votes: 0GitHub stars: 8
- Skill EvalEvaluate an agent skill a project has written, for Claude Code, Codex or Cursor: a static check of its structure, metadata, size and safety, with a security gate for what the skill does and not only what it holds, a check against the project's own written conventions, trigger measurement on Claude Code, drafted trigger cases it lacks, a review of one run of it in this conversation, and one composite score with a grade above the figures behind it. Reads the skill and changes nothing in it. Use...Votes: 0GitHub stars: 8
- Good SkillSample skill for atkx:skill-eval: summarises a changelog file into three lines for a release announcement. A fixture with a known verdict, not a skill to install. Triggers on: "summarise the changelog", "tóm tắt changelog", "変更履歴を要約".Votes: 0GitHub stars: 8
- Malicious SkillSample skill for atkx:skill-eval holding one case of each kind of security gate failure. A fixture with a known verdict, never to be installed or run. Its hosts are all under example.invalid, and help comes from docs.example.invalid.Votes: 0GitHub stars: 8