haitranatwork
- 14 skills
- 0 followers
- 6 hours ago last updated
- ▌ Create Docs · haitranatworkGenerate a CLAUDE.md and a docs/ knowledge base for this repository so Claude can answer questions about architecture, business logic, workflows, and coding conventions. Use whenever the user asks to create, generate, bootstrap, or set up documentation, a knowledge base, CLAUDE.md, or repo docs — including phrases like "document this repo", "create docs", "set up CLAUDE.md", or "help Claude understand this codebase". Always plan first and wait for confirmation before writing files.
- ▌ Update Docs · haitranatworkSync CLAUDE.md and the docs/ knowledge base with code changes since the last documentation update. Use whenever the user asks to update docs, refresh documentation, sync docs with recent commits, check if docs are stale, or after merging changes — including phrases like "update the docs", "are the docs up to date", "sync documentation with the latest commits", or when the user names a specific commit range or PR to document.
- ▌ Forum Post · haitranatwork bundleDraft or review university discussion forum posts in the user's simple B1 English voice with APA 7 citations. Use for any discussion post, forum post, initial post, classmate reply, or when the user pastes their own draft post and asks to review, check, or improve it before submitting.
- ▌ Implement · haitranatwork bundleImplement one unit of a ticket from the knowledge base, commit it, and write a handoff file so any future session can resume cold without re-reading the docs or scanning the repo. Use whenever a developer says "implement WM-123", "continue", "next unit", "keep going", "carry on with the ticket", or asks to pick up where they left off. This is the developer-facing execution skill for the AI-Native SDLC chain and reads tickets.yaml from the knowledge base, not Jira. Do NOT use for planning, writing specs, or generating tickets.
- ▌ Write Plan · haitranatwork bundleWrite plan.md for an epic that already has spec.md and contracts — an ordered list of milestones, each one a deliverable slice with acceptance criteria an end user or QC can actually touch. Use whenever the user says "write the plan", "plan this", "break it into milestones", "next stage" after a spec, or mentions plan.md or milestones for an epic. This is stage 3 of the AI-Native SDLC chain and requires spec.md to exist first. Do NOT use for scoping a requirement, writing the spec, generating tickets, or implementing anything.
- ▌ Write Spec · haitranatwork bundleWrite spec.md and the API contracts for an epic that already has an approved intent.md, after reading the affected repositories with one subagent per repo. Use whenever the user says "write the spec", "spec this out", "next stage", "move to spec", mentions spec.md or contracts or OpenAPI for an epic, or asks what the API should look like for a scoped requirement. This is stage 2 of the AI-Native SDLC chain and requires intent.md to exist first — if it does not, say so and point to /write-intent instead. Do NOT use for scoping a raw requirement, for per-repo plans, or for tickets.
- ▌ Plan Status · haitranatworkReport progress across a whole epic — milestones, tickets, units done, what is blocked, and which doc-requests are waiting. Use whenever the user asks "where are we", "what's the status", "how is the epic going", "progress on WM-1740", "what's blocked", or asks for a rollup before sprint planning or a status report. Reads the knowledge base, not Jira. Do NOT use for planning, implementing, or reviewing.
- ▌ Sync Tickets · haitranatworkPush a reviewed tickets.yaml into Jira via the Atlassian MCP server, then write the assigned keys back into the file. Run only when the user explicitly invokes it — this skill creates real issues in a real backlog. Requires an existing tickets.yaml from /write-tickets and a connected Atlassian MCP server.
- ▌ Write Intent · haitranatwork bundleTurn a raw requirement into intent.md, the product-level artifact of the AI-Native SDLC Playbook, through a structured interview that pins down scope, out-of-scope, affected repositories, and cross-team dependencies before any planning happens. Use this whenever a new requirement, feature request, or epic arrives and needs to be scoped — including when the user says "new requirement", "scope this", "write the intent", "start an epic", "turn this into an intent", mentions intent.md or the knowledge-base repo, or pastes a requirement from a stakeholder and asks what to do with it. Use it even when the requirement looks small or obvious, because the value is in catching the hidden Core dependency and the unstated scope assumption. Do NOT use for spec.md, plan.md, or ticket generation — those are separate later stages.
- ▌ Review Ticket · haitranatworkReview a completed ticket against its acceptance criteria and the epic's contracts before it is handed to QC. Use whenever a developer says "review WM-123", "review this ticket", "check my implementation", "is this ticket done", or asks for a code review on ticket work. Reviews against the spec and the ticket, not general code style. Do NOT use for planning, implementing, or reviewing a single unit mid-ticket.
- ▌ Write Tickets · haitranatwork bundleGenerate tickets.yaml from an epic's milestones — one or more tickets per milestone, each split into small resumable implementation units so a developer can run as many as their context budget allows. Use whenever the user says "write the tickets", "break the milestones into tickets", "generate the backlog", "next stage" after a plan, or mentions tickets.yaml or implementation units. Requires plan.md to exist first. This skill NEVER touches Jira. Do NOT use for scoping, specs, plans, or implementing.
- ▌ Coding Assignment · haitranatwork bundleComplete university programming assignments (Java, Python, or any language) with a correct, runnable solution engineered to hit the highest band of every rubric criterion, a rubric self-check with evidence, and an optional B1-English write-up with APA 7 citations. Use whenever the user asks to solve, complete, review, or debug a coding assignment, programming homework, lab exercise, or course project — including when they paste an assignment description, rubric, starter code, or a failed test from a grader. Do NOT use for discussion forum posts or non-coding essays.
- ▌ Written Assignment · haitranatwork bundleDraft university written assignments (essays, reports, reflection papers, case studies) in the user's simple B1 English voice with APA 7 citations. Use whenever the user asks to write, draft, plan, review, check, or improve any graded academic writing that is not a discussion forum post, including "written assignment," "essay," "report," "term paper," when they paste a rubric and assignment question, or when they paste their own draft and ask for feedback.
- ▌ Apply Doc Updates · haitranatwork bundleReview and apply pending doc-requests that developers raised during implementation — proposed corrections to spec.md, contracts, plan.md, or the context and architecture docs. Use whenever the user says "apply doc updates", "any doc requests", "process the doc requests", "what did the developers flag", or asks to review proposed knowledge base corrections. Only the knowledge base owner runs this. Do NOT use for implementing or for writing new artifacts.