engineering-principles

Name: engineering-principles
Author: omnigentx

31stars13forks

How to install engineering-principles?

omnigentx/jarvis/engineering-principles

$npx -y skills add omnigentx/jarvis --skill engineering-principles

Installs into the current project.

Summary

Four behavioral rules for Dev agents writing or modifying code. Bias toward caution over speed. Read BEFORE you touch source files.

Files · 1

View on GitHub

SKILL.md

1	# Engineering Principles
2
3	These rules reduce the most common LLM coding mistakes. They override speed —
4	if a rule slows you down, follow it anyway.
5
6	## 1. Think Before Coding
7
8	Don't assume. Don't hide confusion. Surface tradeoffs.
9
10	- State your assumptions explicitly in the PR/commit message. If uncertain, email the BA or SA — don't guess.
11	- If the spec admits multiple interpretations, list them and ask. Don't pick silently.
12	- If a simpler approach exists than what the spec requires, flag it. Push back when warranted.
13	- If something is unclear, stop and ask. One clarifying email costs less than a rewrite.
14
15	## 2. Simplicity First
16
17	Minimum code that solves the problem. Nothing speculative.
18
19	- No features beyond the Jira story's acceptance criteria.
20	- No abstractions for single-use code.
21	- No "flexibility" or "configurability" that wasn't requested.
22	- No error handling for scenarios that can't happen (trust internal code + framework guarantees).
23	- If you write 200 lines and it could be 50, rewrite it.
24
25	Self-check: "Would a senior engineer call this overcomplicated?" If yes, simplify.
26
27	## 3. Surgical Changes
28
29	Touch only what you must. Clean up only your own mess.
30
31	- Don't "improve" adjacent code, comments, or formatting.
32	- Don't refactor things that aren't broken.
33	- Match existing style, even if you'd do it differently.
34	- Unrelated dead code → mention it in the PR description, don't delete it.
35
36	When your changes create orphans:
37	- Remove imports/variables/functions that YOUR changes made unused.
38	- Don't remove pre-existing dead code unless the story asks for it.
39
40	Every changed line should trace directly to the Jira story.
41
42	## 4. Goal-Driven Execution
43
44	Define success criteria. Loop until verified.
45
46	Before writing code, restate the goal as a verifiable check:
47	- "Add validation" → "Write tests for invalid inputs, then make them pass" (TDD is mandatory anyway)
48	- "Fix the bug" → "Write a test that reproduces it, then make it pass"
49	- "Refactor X" → "Ensure tests pass before AND after, no behavior change"
50
51	For multi-step stories, write a short plan:
52	```
53	1. <step> → verify: <check>
54	2. <step> → verify: <check>
55	```
56
57	Strong success criteria let you work independently. Weak ones ("make it work")
58	mean you'll be rewriting after review.
59
60	## Integration with GitNexus (MANDATORY for Jarvis repo)
61
62	When the target codebase is indexed by GitNexus (look for `.gitnexus/` dir):
63
64	- Before editing any symbol → `gitnexus_impact({target: "symbolName", direction: "upstream"})`. Report blast radius in PR/commit. HIGH/CRITICAL risk → escalate to SA, don't proceed silently.
65	- Before renaming → `gitnexus_rename({..., dry_run: true})`. Review preview, then `dry_run: false`. Never find-and-replace.
66	- Before committing → `gitnexus_detect_changes()`. Confirm scope matches the story.
67	- When exploring → `gitnexus_query({query: "concept"})` and `gitnexus_context({name: "symbol"})` instead of grep.
68
69	If `.gitnexus/` is stale (tool warns): run `npx gitnexus analyze` in the repo first.
70
71	This is how you enforce Principle #3 (Surgical Changes) at scale — the call
72	graph tells you exactly what you're about to break.

People who liked this also viewed

6 picks

Type

engineering-principles

31stars13forks

View on GitHub

How to install engineering-principles?

omnigentx/jarvis/engineering-principles

$npx -y skills add omnigentx/jarvis --skill engineering-principles

Installs into the current project.

Summary

Four behavioral rules for Dev agents writing or modifying code. Bias toward caution over speed. Read BEFORE you touch source files.

Files · 1

View on GitHub

SKILL.md

1	# Engineering Principles
2
3	These rules reduce the most common LLM coding mistakes. They override speed —
4	if a rule slows you down, follow it anyway.
5
6	## 1. Think Before Coding
7
8	Don't assume. Don't hide confusion. Surface tradeoffs.
9
10	- State your assumptions explicitly in the PR/commit message. If uncertain, email the BA or SA — don't guess.
11	- If the spec admits multiple interpretations, list them and ask. Don't pick silently.
12	- If a simpler approach exists than what the spec requires, flag it. Push back when warranted.
13	- If something is unclear, stop and ask. One clarifying email costs less than a rewrite.
14
15	## 2. Simplicity First
16
17	Minimum code that solves the problem. Nothing speculative.
18
19	- No features beyond the Jira story's acceptance criteria.
20	- No abstractions for single-use code.
21	- No "flexibility" or "configurability" that wasn't requested.
22	- No error handling for scenarios that can't happen (trust internal code + framework guarantees).
23	- If you write 200 lines and it could be 50, rewrite it.
24
25	Self-check: "Would a senior engineer call this overcomplicated?" If yes, simplify.
26
27	## 3. Surgical Changes
28
29	Touch only what you must. Clean up only your own mess.
30
31	- Don't "improve" adjacent code, comments, or formatting.
32	- Don't refactor things that aren't broken.
33	- Match existing style, even if you'd do it differently.
34	- Unrelated dead code → mention it in the PR description, don't delete it.
35
36	When your changes create orphans:
37	- Remove imports/variables/functions that YOUR changes made unused.
38	- Don't remove pre-existing dead code unless the story asks for it.
39
40	Every changed line should trace directly to the Jira story.
41
42	## 4. Goal-Driven Execution
43
44	Define success criteria. Loop until verified.
45
46	Before writing code, restate the goal as a verifiable check:
47	- "Add validation" → "Write tests for invalid inputs, then make them pass" (TDD is mandatory anyway)
48	- "Fix the bug" → "Write a test that reproduces it, then make it pass"
49	- "Refactor X" → "Ensure tests pass before AND after, no behavior change"
50
51	For multi-step stories, write a short plan:
52	```
53	1. <step> → verify: <check>
54	2. <step> → verify: <check>
55	```
56
57	Strong success criteria let you work independently. Weak ones ("make it work")
58	mean you'll be rewriting after review.
59
60	## Integration with GitNexus (MANDATORY for Jarvis repo)
61
62	When the target codebase is indexed by GitNexus (look for `.gitnexus/` dir):
63
64	- Before editing any symbol → `gitnexus_impact({target: "symbolName", direction: "upstream"})`. Report blast radius in PR/commit. HIGH/CRITICAL risk → escalate to SA, don't proceed silently.
65	- Before renaming → `gitnexus_rename({..., dry_run: true})`. Review preview, then `dry_run: false`. Never find-and-replace.
66	- Before committing → `gitnexus_detect_changes()`. Confirm scope matches the story.
67	- When exploring → `gitnexus_query({query: "concept"})` and `gitnexus_context({name: "symbol"})` instead of grep.
68
69	If `.gitnexus/` is stale (tool warns): run `npx gitnexus analyze` in the repo first.
70
71	This is how you enforce Principle #3 (Surgical Changes) at scale — the call
72	graph tells you exactly what you're about to break.

People who liked this also viewed

6 picks

Type