gjalla-breakdown
gjalla-breakdown decomposes a completed feature specification into sequential waves of parallel, dependency-ordered tasks with specific file targets and acceptance criteria. Use this skill after finalizing a spec to create an implementation roadmap that tracks progress, ensures logical ordering of work, and keeps individual tasks small enough for straightforward code review and verification.
git clone --depth 1 https://github.com/gjalla/engineering /tmp/gjalla-breakdown && cp -r /tmp/gjalla-breakdown/skills/gjalla-breakdown ~/.claude/skills/gjalla-breakdownSKILL.md
# Wave-Based Task Breakdown Break the feature into sized, dependency-ordered task waves. This makes it easier to keep track of progress as we build so we ensure that we're on track to build what the user expects: ## Process 1. **Read the spec**: Identify all behavioral requirements and technical changes from the agent plan or gjalla spec. 2. **Identify tasks**: Each task should touch 1-2 files and produce a small, reviewable diff that's verifiable. 3. **Map dependencies**: Which tasks must complete before others can start? 4. **Group into waves**: Tasks within a wave can be done in parallel; waves are sequential. ## Task Format Waves of work comprise groups of tasks: - **ID**: W1-T1, W1-T2, W2-T1, etc. - **Description**: One-line summary of what changes. - **Files**: Exact file paths that will be modified or created. - **Depends On**: Task IDs this depends on (within same wave = none). - **Acceptance**: How to verify this task is done. ## Principles - Waves help you group tasks into logical/modular sections so you can put them in an intuitive order. For instance, data model changes might need to come first so the rest of the waves have the foundation they need to build on. - The waves and tasks should have a place to mark once complete so that we can easily see our status as we implement. - Make sure that docs, verification, tests, etc are included in your breakdown. To avoid overload, try to keep the total task count under 20 for a single spec; split larger features into multiple specs.
Create a commit attestation for your changes
Load architecture context for this repo
Master-spec delta — what changes in the system when this merges
Show recent semantic change history
Review a spec OR a code change against master spec, rules, and production readiness
Initialize gjalla in this repo
Review a code change (diff or PR) for ship-readiness before merge. Use when reviewing your own or someone else's changes prior to committing/merging/etc.
Make sure your code is ready to commit, then stage changes into clean, atomic commit. Use before committing.