Build progress

Skill LuchoC-Dev/agent-kits/skills/build-progress

AI-first workspace bootstrapper — installs skills, packs, agents, and disciplines into .agents/. Cross-compatible with Claude Code and OpenCode.

Install

npx -y skills add LuchoC-Dev/agent-kits --skill build-progress

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Creates and maintains a docs/build.md progress tracker for any software project. Use this skill proactively after completing any implementation task, phase, or feature — even if the user doesn't explicitly ask. Also trigger when the user says things like "actualiza build.md", "update build.md", "mark X as done", "marcar X como completo", "actualiza el progreso", "update progress", "create build.md", or "crea el build.md". At project start, use it to scaffold the full build.md from the project description or codebase. After any task completes, use it to mark that task/stage as done and keep the file in sync.

SKILL.md

4.1 KB, as published. Nobody here has run it

Purpose

Maintain a single source of truth for project build progress at docs/build.md. The file has two parts: a summary table and a detailed checklist. Both must always be in sync.

Two modes

Mode A — Create (docs/build.md does not exist)

Check if docs/build.md exists. If not, this is Mode A.
Understand the project's planned phases and tasks from:
- The current conversation (user description, prior work done)
- Existing docs (README, CLAUDE.md, any planning docs)
- The codebase structure (folders, files already present)
Infer which stages are already complete based on what exists in the codebase.
Create docs/ if it doesn't exist.
Write docs/build.md using the format below.

Mode B — Update (docs/build.md exists)

Read the current docs/build.md.
Determine what was just completed from the conversation context.
For each completed item:
- In the table: change ⚪ → ✅, update % to 100%
- In the detail section: change [ ] → [x] for each completed checkbox
If a phase has all stages complete, the phase row itself should show ✅ 100%.
Write the updated file.

Format

# Build Progress

## Estados

- ⚪ Pendiente
- 🔵 En progreso
- ✅ Completado

---

| Fase                     | N°  | Etapa                  | Estado | %    | Descripción                          |
| ------------------------ | --- | ---------------------- | :----: | :--: | ------------------------------------ |
| **1 — Initial Setup**    | 1.1 | Project scaffold       |   ✅   | 100% | Folder structure, config, entry point |
|                          | 1.2 | Dependencies           |   ✅   | 100% | Package manager, core libs            |
| **2 — Domain**           | 2.1 | Entities               |   ⚪   | 0%   | Core domain models                    |
|                          | 2.2 | Business rules         |   ⚪   | 0%   | Validations and invariants            |

---

## Detalle por etapa

---

### Etapa 1 — Initial Setup

#### 1.1 Project scaffold

- [x] Create folder structure
- [x] Configure build tool (pom.xml / package.json / pyproject.toml / etc.)
- [x] Create entry point

#### 1.2 Dependencies

- [x] Add core dependencies
- [x] Add dev/test dependencies

---

### Etapa 2 — Domain

#### 2.1 Entities

- [ ] Define core entities
- [ ] Add fields and getters

#### 2.2 Business rules

- [ ] Add validation logic
- [ ] Add invariants

Rules

Adapt language to the project: if the project uses Spanish (like the current one), keep headings in Spanish ("Etapa", "Fase", "Estados", etc.). If English, use English.
The table and the detail section must always be in sync — if the table says ✅ 100%, all checkboxes in that section must be [x].
Phase rows (e.g., **1 — Initial Setup**) don't have their own N° or status — the status lives at the stage level (1.1, 1.2, etc.).
Use ⚪ for not started, 🔵 for in progress (some checkboxes done but not all), ✅ for complete.
% should be 0%, 50%, or 100% — avoid intermediate values unless you have specific evidence.
Keep descriptions short (≤ 8 words).
Checkboxes in the detail section should be concrete and verifiable, not vague.
Don't add phases or tasks that haven't been planned — only document what's real.
After writing the file, confirm to the user with a one-line summary: "✅ build.md updated — etapa X.Y marcada como completa." or similar.