interview-building-blocks

Estrellas11

Forks2

Actualizado8 de julio de 2026 a las 08:25

Funnel level 3 — identify building-block names and rough boundaries only, and run gap analysis.

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Fuente

nullhack

nullhack/temple8

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Desarrolladores de softwareOcupaciones informáticas y matemáticas·SOC 15-1252

SKILL.md

readonly

name	interview-building-blocks
description	Funnel level 3 — identify building-block names and rough boundaries only, and run gap analysis.

Interview (Building Blocks)

Load [[requirements/domain-decomposition]], [[requirements/aggregate-boundaries]], [[architecture/quality-attributes]], [[methodology/simplicity-discipline]] — gap analysis, boundary sizing, the quality-attribute taxonomy the coverage check runs over, and the simplicity discipline. This level is structural decomposition, not CIT/Laddering elicitation (those served levels 1–2).
Read the running interview-notes; append the building-block names and boundaries to it.
Capture building-block NAMES and rough boundaries ONLY — no detailed spec (rules, examples, criteria come later in planning). The purpose is to know WHAT building blocks exist, not to specify each.
Ask the simplicity question for each block: "Is this building block load-bearing, or could it collapse into a neighbour?" A block with no unique responsibility a cited need requires is speculative per [[methodology/simplicity-discipline]] — flag it for collapse into a neighbour or drop at consolidation. A block the cited need requires but no current block covers is a gap, flagged here (not silently filled).
Flag rework: IF a finding implies MODIFYING an existing block's behaviour (not adding a new one) THEN mark that block in the decomposition table as rework — modifies existing <block> and record the stakeholder's CIT-grounded reason. This is a requirements-level observation only — discovery does not touch tests. Plan reads these flags at author-test-stubs and marks the matching existing tests @pytest.mark.pending so the build backlog picks them up as rework per [[software-craft/tdd]]. A finding with no such flag is new work.
Run gap analysis: IF a bounded context from cross-cutting maps to no block THEN flag the gap; IF a quality attribute maps to no block THEN flag the gap. Do not silently fill gaps per [[requirements/domain-decomposition]], [[requirements/aggregate-boundaries]].

Más de este repositorio

mismo repositorio

simulate-contracts

nullhack/temple8

Compile the contract set in your head — simulate how the real application would run from the specs, and disprove (or confirm) it works before any source .py is written.

2026-07-0811

author-test-stubs

nullhack/temple8

Author test stub files (.pyi) whose signatures express the domain, relationships, and compositions, as the first contract surface.

2026-07-0811

interview-general

nullhack/temple8

Funnel level 1 — establish the big picture with seven broad questions, applying CIT, Laddering, and CI Perspective throughout.

2026-07-0811

merge-to-dev

nullhack/temple8

Squash-merge the feature commits into dev, regenerate docstrings, and verify the whole suite plus whole-suite stubtest are clean.

2026-07-0811

publish-release

nullhack/temple8

Publish the delivered batch as release notes, a PR to main, or a tagged release.

2026-07-0811

refresh-cycle

nullhack/temple8

Close the pipeline cycle: regenerate the living spec from current tests, summarize the carry-over cache files, regenerate source docstrings then strip all .py so the next cycle starts compact.

2026-07-0811

Interview (Building Blocks)

Load [[requirements/domain-decomposition]], [[requirements/aggregate-boundaries]], [[architecture/quality-attributes]], [[methodology/simplicity-discipline]] — gap analysis, boundary sizing, the quality-attribute taxonomy the coverage check runs over, and the simplicity discipline. This level is structural decomposition, not CIT/Laddering elicitation (those served levels 1–2).

Read the running interview-notes; append the building-block names and boundaries to it.

Capture building-block NAMES and rough boundaries ONLY — no detailed spec (rules, examples, criteria come later in planning). The purpose is to know WHAT building blocks exist, not to specify each.

Ask the simplicity question for each block: "Is this building block load-bearing, or could it collapse into a neighbour?" A block with no unique responsibility a cited need requires is speculative per [[methodology/simplicity-discipline]] — flag it for collapse into a neighbour or drop at consolidation. A block the cited need requires but no current block covers is a gap, flagged here (not silently filled).

Flag rework: IF a finding implies MODIFYING an existing block's behaviour (not adding a new one) THEN mark that block in the decomposition table as rework — modifies existing <block> and record the stakeholder's CIT-grounded reason. This is a requirements-level observation only — discovery does not touch tests. Plan reads these flags at author-test-stubs and marks the matching existing tests @pytest.mark.pending so the build backlog picks them up as rework per [[software-craft/tdd]]. A finding with no such flag is new work.

Run gap analysis: IF a bounded context from cross-cutting maps to no block THEN flag the gap; IF a quality attribute maps to no block THEN flag the gap. Do not silently fill gaps per [[requirements/domain-decomposition]], [[requirements/aggregate-boundaries]].