hackify

Print a concise 2-column Area/Change summary table for the current hackify task.

Phase 2.5 Spec-review C — proposes a topological execution-wave plan for a hackify work-doc Sprint Backlog and flags dependency/ordering/parallelism risks (file-collision edges within a wave, missing prerequisites, oversized or undersized tasks) before Phase 3 implementation begins.

Phase 2.5 Spec-review B — audits a hackify work-doc plan against project CLAUDE.md and user-global rule files for architectural/cross-cutting risks (lint suppression, non-null assertions, inline types in forbidden files, layering violations, bare Error throws, security regressions) before Phase 3 implementation begins.

Phase 5 Multi-reviewer C — audits a base..head git diff against the authorizing hackify work-doc for plan-consistency and scope defects (DoD bullets without covering hunks, ticked Tasks without covering hunks, files touched without an authorizing Task in task_file_index, Q&A scope violations, missing/mismatched CHANGELOG bullets). Requires the dispatcher to provide a pre-built task_file_index.

Phase 5 Multi-reviewer B — audits a base..head git diff for quality & layering defects (DRY violations against existing helpers, function/parameter/nesting/file size caps, inline types in forbidden files, new lint suppressions, non-null assertions, empty catches, bare Error throws in domain code), citing verbatim CLAUDE.md rule sentences and file:line for every finding.

Phase 5 Multi-reviewer A — audits a base..head git diff for security & correctness defects (auth flows, permission boundaries, injection, PII/secrets, migration safety, race conditions), citing OWASP Top 10 / CWE / NIST / RFC 6749 / RFC 7519 standards and post-image file:line for every finding. Dispatch one of these in parallel with Multi-reviewer B and C in a single parent assistant message.

