ananthanandanan
- 7 skills
- 0 followers
- 8 hours ago last updated
- ▌ Spec · ananthanandananTurn a rough product idea (or the output of /ank:third-degree) into a single, opinionated SPEC.md that serves as the source of truth for an entire product or feature. Use whenever the user invokes /ank:spec, says "let's design this", "draft a spec", "write the design doc", "turn this into a tech spec", or otherwise signals they want the idea crystallised into a reviewable document before tasks or code. The skill produces ONE file (SPEC.md at repo root for product-level specs, or docs/spec/<slug>.md for feature-level) and then HARD STOPS, waiting for explicit approval before any downstream skill (/ank:tasks) runs.
- ▌ Tasks · ananthanandananTurn an approved SPEC.md into a complete TASKS.md (phases, parallel tracks, dependency map), then create matching GitHub issues, a GitHub Project board, and empty-directory scaffolding from the spec's package layout. Use whenever the user invokes /ank:tasks, says "break this into tasks", "create the issues", "wire up the project board", or otherwise signals the approved spec should become trackable, parallel-friendly work. Requires a SPEC.md to exist and the user to have explicitly approved it. The skill HARD STOPS before creating GitHub side-effects, asks for confirmation, and gracefully degrades when the gh CLI is absent or unauthenticated.
- ▌ Handoff · ananthanandananGenerate a Markdown handoff document summarizing the current conversation so another agent (Claude, Codex, opencode, pi, ampcode, Cursor, or a fresh session) can resume without re-deriving context. Produces docs/<slug>-handoff.md. Invoke explicitly when a session is near its context limit.
- ▌ No Yap · ananthanandananAnswer in ASD-STE100 Simplified Technical English — the numbered-clause, one-idea-per-sentence style of an aircraft maintenance manual — instead of a wall of prose. Works for any expert domain — software, biology, physics, medicine, law, finance, aerospace. Use whenever the user invokes /ank:no-yap, or says "explain it simply", "no yapping", "keep it structured", "give me the short version", "STE style", "plain English", or otherwise signals they want a dense explanation restructured into something scannable. Applies to cause-and-effect questions, summaries of what changed, mechanism walkthroughs, and "how does X work". Answers inline in chat only — never writes a file.
- ▌ Review Board · ananthanandanan bundleGenerate a single-file HTML "story-paced" walkthrough of a finished feature for human code review. Use after completing a feature or merging a PR — produces docs/review/<slug>.html with sidebar nav, Why/Tradeoff/Deferred callouts, status pills, and a reviewer's checklist.
- ▌ Third Degree · ananthanandananInterview the user to converge on a shared, concrete understanding of a feature before any planning or implementation — the front of the ank pipeline (third-degree → visualise-plan → review-board). Use whenever the user invokes /ank:third-degree, says they have a "rough idea", asks you to "flush out the requirements", "interview me", "interrogate me", or otherwise signals the spec is fuzzy and needs pinning down before code or a plan is written.
- ▌ Visualise Plan · ananthanandanan bundleProduce a visual HTML implementation plan for a feature BEFORE writing any code. Use this skill whenever the user invokes /ank:visualise-plan, asks for an "implementation plan", says "plan this out before you build it", asks you to "visualise the plan", or otherwise signals they want to review the approach as a document before code is written. The skill assumes all clarifying questions about the feature have already been answered in this conversation — its job is to crystallise that context into a single reviewable HTML file at docs/plan/<feature-slug>.html and then HARD STOP, waiting for the user to type "approved" (or send edits) before any implementation begins.