All of my mad agentic skills

Trying to build things can be hard, and I honestly think AI has made this harder as an Engineer, not easier.

Before we'd go through the full SDLC cycle, requirements gathering, planning, designs, implementation, QA blah blah. But with AI you can write a prompt, set your claude code to bypass permissions, grab a cuppa, then realise "woah its done everything!"... the issue is what its actually built might look and feel like the real deal, but as it scales, as it hits real world scenarios, it rarely holds up. So here are a list of skills with huge inspiration from the incredible Matt Pocock, with some of my personal favourite engineering authors, Robert C. Martin, Martin Fowler, Eric Evans, and more. Time to figure out how to remain an engineer in the world of AI.

Setup

1. Run the skills.sh installer:

npx skills@latest add canhassancode/skills

2. Select the skills you want.
3. Donezo. Enjoy!
4. If you ever need to update the skills, run:

npx skills@latest update

What's in the box

Skills are organised into folders by category. Each folder maps to a section below.

engineering/ — the core SDLC loop

• bootstrap — one-time per-repo setup for both lanes: the triage-graph tracker: preference and the planning lane's docs/agents/*.md config (GitHub/Linear/GitLab/local)
• code-review — four-axis review of a diff (Standards, with a Fowler smell baseline ‖ Spec ‖ Structure ‖ Design, path-triggered on DESIGN.md) in parallel sub-agents; called by implement, runs alongside review
• codebase-design — deep-module design vocabulary, principles, and testability guidance (model-invocable; referenced by tdd and improve-codebase-architecture)
• commit — create a git commit with conventional commit message format
• design-system — interview a repo's brand knobs into a DESIGN.md and a token layer, then amend it as motifs are earned from prototypes; the invariant lives in SYSTEM.md, the flavour in the repo
• diagnose — disciplined diagnosis loop for hard bugs and performance regressions (reproduce → minimise → hypothesise → instrument → fix → regression-test)
• domain-modeling — build and maintain a project's domain model (model-invocable: challenge terms, sharpen language, stress-test with scenarios, update CONTEXT.md inline, offer ADRs)
• grilling — reusable interview loop (model-invoked): the relentless-questioning core shared by grill-me and grill-with-docs
• grill-with-docs — stress-test a plan against the project's domain model, glossary, and ADRs; updates docs inline (and captures the session into the Obsidian Library if present)
• handoff — compact the conversation into a handoff doc for a fresh session to pick up (written into the Obsidian vault's Handoffs/ when present, else a tmp file)
• implement — implement a spec or set of tickets: TDD at pre-agreed seams, regular typecheck, then code-review before committing
• improve-codebase-architecture — find deepening opportunities informed by CONTEXT.md and ADRs
• pr — create a GitHub pull request with a structured summary
• prototype — build a throwaway prototype to answer a design question (logic or UI branch); model-invoked so wayfinder can reach it
• receive — resume an agent handoff from Handoffs/, then delete it
• research — spin up a background agent to investigate a question against primary sources and write cited findings to a markdown file
• resolving-merge-conflicts — resolve an in-progress git merge or rebase conflict from the primary sources behind each hunk, then run the project's checks
• review — review a named GitHub PR in Hassan's voice: check the branch out locally, run code-review for the analysis, post inline comments after confirmation. With no argument it no longer self-reviews — that is code-review against a fixed point
• tdd — test-driven development with red-green-refactor loop
• to-proposal — turn a grilling into an argued proposal for a decision-maker and publish it to the tracker as ready-for-human (the proposal sibling of to-spec)
• to-spec — synthesise the current conversation into a spec and publish it to the tracker as ready-for-agent (no triage); the planning lane's entry point
• to-tickets — break a spec into tracer-bullet tickets with blocking edges, as native tracker links or a local tickets.md
• triage — triage inbound issues through a state machine driven by triage roles
• wayfinder — chart an oversized, foggy plan as a map of investigation tickets (research/prototype/grilling/task) on the tracker, resolved one session at a time

productivity/ — meta-skills for working with me and Claude

• grill-me — interview me relentlessly about a plan until each branch of the decision tree resolves
• writing-great-skills — vocabulary and principles for predictable skills; companion GLOSSARY.md

personal/ — the Obsidian second brain

An Obsidian vault in two halves: Library for the world (external sources, agent-written) and Profile/Personal for Hassan (hand-edited). See the vault's own CONTEXT.md/CONVENTIONS.md for the model.

• ask — answer a question from the brain, routed by query shape: grep for a named fact, index-first for a conceptual one
• file — file a personal document or self-fact into a domain folder or Profile/: OCR on intake, matter-as-unit with linked raws, supersede-don't-append fact hygiene; also drains the top item from Inbox/
• ingest — process an article, video, or book chapter into the Library wiki; also drains the top item from Inbox/
• observe — append one timestamped observation to Profile/observations.md; called by nothing, drained by retro
• retro — drain the observations file one item at a time, each into a change made in the same sitting

in-progress/ — works in progress, not yet released

• system-map — build a layered map of how a flow or domain concept spans multiple repos (UI → API → service → data)

deprecated/ — kept for reference, no longer recommended

• validate — superseded by per-repo validation hooks
• obsidian-vault — superseded by the second-brain skills above (ask/ingest)
• write-a-skill — superseded by writing-great-skills
• to-prd — superseded by to-spec; "spec" is the honest superset of PRD
• to-issues — superseded by to-tickets; tracker-neutral "ticket", with blocking edges
• setup-tracker — superseded by bootstrap; configures both lanes, not just the tracker preference
• challenge — superseded by grill-me; the same Socratic pass, with a decision tree that has to resolve
• pickup — superseded by implement, which takes a ticket reference and absorbs the stale-brief risk pickup existed to catch
• inbox — superseded by ingest, which drains Inbox/ as part of its own flow
• morning-brief — retired, not replaced; the daily Operating Loop and its Journal/ are gone
• eod-summary — retired, not replaced; same reason as morning-brief
• lint — retired, not replaced; the vault's surviving files are hand-written and don't generate hygiene debt

My day-to-day

The ones I reach for most:

• grill-me / grill-with-docs before any non-trivial change
• Planned work (triage-free lane): grill-with-docs — or wayfinder when it's too big for one session — to shape it → to-spec → to-tickets → implement each ticket → code-review → commit/pr. A grill that turns out to be an argued recommendation rather than a build routes to to-proposal (tracker, as ready-for-human) instead.
• New frontend repo: bootstrap → design-system (knobs, tokens, empty motifs) → prototype the first screen → design-system again to distil the motifs → then the planned-work lane as normal.
• Inbound work (triage lane): triage for bugs from users, drafts from collaborators, stale tickets → implement the ticket → tdd / diagnose.
• diagnose for anything broken; code-review for my own branch, review for posting on someone else's PR