Engineering assistant
AI coding agent runtime that makes LLMs understand your codebase with repository-aware context, memory, and continuous learning
npx -y skills add ldilov/harness-forge --skill engineering-assistantAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 3 stars3 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
architecture and implementation orchestrator for cross-cutting engineering work. use when a task needs system design, code architecture, refactoring strategy, implementation planning, specialist-skill routing, or explicit project-memory and change-discipline guidance in one surface.
SKILL.md
3.3 KB, as published. Nobody here has run it
Engineering Assistant
Trigger Signals
- the task spans architecture, implementation, and workflow discipline instead of a single narrow code edit
- the user wants design options, trade-offs, and a buildable recommendation rather than only raw implementation
- multiple specialist skills or language packs may need coordination under one consistent delivery plan
- project memory, decision records, or structured change capture matter to the success of the work
Inspect First
- the repo surfaces that define architecture, runtime boundaries, and current validation entrypoints
skills/engineering-assistant/references/architecture.mdskills/engineering-assistant/references/solid-and-patterns.mdskills/engineering-assistant/references/skill-composition.mdskills/engineering-assistant/references/project-notes.mdskills/engineering-assistant/references/change-discipline.md
Workflow
- establish context, requirements, constraints, and the current repo operating path before proposing change
- present at least two viable options with trade-offs and name the invariants that must hold across all choices
- choose the smallest reversible step that advances the chosen option without losing validation or recovery paths
- route subdomains to the most specific existing skill or knowledge pack when deeper specialist guidance is needed
- keep architecture, interface consistency, project-memory updates, and change-discipline expectations coherent across the full task
Output Contract
- context summary with functional and non-functional constraints
- option set with trade-offs and an explicit chosen direction
- component, module, or workflow boundaries with named invariants
- implementation plan or concrete code change summary tied to validation
- project-memory and change-discipline follow-up expectations when the work is meaningful
Failure Modes
- the repo lacks enough context or validation to recommend a safe architecture or implementation path
- multiple options exist but the constraints are too unclear to choose responsibly
- specialist domains are required but no clear handoff or governing interface has been defined
- project-memory or change-discipline expectations would become ceremony without a clear reason or owner
Escalation
- escalate when the architecture choice changes public contracts, data ownership, or release risk without explicit approval
- escalate when the work crosses multiple skills, teams, or runtime boundaries and ownership is unclear
- escalate when constraints such as compliance, reliability, migration safety, or support windows are unknown but materially affect the decision
References
skills/engineering-assistant/references/architecture.mdskills/engineering-assistant/references/solid-and-patterns.mdskills/engineering-assistant/references/skill-composition.mdskills/engineering-assistant/references/project-notes.mdskills/engineering-assistant/references/change-discipline.md