Give it context
The agent reads the repository entrypoint and the guidance for the selected package or stack.
Lighthouse
A clear path to engineering excellence.
Proven techniques and best practices for a practical, AI-driven SDLC.
Engineering Excellence
Patterns, checks and examples for code, architecture, testing and design.
Explore practices 02 / ENVIRONMENTAgentic Development Environment
A local agent works with you in a repository, guided by versioned context and checks.
Explore the environment 03 / DELIVERYDelivery Workflows
Supervised workers carry an issue through implementation, evidence and review.
Explore workflows01 / ENGINEERING EXCELLENCE
Practices with a way to check them.
Take the parts that fit your product. Lighthouse keeps recommendations, reference examples and enforced rules distinct.
01Product intentTrace a change back to an accepted product model.↗
02Architecture & repository boundariesMake ownership and module dependencies visible.↗
03Testing & qualityExercise behavior and run the checks your stack supports.↗
04Dependencies & securitySee the .NET profile's locked restore, audit and explicit exceptions.↗
05Interface designUse semantic tokens, accessible states and native CSS recipes.↗
Keep module internals behind contracts.
In the .NET reference, Roslyn rule LH1002 rejects a sibling module implementation reference. A compiled architecture test checks the boundary too. Recommendations elsewhere in the profile are identified as such.
npm run verify:dotnet02 / AGENTIC DEVELOPMENT ENVIRONMENT
Work with an agent in your repository.
Instructions, skills and verification travel with the code. The developer still owns the request, scope and decision.
Keep the work bounded
Skills and commands describe the task, the files it owns and the evidence it should return.
Check the result
Run the relevant verifier and review the change before accepting it.
Ask for a .NET use case. The agent follows the repository and profile contracts, edits the selected slice, then reports the result of npm run verify:dotnet. The check provides feedback; it does not approve the change.
03 / DELIVERY WORKFLOWS
From issue to reviewed change.
With the selected workers installed, an owner requests a stage through GitHub. Each result links to the work and the next decision.
Triage
Assess the request and estimate it. Stop for the owner's decision.
Refine
Define acceptance criteria or ask a specific question.
Implement
Plan, change code and verify. Publish both plan and code in a draft PR.
PR & checks
Apply feedback in the same PR. Wait for required checks and owner approval.
Integrate
Assess the current approved head and merge only when authorized.
Review
After post-merge CI, record the retrospective and close the issue if passed.
Questions, future, human reservations and failed checks pause continuation. A passing worker run alone does not authorize merge.
propose opens a separate design PR when requested. Product Change, fast-forward and test-first hotfix are optional installations with their own gates.
THE BASE / RUN IT YOURSELF
Start locally. Add workers when you need them.
The baseline can live in your repository. Automation is a separate, selected installation.
Adopt the baseline
Initialize a repository, inspect the generated boundaries and run its local checks. Select stack profiles and external authorities only where they fit.
lighthouse init --name <product>
lighthouse verifyOpen the package guide Run the workers
Install selected SDLC workflows, review their configuration and provision a trusted runner and agent engine. The repository owner enables automation after setup.
Choose workflows See the single-host runtime example