konstantinos-malavazos
UserA stack-agnostic blueprint for running Claude Code as an engineering teammate on a Jira/agile workflow — semantic code navigation, durable memory, and multi-agent flows behind slash commands.
Categories
Indexed Skills (21)
bootstrap
Scaffold a decided-but-empty repo until the implementation pipeline's preconditions are true — the stub, CLAUDE.md, Serena if the verdict calls for it, the layer specialists, the tracker adapter check, two memories — then run every check once and report. Use when charting has closed with a named stack, or the user says "bootstrap the repo" / "scaffold it" / "make the repo real". NOT for a repo that already builds, and NOT for choosing a stack.
cut-backlog
Cut a closed charting map into an ordered backlog of work units — one ticket per thing the app can now do, traced back to the smallest version, shown on a board you approve, then created in the tracker all at once. Use when charting has closed and the repo is scaffolded, or the user says "cut the backlog" / "turn the map into tickets" / "what do I build first". NOT for a map that is still open, and NOT for adding one ticket to a backlog that already exists.
handoff
Compact the current conversation into a handoff document a fresh session can pick up from. Use at the end of a working session, before a context limit, or when parking work you will return to later. Writes ONE file per subject to the root of <workspace>/.claude/handoffs/, reads and supersedes any existing file for that subject rather than sitting beside it, and carries only what exists nowhere else.
to-questionnaire
Turn a decision you cannot answer alone into a questionnaire for one other person to fill in — async, or together in a meeting. Use when the answer is a fact somebody else holds, and neither the code, the docs nor your own judgement can settle it.
wait-what
Stop. That last message did not land — re-pitch it.
charting
Chart an effort that is too big for one session and whose route is not yet visible — turn the fog into a map of tickets on the issue tracker, then resolve them one per session until nothing is left to decide. Use when the goal is clear but the way to it is not, when work will span many sessions, or when the user says "chart this" / "map this out" / "I don't know where to start". NOT for work you can already plan in one pass.
pitch
Put a raw idea through a one-hour kill gate and come out with a verdict — build, kill, or park. Six questions asked one at a time, two cold search subagents, three hard kills, and an anonymised third-party judge. Use when the user has an idea and no repo, or says "is this worth building" / "should I build this" / "pitch this" / "kill or build". NOT for work that already has a ticket, a repo, or a spec.
research
Investigate a question whose answer lives OUTSIDE this workspace — third-party docs, a vendor API, a spec, an RFC — and capture the findings as a cited Markdown file. Dispatch it to a background agent so the main session keeps working. Use when a decision is blocked on a fact nobody here knows yet.
grilling
Stress-test a plan or design by interviewing the user until every branch of the decision tree is resolved — OR explicitly deferred. Maps the decisions, posts the whole numbered set up front, then asks them one at a time. Use when the user wants to pressure-test their thinking, says "grill me", or when a plan has open questions before implementation. This is the deferred-decision gate of the pipeline.
adapt-to-stack
Generate one layer specialist agent, its slice-mode variant, and one engineering-standards skill per layer of a repo's chain, read out of that repo's own CLAUDE.md — creating what is missing, never overwriting what exists, and ending in one report. Use when a repo's CLAUDE.md declares a layer chain and the specialists do not exist yet, when the chain gains a layer, or the user says "adapt to my stack" / "generate the layer specialists". NOT for writing CLAUDE.md itself, and NOT for editing a generated file that already exists.
dispatch-weight
The single classification rule for how heavy ONE implementation dispatch is, so the orchestrator can escalate the model for that run only. Emits `light` or `heavy` plus a one-line reason naming the criterion that fired. Auto-loads whenever an agent is about to hand work to an implementation specialist, or is writing the plan/verdict/fix-plan that another agent will dispatch from. Triggers on "weight", "which model", "escalate", "dispatch the specialist", "re-pass", "REQUEST CHANGES", "model escalation".
memory-tag-lint
The write gate for /encode-codebase — the seven assertions every candidate memory must pass before it is written, and the positive control that proves the gate is wired up. Auto-loads before encoding a unit, before re-checking an encoded batch, and when running the proving gate on a draft vocabulary. Load it whenever a tag is about to be written or judged.
prototype
Answer a design question with throwaway code built to be reacted to and then deleted — a tiny interactive harness when the question is "does this logic hold up", several rough variants on one screen when it is "what should this look like". Use when a decision is stuck on something nobody can judge on paper, or the user says "prototype it" / "spike it" / "let me see it first". NOT for building the real thing, and NOT for a decision the code or the docs can already settle.
to-spec
Turn an approved planner.md into a slice-ready spec for a large ticket — the problem and the solution in user terms, the testing seam that proves each behaviour, and the behaviour boundaries to slice along. Runs inside the /start-ticket DECOMPOSE path, after the planner set slice-count > 1 and you approved the plan, and before /to-tickets. It is a thin transform of briefs that already exist: no interview, no re-exploration of the codebase. Not for a normal single-slice ticket.
to-tickets
Split a slice-ready spec from /to-spec into independent vertical-slice work-units for a large ticket, then render an approval board and STOP. Each slice is a thin COMPLETE path through every layer of the chain it needs, verifiable on its own testing seam. Writes one work-unit per slice under handoffs/<TICKET-ID>/slices/ plus a slice-board.md carrying the dependency waves and a DAG, for you to accept or edit. Internal work-units only — it never writes to the tracker. Runs inside the /start-ticket DECOMPOSE path, after /to-spec and before the orchestrator dispatches any slice.
wizard
Generate an interactive bash wizard that walks a human through a manual procedure only they can perform — provisioning infrastructure, credentials and CI secrets, an unfamiliar third-party dashboard, a one-off migration or cutover. Use when the blocking work is manual and tedious to re-explain every time. NOT for a step an agent can perform itself.
memory-schema
Your memory server's exact call shape and rules. Auto-loads before any memory WRITE (create/update/link a memory) so the model uses the correct tool shape, required fields, enums, char caps, and linking API — and stops inventing fields. Also load it whenever a memory tool errors with a validation failure before retrying.
commit-conventions
Canonical commit / branch convention for this workspace. Type/scope/ticket-id format, allowed values, the MR/PR description template, and the one-commit-per-branch rule. Auto-loads when about to commit, when naming a branch, or when finishing a logical change on a feature branch. Triggers on "commit", "commit message", "branch name", "MR/PR description".
diagnose
Disciplined diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose this" / "debug this", reports something broken/throwing/failing, or describes a performance regression.
layer-engineering-standards
GENERATED ONCE PER LAYER/LANGUAGE of your chain by /adapt-to-stack, into the repo's own .claude/skills/ under a per-layer directory name (e.g. schema-standards, backend-standards, frontend-standards). The coding + review standard for <LAYER/LANGUAGE>. Loaded when writing or reviewing <LANGUAGE> code, or when running as the <layer>-specialist agent. Deliberately carries NO rules for other layers so it stays cheap to load.
tdd
Test-driven development with the red-green-refactor loop. Use when building a feature or fixing a bug test-first, when the user mentions "red-green-refactor" or "test first", or when a bug fix needs a reproducing test before the fix.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.