DEEP-BY-DEFAULT browser-based interactive call-stack viewer for code the user did not write — a senior-peer walkthrough of one execution path from a single entry point (route, handler, CLI command, queue job, UI action), rendered as a GitHub-PR-style three-pane app under `.codewalk/<slug>/` at the repo root. Auto-discovery triggers (case-insensitive substring match on the user's latest prompt) — `/codewalk`, `walk this code`, `walk me through`, `walk through this`, `trace this call stack`, `trace this flow`, `trace from`, `explain this flow`, `explain how this works`, `what happens when`, `onboard me to`, `call-stack viewer`, `code walkthrough`. Workflow shape — Phase 1 confirm entry (clarify ONLY on ambiguity) → Phase 2 read repo conventions → Phase 3 deep depth-first walk to LEAVES (controller → service → repository/external + every type/interface/DTO/Zod schema crossed on the path, emitted as separate `layer: "type"` nodes hyperlinked from the function nodes that reference them) → Phase 4 emit `data.json` → Phase 5 materialize the viewer by copying assets and writing `data.json` → Phase 6 launch `node serve.js` (with a fallback chain when Node is missing) → Phase 7 chat handoff (5 comprehension questions + decisions checklist). Locked contract — **the trace is deep-by-default, types are first-class nodes, and re-invokes UPDATE rather than overwrite**: walk to leaves regardless of size, emit a `layer: "type"` node for EVERY interface / type alias / class / enum / Zod schema / NestJS DTO / TypeORM entity referenced on the path, cross-link with `call_sites[].callee_id` that MUST resolve to a `nodes[].id` (no dangling links); on re-invoke for the same slug, LOAD the existing `.codewalk/<slug>/data.json`, preserve manual edits to docblock.purpose/risk/branches_not_taken when function_range is unchanged, replace the live fields (source/invoked_lines/call_sites/data_in/data_out/git_blame), set previous_generated_at, and compute `diff_vs_previous` so the viewer's amber callout shows added_nodes / removed_nodes / signature_drift / new_side_effects; the user must type "regenerate" or "fresh" to opt INTO a blind overwrite; never collapse a sub-path because "it's a service / repo / external client"; the viewer is the deliverable, not chat narration; branches not taken are listed BY NAME and never expanded; on ambiguity (env flags, feature gates, tenant guards, DI tokens, dynamic dispatch) the skill STOPS and asks rather than guessing; **the viewer defaults to light mode** (`?theme=dark` or the header toggle switches to dark); `.codewalk/` is added to `.gitignore`. Self-contained — never calls other skills.

Socratic pre-task refinement skill — the idea-shaping front door to the hackify workflow. Runs an interactive 1-or-2-forking-questions-per-turn conversation (NOT a batched wizard), reflects what the user said before each following question, and graduates to full hackify Phase 1 the moment the user signals build intent. Auto-discovery triggers — invoke this skill when the user prompt contains any of `/hackify:groom`, `let's discuss`, `let's think`, `what if`, `groom`, `explore the idea`, `what do you think`, `considering`, `thinking about`, or any open-ended idea-exploration phrasing that has no concrete build verb. Do NOT invoke when the prompt already contains build verbs like `add`, `implement`, `build`, `fix`, `refactor`, `ship`, `make this happen` — those route directly to full hackify or quick via each skill's own description-based auto-discovery. Locked contract — groom runs WITHOUT a work-doc until graduation; no scratch files, no eager creation. At graduation, write a one-paragraph distillation, create the canonical work-doc at `<project>/docs/work/<YYYY-MM-DD>-<slug>.md` with a `## Groom Provenance` block, then hand off to Phase 1 of `skills/hackify/SKILL.md`. Use this skill when the user is exploring an idea, not yet asking for a build.

One unified end-to-end dev workflow for ANY substantive task — feature, bug fix, refactor, redesign, design, debug, migration, or research-then-build — driven by a single per-task markdown work-doc at <project>/docs/work/. Replaces multi-skill ceremony (no separate spec/plan files). Asks every clarifying question up-front in one batched questionnaire, holds a hard gate before code is written, file-driven pause/resume across sessions, mandatory evidence-before-claims, baked-in self-review checklist, parallel multi-reviewer code review on non-trivial diffs, explicit definition-of-done verified end-to-end. The default route for any substantive prompt — auto-fires on broad-spectrum verbs (add, build, implement, refactor, redesign, restyle, migrate, debug, polish, audit) AND on architecture/scope/security surface (auth, crypto, migration, secret, token, password, schema, data model, API surface, refactor everywhere, across all). Invoke even when the user does not say "use the workflow" — carve-outs are trivial factual Q&A, single-line typo fixes, and pure read-only inspection. When in doubt, invoke this skill — escalation to full ceremony is free, demotion is not.

Audit an existing or new codebase against its engineering laws — hard caps (function/file/param/nesting), zero-tolerance bans (lint suppressions, non-null `!`, empty catches, bare Error throws, secrets, inline types in scoped modules), plus DRY, naming, layering, single-responsibility, folder-structure, and file-scoping rules. Reads the rule set at audit time from the project's OWN harness (.claude/rules, ban-patterns.txt, CLAUDE.md/AGENTS.md), stricter-wins fallback to global doctrine; runs a deterministic scanner plus semantic subagents; reports every finding with file:line by category/severity, then fixes them one at a time with your approval. Use when the user wants to check, audit, validate, or enforce engineering rules/standards/conventions across a project — e.g. "audit my code against our rules", "does this follow CLAUDE.md", "find all rule violations", "validate the architecture". FULL-CODEBASE sweep — NOT for generating a project's CLAUDE.md/rules, NOT for a single PR diff (use code-review).

Compressed-flow companion to the hackify workflow for genuinely small tasks where full ceremony (Plan+Gate, Spec review, Multi-reviewer, 4-options finish) would burn more wall-clock and tokens than the change is worth. Auto-discovery triggers — invoke this skill when the user says any of "quick fix", "small change", "just fix the", "one-line fix", "tiny edit", "small fix", "small bug", "quick patch", "minor tweak", "just rename", "fix typo", or the explicit slash form /hackify:quick. Workflow shape — Phase 1 (clarify ONLY if ambiguous; zero questions otherwise) → Phase 3 (implement; single foreground agent OR inline edit; file allowlist still applies) → Phase 4 (verify; full test + lint + typecheck triad still mandatory) → Phase 6 Step F (mandatory 2-column Area/Change summary table, printed to chat). Do NOT auto-fire on cross-file refactors, redesigns, debug investigations of unknown root causes, or anything touching auth/crypto/migration/secret/token/password — those route to full hackify via its own description. User-locked mode — once invoked, quick mode stays in quick mode for the entire task. It only promotes to full hackify when the user explicitly says so (e.g., "switch to full", "promote to full", "/hackify:hackify"). No work-doc is created, so progress cannot be paused or resumed across sessions — invoke full hackify if you need pause/resume.

2 hooks across 2 events