Claude Skills by kapilvirenahuja

Author the /vision seed of the product model — a detailed domain grounding doc and directional capability grounding docs — straight to the live model, and emit the matching spine-delta (domain + capability entries, status proposed, detail directional, and the directional profile block) as structured data in the seed manifest. Generative artifact production for the /vision play. Under direct-model-write (ADR 026) it writes ONLY the per-node docs (domain.md, capability.md) in place, skip-if-exi...

Systematically enumerate import and call relationships across a codebase, build a structured dependency graph, and emit both dependency-graph.yaml (structured data) and dependency-graph.md (mermaid diagrams + module clusters). Used by tech-architect.

Run the per-round tension check that makes /grill's steelman push-back discipline real. Reads the epic cut on the live model (the `epic.md` grounding docs, written in place per ADR 026 — there is no draft tree) and everything the slice declared — its functionalities' grounding docs `functionality.md` (the hub), all SEVEN lens grounding docs, and the profile bars — and produces a structured tension report, one entry per real contradiction, each citing the specific declared item it defends (sou...

Given a change surface (file list) and a dependency graph, compute directly and transitively impacted tests, identify coverage gaps in the change surface, and emit blast-radius.yaml. Used by test-engineer.

Load the domain-taxonomy capability catalog, apply project-profile-driven inclusion rules, walk every cross-tree constraint explicitly, present optional capabilities to the user, produce scope.yaml with selected/rejected capabilities and the constraint_trace audit.

Stage files and create one or more commits in a single pass

Deploy a delivered increment to ONE resolved cloud environment exactly as the slice's run lens (run.yaml) declares it — run the environment's declared deploy command honoring its provider, region, compute, services, and networking; read secrets only from the declared secrets-manager binding (never print or store them); then prove the increment answers with an independent reachability/health check and capture a deploy record (environment, what ran, address, health proof, secrets source). On fa...

Read logical architecture, physical architecture, and nfr-spec to produce design-patterns.yaml — the pattern catalog applied to this product at every applicable layer: system-level, layer-level, component-level (per runtime tier), and cross-cutting. Every pattern carries applicability scope, a cited driver, alternatives considered, and source_type.

Stage 3 skill of /arch. Builds the layered logical architecture for a product by selecting components from the systems inventory, placing each in a layer of the product-locked layer model, wiring edges with sync/async intent, detecting cycles, and validating end-to-end traceability of every selected capability from the user-facing entry layer to a serving component. Logical names systems by their inventory ID and role — never by product, runtime, language, protocol, or schema.

Read the upstream quality profile, intent epics constraints block, and physical architecture to produce nfr-spec.yaml — a per-NFR contract that re-states intake targets, records any agent adjustments with rationale, and for every NFR names the specific architectural mechanism that delivers it plus the verification method.

Stage 4 skill of /arch. Builds the runtime physical architecture by mapping every logical component to one or more physical components, inheriting system_ref grounding from the inventory, picking specific deployment targets and resources, wiring comms with retry/idempotency stance, and naming a delivery mechanism for every NFR target in the refined quality profile. Mapping cardinality (1:1, N:1, 1:N) is recorded per physical component with rationale for non-trivial cases.

Read quality-profile, nfr-spec, logical architecture, and physical architecture to produce quality-vision.yaml — a vision statement plus per-ISO-25010-characteristic entries carrying vision narrative, target level, design linkage, concrete named tooling, quantified thresholds, and lifecycle gates. Merges and extends the prior quality-standards artifact.

Stage 1 skill of /arch. Walks selected capabilities, identifies the system (and any sub-systems) that serves each one, and populates the product's systems-inventory by pulling KB-grounded systems with provenance or authoring novel systems as stm_research with the required KB-extension shape. Output is the inventory every later /arch stage reads.

Stage 5 skill of /arch. Picks languages, runtimes, frameworks, libraries, tools, and design patterns per box (component, group of components in a layer, or product-wide). Patterns referenced MUST be industry-documented with literature citations — invented patterns are rejected. System-level decisions (monolith / microservice / serverless / modular monolith) are patterns and live here, not in a separate artifact. Every entry carries source_type, scope, and rationale citing a QP target, a proje...

Inspect scan-index manifests, existing CI workflow, and detected test frameworks to produce a TEST_HARNESS record describing how to actually run the codebase's tests — framework, runner command, working directory, dependency install command, env vars, and stdout pass/fail parse format. Pattern-matches against a canonical harness catalog. Called by /decode before test generation or baseline-green verification (C26). Halts with a prerequisites error when no runnable harness is detectable (F18).

Given a completed rca.yaml, design a fix with at least one alternative considered and rejection reason, affected-files map with change specifications, and a self-sufficient execution plan. Writes design.yaml.

Create a plan.yaml artifact — execution order of features as vertical slices with scope items, exit gates, and scenario gates

Create a tech.yaml artifact with project structure, libraries, data model, components, design decisions, and feature mapping from features and architecture specifications

Create a features.yaml artifact defining product identity, invariants, scope, and features with IDD fields from product intent

Trace a reported defect from symptom to specific root cause — the file, the logic, and why it is wrong — and author rca.yaml plus resolution-trace.yaml (when LTM context provided). Used by tech-designer in the fix-it play.

Produce language-agnostic reference pseudocode sections for algorithmically complex internal interfaces identified in tech.yaml. One section per qualifying interface.

Produce tech.yaml — project structure, library picks, build/test tooling, runtime configuration — from a features spec, technical approach, and architecture inference. Used by tech-architect in the prepare play.

Create an architecture.yaml artifact with technology selections, NFRs, platforms, integrations, and agentic PCAM design from a features specification

Create a scenarios.yaml artifact with grouped scenarios, feature back-links, feature gates, and coverage summary from a features specification

For each selected capability, merge project-profile-specific overrides onto the KB base values (business rules, depth spectrum cap, experiential warnings), producing enriched-capabilities.yaml — the input to intent-epic generation.

Detail one capability that /vision seeded — promote its capability.md from the directional stage to the detailed stage (benefit hypothesis, boundary, guiding rules, functionalities), author a detailed functionality.md grounding doc for each functionality it identifies, set the capability's structured nfr_needs + compliance_needs, and emit the implied per-dimension levels. Grounded in the capability's KB shelf. Generative artifact production for the /understand play. Under direct-model-write (...

Generate testable verification evaluations from spec inputs (product-spec behaviors, verification scenarios, epic success and failure conditions, LLD exit-gate text), encrypt the resulting YAML with AES-256-CBC + PBKDF2, delete plaintext, and write a manifest.json. Single common skill for the evals-engineer agent.

Infer logical architecture from an existing codebase — module structure, design patterns, framework conventions, LLD patterns — and write architecture-inference.yaml. Used by tech-architect in the prepare play.

Infer the design-patterns catalogue (architecture/design-patterns.yaml) from scan-index.json during /codify by mapping naming suffixes, framework idioms, and layered directory trees to named patterns — each scoped as system/layer/component/cross-cutting, cited to a driver, with alternatives considered and source_type tagged. Called by tech-architect after logical-architecture and physical-architecture proposals exist.

Infer which product domains a brownfield codebase evidences by cross-walking scan-index.json signals (framework idioms, dependencies, config, readme, CI) against Garura's canonical domain KB. Produces specification/domain-selection.yaml. Used by product-keeper during /codify.

Infer per-capability enrichment (business rules, depth spectrum cap, experiential warnings) during /codify by merging KB base values from core/components/memory/knowledge/domain/{domain}.md with project-specific overrides evidenced in scan-index.json. Produces scope/garura:enriched-capabilities.yaml. Used exclusively by product-keeper in the /codify play.

Derive epic boundaries for a brownfield codebase by clustering capabilities from features.yaml, enriched-capabilities.yaml, scope.yaml, and domain-selection.yaml using co-change, KB domain grouping, version tags, and ADR titles. Produces one minimal intent-epic stub per derived epic. Used exclusively by product-keeper during /codify.

Infer the 3-tier domain → capability → feature catalog (scope/features.yaml) from scan-index.json during /codify by enumerating per-capability modules, routes, and entry-point wiring, then assigning a 5-point status (planned | development | rollout | released | cleanup) from release tags, churn, test presence, and deprecation markers. Used exclusively by product-keeper after infer-enriched-capabilities-from-code.

Infer a technology-agnostic logical architecture (bounded contexts, components, data model, capability-level API surface, integration points, ADR log) from scan-index.json plus prior codify proposals, during /codify. Used exclusively by tech-architect.

Produce a low-fidelity market-brief.md stub from codebase signals (README, manifests, ADRs, git tags, deploy config) during /codify. Owned by product-keeper. Confidence defaults to low; real market data is never inferable from code.

Infer the MVP recommendation from scan-index.json during /codify by reverse-engineering what the shipped codebase ALREADY treats as v1 — primary use cases evidenced by release history, entry points, churn, and README — plus deferred capabilities evidenced by thin/scaffold-only code. Output is Markdown with YAML frontmatter. Used exclusively by product-keeper in the /codify play.

Infer the NFR spec from scan-index.json during /codify by reading framework idioms, dependency manifests, deploy configs, and CI signals to reconstruct what non-functional requirements the shipped code already enforces — per-NFR target, delivery mechanism (named library / middleware / layer), and verification method — with every entry traced to concrete evidence paths. Used exclusively by tech-architect in the /codify play.

Infer the physical architecture proposal (runtime, deployment target, data stores, caches, queues, search, observability, auth infrastructure, scaling strategy) from scan-index.json during /codify, naming specific products (Postgres 15, Redis 7, Kafka, etc.) — never categories. Every slot is grounded in concrete manifest / Dockerfile / infra / CI evidence and tagged source_type=inferred_from_code. Used exclusively by tech-architect in the /codify play.

Infer the foundational project-profile.yaml (product identity, team shape, technology posture, compliance hints, platform targets, delivery maturity) from scan-index.json during /codify, with every field grounded in concrete scan-index evidence and tagged source_type=inferred_from_code. Used exclusively by product-keeper in the /codify play.

Infer the product's ISO 25010:2023 quality-profile.yaml (characteristic-level targets, security profile, risk register) from scan-index.json during /codify, grounding every characteristic level and every risk entry in concrete scan-index signals and tagging source_type=inferred_from_code. Used exclusively by test-engineer in the /codify play.

Synthesize a quality-vision proposal for a brownfield codebase by merging the already-inferred nfr-spec, quality-profile, physical-architecture, and logical-architecture proposals, then attaching scan-index signals (ADRs, CI/lint/test config files, commit cadence) to the relevant ISO 25010 characteristics. Produces a Tier 1 proposal at architecture/quality-vision.yaml. Used exclusively by tech-architect during /codify.

For every domain in the upstream domain-selection proposal, derive a product-scoped research Markdown file from scan-index.json evidence plus the canonical domain KB, carrying the five KB-extension sections with inline knowledge_gap markers wherever code evidence is absent.

Infer the v1 scope.yaml (selected / deferred / rejected capabilities plus depth caps, within-domain coverage gaps, and constraint trace) by scoring KB capabilities against scan-index.json signals during /codify. Bounds the selection to the domains already chosen in the domain-selection proposal and the profile posture from the project-profile proposal. Used exclusively by product-keeper in the /codify play.

Compose /validate's findings from CAPTURED results only — the judgment half of the finder's job. Reads the normalized check results (results/*.json + summary.json from run_checks) and the gates/benchmark map (gates-map.json from check_gates), and writes findings.yaml — one entry per real problem, each carrying its mechanical citation (the failing check id, the rule that fired, the gate or benchmark) and its location (file:line where the tool named one, else the raw log path). Adds judgment th...

Search the empirical Knowledge Base for the best-fit architecture and technology learnings given a product's conditions. Use during context-building in the realize lenses (/arch, /run, /ux, /agentic) when you need to know what worked before for a product in this situation — its stage, scale, persistence, and monetization. Reads the architecture/ and technology/ shelves (the condition-matched, "what works for us" engine), distinct from search-kb which routes work to a domain. Returns the learn...

Validates Garura components (plays, agents, skills) against structural, semantic, and cross-reference rules. Reads quality profile to classify violation severities.

Author the canonical 3-tier domain → capability → feature catalog (features.yaml) from enriched-capabilities.yaml using the 5-point status vocabulary (planned | development | rollout | released | cleanup). Use this skill whenever product-keeper needs to materialise features.yaml during specify Stage 4b — after enrich-capabilities and before generate-intent-epics — or when any product-configuration workflow references authoring, updating, or regenerating the product feature catalog at .garura/...

Read, create, close, comment, resolve, or list GitHub issues with optional sub-issue attachment

Enumerate every test file in a codebase, extract test subjects and assertions, detect the test framework in use, and emit test-surface.yaml. Used by test-engineer.

Merge a pull request on the configured platform, switch to main, pull latest, and delete the feature branch (local and remote)