khuynh22
- 26 skills
- 0 followers
- 13 hours ago last updated
- ▌ Tdd Loop · khuynh22Writes the failing test first, watches it fail for the right reason, then makes it pass with the smallest change. Use before implementing any feature or bug fix, when adding a regression test, or when a change needs proof it works. Refuses to write implementation code before a red test exists.
- ▌
- ▌
- ▌
- ▌ Spec Writing · khuynh22Turns gathered requirements into a written specification that an implementer can build from without asking follow-up questions. Use when requirements are known but not written down, before starting a feature that spans several tasks, or when a spec needs reviewing for gaps and contradictions. Produces a committed document, not a chat message.
- ▌
- ▌
- ▌
- ▌
- ▌
- ▌
- ▌ Work Breakdown · khuynh22Splits a spec into an ordered list of tasks, each with a single verifiable outcome, an assigned tier, and a delegation brief. Use when a spec exists but there is no plan, when work must be divided across agents or people, or when a task is too large to verify in one step. Produces a plan file, not code.
- ▌ Team Escalation · khuynh22Hands work up to a higher tier, or down to a lower one, with a structured packet so no context is lost. Use when a task exceeds the current agent's ceiling, when a brief is too vague to execute, when two agents disagree, or when decomposing work for someone else to do. Escalating correctly is a successful outcome, not a failure.
- ▌ Autonomous Relay · khuynh22Runs a tracker ticket through the whole lifecycle without stopping at each stage boundary - requirements, plan, build, review, release plan - with escalations routed to a terminal tier instead of to a waiting human. Use when a ticket already carries enough intent to work unattended, when nobody is available to answer stage-by-stage questions, or when the ask is to work an issue end to end and report back. Refuses to deploy, refuses to push, and refuses to resolve product intent on the human's behalf.
- ▌ Code Review Pass · khuynh22Reviews a diff, branch, or pull request across correctness, security, architecture, readability, and performance, returning ranked findings with file and line references and a concrete fix for each. Use before merging, when checking code written by someone or something else, or when a change needs a quality gate.
- ▌ Performance Pass · khuynh22Fixes measured slowness by setting a budget, profiling to find where time actually goes, changing one thing, and measuring again. Use for a latency regression, an N+1 query, memory growth, a slow build or test suite, or a Core Web Vitals miss. Refuses to optimize anything without a baseline number.
- ▌
- ▌ Security Hardening · khuynh22Audits a change or a system for reachable vulnerabilities by tracing untrusted input to its sinks and checking authorization at every new path. Use when code touches authentication, secrets, cryptography, file paths, shell execution, deserialization, or any input crossing a trust boundary, and before exposing anything to the internet.
- ▌
- ▌ Browser Verification · khuynh22Confirms a user-interface change actually works by loading it in a real browser and checking rendering, interaction, keyboard access, console output, network calls, and responsive behavior. Use after any visual or interactive change, when a test passes but the page might not, or before claiming a UI change is done.
- ▌ Incremental Delivery · khuynh22Executes a multi-task plan one task at a time, keeping every commit atomic and green before starting the next. Use when working through a task list, when a change is large enough to need checkpoints, when commit hygiene matters for bisect, or when tempted to build several things at once. Refuses to begin the next task while the previous one is unverified.
- ▌
- ▌ Systematic Debugging · khuynh22Finds the actual cause of a defect by reproducing it, narrowing the search space by bisection, and proving the diagnosis before changing code. Use for a crash, a stack trace, a flaky or intermittently failing suite, or behaviour that differs from expectation and resists an obvious fix. Refuses to change code before the cause is proven.
- ▌ Using Agent Dev Team · khuynh22Routes an incoming engineering request to the right team member and the right workflow, and explains the tier system. Use at the start of any development work when it is unclear who should do it, which skill applies, or how much process a task deserves. Also use when a task turns out to be bigger than it looked and needs re-routing.
- ▌ Architecture Decision · khuynh22Records a non-obvious technical choice as an ADR with context, options, the decision, consequences, and the condition that should reopen it. Use when choosing between technologies or designs, when a decision is expensive to reverse, or when someone will ask in six months why it was done this way. Also use to review a proposed design.
- ▌ Requirements Interview · khuynh22Extracts what someone actually needs by asking one question at a time, separating the problem from the solution they proposed. Use when a request is vague, when you are about to guess at intent, when scope keeps shifting, or when nobody has said what done means. Ends with written requirements and acceptance criteria.