Skills.
StackWeavers ships work in six categories: build something new from scratch, modernize an old codebase, add to an existing one, migrate frameworks or dependencies, document what you already have, and refactor with full test coverage. Each skill has a typical CU cost range so you can plan and a clear when-to-use definition so you don't pick wrong.
Build new
Take a vision and ship a working product from zero.
Five-asset onboarding (Git, cloud, domain, brand, vision). Backlog refinement with a product owner. Vertical slices through database, API, frontend, tests, and deploy.
When to use: You have an idea and need a product. No team required.
Modernize old
Bring a legacy codebase up to current standards without breaking it.
Ingest the existing codebase. Map conventions and dependencies. Plan migrations as a series of safe vertical slices with full test coverage at each step.
When to use: You have a working codebase that's slowing the team down.
Add to existing
Build new features that match the patterns your team already uses.
Learn your conventions from the codebase. Ship features the way your team would have shipped them, through your existing CI/CD and PR review process. Each shipped feature is versioned and lineage-tracked from day one.
When to use: You have a team and a codebase and you want help shipping work.
Evolve
Iterate any shipped feature into v1.1, v1.2, v2.0 with full lineage.
Every feature is semver-versioned the moment it ships. Add behavior with a minor bump, break a contract with a major bump, fix a bug with a patch. Click any version to see the vision line that prompted it, the diff, and who approved it. Fork an experiment branch. Roll back in one click.
When to use: You shipped v1, learned from users, and want to evolve without losing the trail.
Migrate
Framework upgrades, dependency bumps, language version migrations.
Plan the migration as a series of independently shippable steps. Run quality gates on each step. Roll back per-step on failure.
When to use: You need to upgrade something major and the team keeps deferring it.
Document
Generate documentation that other developers and agents can use.
Architecture docs, API references, ADRs, onboarding guides. Written for the next engineer or the next agent to pick up the code.
When to use: Your codebase is hard to onboard new people (or new agents) into.
Refactor
Improve code quality without changing behavior, with full test coverage.
Behavior-preserving refactors. Tests added or strengthened first, refactor second, contract verified third.
When to use: You're carrying technical debt that's slowing the team down.