kt-parser

Systematically map codebase architecture, stack, and conventions by analyzing docs and code factually. Trigger when user says "acquire codebase knowledge" or "map codebase", "understand codebase", "document codebase". trigger when you dont have infomration about codebase as a primary step to understand codebase.

Background reference skill defining the structured JSON log format written to logs/copilot/agent-activity.log by each phase agent on completion. Auto-loaded by Discuss, Research, Planner, TDD Implementer, and Verify agents when they append their completion log entry. Defines all required fields (timestamp, issueId, phase, agent, developer, status, summary, decisions, outputFile, nextPhase) and optional phase-specific fields (filesChanged for execute, testResults for verify). Also provides jq query examples for filtering logs by Issue, date, or status. Loads when log format, activity log, or agent logging is mentioned.

Use when a developer asks to review, audit, check, or critique any documentation file — when they say 'review this doc', 'is this README beginner-friendly?', 'check for markdown errors', 'audit the learn guide', or 'rate this doc'. Brutally reviews .md files for: beginner-friendliness (could a newcomer follow this?), markdown lint errors (broken links, bad code fences, heading hierarchy), missing references, and documentation quality. Outputs a structured report with Critical/Major/Minor issues, a Beginner-Friendliness Score out of 10, and a merge-ready verdict. Never softens feedback. Auto-loads when doc review, README audit, guide critique, markdown lint, or beginner-friendliness check is mentioned.

Use when a developer needs to create or improve technical documentation — when they say 'write docs for', 'document this API', 'create a tutorial for', 'write a how-to guide', 'add a README', or 'explain this feature in docs'. Applies the Diátaxis framework to classify the document type (Tutorial / How-to / Reference / Explanation), asks clarifying questions about audience and goal, proposes an outline for approval before writing, then produces well-structured Markdown. Stores in the correct project folder (docs/issues/, docs/flows/, docs/apis/, docs/external-apis/). Matches existing project doc style. Auto-loads when documentation, README, API docs, tutorial, guide, or explanation writing is mentioned.

Use when a developer needs to automate filling in a web form without submitting it — when they say 'fill in the form at URL', 'automate this form', 'enter these values in the web form', or 'test form input'. Uses Playwright MCP with accessible locators (getByLabel, getByRole, getByPlaceholder). Fills text with fill(), selects dropdowns with selectOption(), handles file uploads with setInputFiles(). ALWAYS stops before submitting — shows a filled-values summary and waits for human review. Auto-loads when form filling, web automation, input testing, or Playwright form interaction is mentioned.

Use when a developer wants to understand what to test on a website before writing tests — when they say 'explore the website', 'what should I test?', 'check what flows exist on this URL', 'analyze the UI for test coverage', or when given a URL and asked to plan browser tests. Uses Playwright MCP to navigate and interact with 3–5 core features, documents UI locators, user interactions, and expected outcomes, then proposes concrete test cases. Auto-loads when website exploration, test planning, UI review, or discovering testable flows is mentioned.

Use when a developer wants to create a Playwright end-to-end or browser test for a specific feature, flow, or scenario — when they say 'write a Playwright test for', 'generate a test for the login flow', 'add e2e tests for', or 'test this UI with Playwright'. Uses Playwright MCP tools to first interact with the real browser (not just guess at selectors), then generates a TypeScript spec using @playwright/test. Saves to tests/ directory with <feature>.spec.ts naming. Iterates until the test passes. Auto-loads when Playwright, e2e, browser test, or UI test is mentioned.

Use when receiving code review feedback or PR review comments, before implementing or accepting any suggestions — especially if feedback seems unclear, technically questionable, or conflicts with prior decisions. Enforces technical rigor over performative agreement. Provides: a 6-step evaluate-before-implement pattern; forbidden responses ('You're absolutely right!'); YAGNI check (grep codebase before adding features); source-specific handling (partner vs external reviewer); pushback templates with technical reasoning; a correction pattern when your pushback was wrong; and implementation ordering by priority (blocking → simple → complex). Auto-loads when user mentions code review, PR feedback, reviewer comments, or 'reviewer said to'.

Use when completing a task, implementing a major feature, or before merging — when a developer says 'review my code', 'check this before I merge', 'is this ready?', or after completing any task in a subagent-driven workflow. Dispatches a code-reviewer subagent with structured input (what was implemented, requirements, git SHAs). Provides a review template, severity tiers (Critical/Important/Minor), and instructions for acting on feedback. Mandatory after each task in subagent-driven development, after major features, and before any merge to main. Auto-loads when review, PR, merge, or code quality is mentioned.

Use when executing an implementation plan with 2+ mostly-independent tasks in the current session — when a developer says 'execute this plan', 'implement these tasks', 'work through the plan', or when a written plan exists and coding is starting. Dispatches a fresh subagent per task to prevent context pollution, then runs two mandatory review stages per task: spec compliance (did code match requirements?) then code quality (is it well-written?). Includes implementer prompt, spec-reviewer prompt, and code-quality-reviewer prompt templates. Distinct from executing-plans (which uses parallel sessions): subagent-driven-development stays in the same session. Auto-loads when plan execution, task implementation, or sequential development work is mentioned.

Enforces Test-Driven Development discipline for all new features, bug fixes, refactoring, and behavior changes. Use before writing ANY implementation code — when a developer says 'implement this', 'write the code', 'add this function', 'fix this bug', or 'build this'. Provides the Red-Green-Refactor cycle with concrete TypeScript examples, an Iron Law (no production code without a failing test first), a rationalization rebuttal table to counter TDD excuses, a verification checklist, and STOP conditions for when code must be deleted and restarted. Auto-loads whenever implementation, coding, building, or feature development is mentioned.