@artale/pi-real-engineering 0.1.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md ADDED
@@ -0,0 +1,36 @@
1
+ # @artale/pi-real-engineering
2
+
3
+ Minimal Pi skills for real engineering: align first, build in small feedback loops, keep domain language sharp, and improve the harness before blaming the model.
4
+
5
+ ## Install
6
+
7
+ ```bash
8
+ pi install npm:@artale/pi-real-engineering
9
+ ```
10
+
11
+ Local test:
12
+
13
+ ```bash
14
+ pi install C:/Users/Artale/Projects/gh-repo/packages/pi-real-engineering
15
+ /reload
16
+ ```
17
+
18
+ ## Skills
19
+
20
+ | Skill | Invocation | Purpose |
21
+ |---|---|---|
22
+ | `setup-artale-skills` | user | Create repo conventions: `AGENTS.md`, `CONTEXT.md`, `docs/adr/`, `.pi/plans/` |
23
+ | `grill-with-docs` | user | Interview the user against docs/context before implementation |
24
+ | `tdd` | model | Red-green-refactor one vertical slice at a time |
25
+ | `diagnosing-bugs` | model | Reproduce, minimize, hypothesize, instrument, fix |
26
+ | `domain-modeling` | model | Maintain shared language in `CONTEXT.md` and ADRs |
27
+ | `codebase-design` | model | Design deep modules with small interfaces and clean seams |
28
+
29
+ ## Conventions
30
+
31
+ - `CONTEXT.md` = shared domain language, not implementation scratchpad.
32
+ - `docs/adr/*.md` = durable architectural decisions.
33
+ - `.pi/plans/*.md` = temporary plans/spikes before durable decisions.
34
+ - `AGENTS.md` = Pi-facing repo rules; mention `CLAUDE.md` only for compatibility.
35
+
36
+ No runtime dependencies. No command extension. Skills only.
package/package.json ADDED
@@ -0,0 +1,15 @@
1
+ {
2
+ "name": "@artale/pi-real-engineering",
3
+ "version": "0.1.0",
4
+ "description": "Minimal Pi skills for real engineering loops: setup, docs grilling, TDD, debugging, domain modeling, and codebase design.",
5
+ "license": "MIT",
6
+ "type": "module",
7
+ "keywords": ["pi-package", "pi", "pi-skill", "engineering", "tdd", "debugging", "domain-modeling"],
8
+ "files": ["README.md", "skills/**/*"],
9
+ "peerDependencies": {
10
+ "@earendil-works/pi-coding-agent": "*"
11
+ },
12
+ "pi": {
13
+ "skills": ["./skills"]
14
+ }
15
+ }
@@ -0,0 +1,10 @@
1
+ # Deepening
2
+
3
+ Move complexity behind a smaller interface. Replace pass-through layers with modules that earn their existence.
4
+
5
+ Checklist:
6
+
7
+ - name the callers
8
+ - shrink the interface
9
+ - hide more implementation detail
10
+ - keep tests crossing the same seam callers use
@@ -0,0 +1,13 @@
1
+ # Design It Twice
2
+
3
+ Before changing architecture, sketch two different interfaces.
4
+
5
+ Compare:
6
+
7
+ - depth
8
+ - locality
9
+ - testability
10
+ - migration cost
11
+ - how much domain language the interface exposes
12
+
13
+ Pick the option that gives callers more leverage with less surface area.
@@ -0,0 +1,28 @@
1
+ ---
2
+ name: codebase-design
3
+ description: Design deep modules with small interfaces and clean seams. Use for architecture, refactoring, testability, or module/interface decisions.
4
+ ---
5
+
6
+ # Codebase Design
7
+
8
+ Design deep modules: a lot of behavior behind a small interface at a clean seam.
9
+
10
+ ## Vocabulary
11
+
12
+ - Module — anything with an interface and implementation
13
+ - Interface — everything callers must know
14
+ - Implementation — what sits behind the interface
15
+ - Seam — where behavior can vary
16
+ - Adapter — concrete thing at a seam
17
+ - Depth — leverage per unit of interface
18
+
19
+ ## Process
20
+
21
+ 1. Read `CONTEXT.md` and relevant ADRs.
22
+ 2. Identify the module and its callers.
23
+ 3. Apply the deletion test: if removed, does complexity vanish or spread?
24
+ 4. Design two interface options.
25
+ 5. Pick the deeper interface.
26
+ 6. Verify through the interface, not internals.
27
+
28
+ See `DEEPENING.md` and `DESIGN-IT-TWICE.md`.
@@ -0,0 +1,24 @@
1
+ ---
2
+ name: diagnosing-bugs
3
+ description: Disciplined bug diagnosis. Use for broken, failing, slow, or flaky behavior.
4
+ ---
5
+
6
+ # Diagnosing Bugs
7
+
8
+ Do not jump to a theory before a red-capable loop exists.
9
+
10
+ ## Phases
11
+
12
+ 1. Build one command that can reproduce the bug.
13
+ 2. Confirm it fails for the user's exact symptom.
14
+ 3. Minimize the repro.
15
+ 4. List 3-5 falsifiable hypotheses.
16
+ 5. Instrument one hypothesis at a time.
17
+ 6. Fix and convert the repro into a regression check.
18
+ 7. Remove debug logs/prototypes.
19
+
20
+ ## Required final evidence
21
+
22
+ - original repro command now passes or no longer reproduces
23
+ - regression check passes, or no valid seam exists and is reported
24
+ - debug instrumentation removed
@@ -0,0 +1,15 @@
1
+ # ADR format
2
+
3
+ # YYYY-MM-DD: Decision title
4
+
5
+ ## Status
6
+ Accepted | Proposed | Superseded
7
+
8
+ ## Context
9
+ What forced the decision?
10
+
11
+ ## Decision
12
+ What did we choose?
13
+
14
+ ## Consequences
15
+ What gets easier/harder?
@@ -0,0 +1,13 @@
1
+ # CONTEXT.md format
2
+
3
+ ## Glossary
4
+ - Term — precise meaning
5
+
6
+ ## Entities
7
+ - Entity — relationships and invariants
8
+
9
+ ## Workflows
10
+ - Workflow — domain steps, not implementation details
11
+
12
+ ## Open questions
13
+ - Question — owner/status
@@ -0,0 +1,22 @@
1
+ ---
2
+ name: domain-modeling
3
+ description: Maintain shared domain language in CONTEXT.md and ADRs. Use when terminology, invariants, or architectural decisions need sharpening.
4
+ ---
5
+
6
+ # Domain Modeling
7
+
8
+ `CONTEXT.md` is a glossary and domain map, not a spec or scratchpad.
9
+
10
+ ## Use this skill to
11
+
12
+ - challenge vague or overloaded terms
13
+ - define canonical domain language
14
+ - record invariants and edge-case scenarios
15
+ - create ADRs only for hard-to-reverse, surprising, real trade-off decisions
16
+
17
+ ## Files
18
+
19
+ - `CONTEXT.md` for terms, entities, invariants, workflows, open questions
20
+ - `docs/adr/YYYY-MM-DD-short-title.md` for durable decisions
21
+
22
+ See `CONTEXT-FORMAT.md` and `ADR-FORMAT.md`.
@@ -0,0 +1,31 @@
1
+ ---
2
+ name: grill-with-docs
3
+ description: User-invoked interview before implementation. Reads docs/context, asks hard questions, and resolves ambiguity before work starts.
4
+ disable-model-invocation: true
5
+ ---
6
+
7
+ # Grill With Docs
8
+
9
+ Do not implement. Interview until the task is sharp enough to hand to an agent.
10
+
11
+ ## Process
12
+
13
+ 1. Read `CONTEXT.md`, relevant ADRs, `.pi/plans/`, and nearby docs.
14
+ 2. Restate the goal in one paragraph.
15
+ 3. Ask 3-7 hard questions, one group at a time:
16
+ - desired behavior
17
+ - non-goals
18
+ - affected modules/interfaces
19
+ - data/state changes
20
+ - verification command
21
+ - rollback/risk
22
+ 4. Call out contradictions between user language, docs, and code.
23
+ 5. End with a concise plan or “not ready yet”.
24
+
25
+ ## Output
26
+
27
+ - Shared understanding
28
+ - Open decisions
29
+ - Verification command
30
+ - Files likely touched
31
+ - Whether to use `tdd`, `diagnosing-bugs`, `domain-modeling`, or `codebase-design` next
@@ -0,0 +1,50 @@
1
+ ---
2
+ name: setup-artale-skills
3
+ description: Configure a repo for Artale real-engineering skills: AGENTS.md rules, issue workflow, CONTEXT.md, ADRs, and .pi/plans. User-invoked setup procedure.
4
+ disable-model-invocation: true
5
+ ---
6
+
7
+ # Setup Artale Skills
8
+
9
+ Prompt-driven setup. Explore first, ask before writing, then make the smallest durable conventions.
10
+
11
+ ## Explore
12
+
13
+ Check:
14
+
15
+ - `git remote -v` / `.git/config`
16
+ - `AGENTS.md`, `CLAUDE.md`
17
+ - `CONTEXT.md`, `CONTEXT-MAP.md`
18
+ - `docs/adr/`
19
+ - `docs/agents/`
20
+ - `.pi/plans/`
21
+
22
+ ## Ask one decision at a time
23
+
24
+ 1. **Issue workflow**: GitHub (`gh`), GitLab (`glab`), local markdown, or other.
25
+ 2. **Docs layout**: single-context `CONTEXT.md` or multi-context `CONTEXT-MAP.md`.
26
+ 3. **Verifier strictness**: strict by default; PASS requires real checks.
27
+
28
+ ## Write
29
+
30
+ Prefer `AGENTS.md`. If only `CLAUDE.md` exists, update it for compatibility. Do not create both unless the user asks.
31
+
32
+ Create lazily:
33
+
34
+ - `CONTEXT.md`
35
+ - `docs/adr/`
36
+ - `.pi/plans/`
37
+ - `docs/agents/issue-tracker.md`
38
+ - `docs/agents/domain.md`
39
+
40
+ ## Agent skills block
41
+
42
+ ```md
43
+ ## Agent skills
44
+
45
+ - Use `CONTEXT.md` for domain language before planning.
46
+ - Use `docs/adr/` for durable architectural decisions.
47
+ - Use `.pi/plans/` for temporary plans/spikes.
48
+ - Use `tdd` for behavior changes, `diagnosing-bugs` for bugs, `codebase-design` for module/interface work.
49
+ - Do not return PASS unless checks actually ran.
50
+ ```
@@ -0,0 +1,11 @@
1
+ # GitHub issue workflow
2
+
3
+ Use `gh issue` for issue creation, listing, and updates.
4
+
5
+ Default labels:
6
+
7
+ - `needs-triage`
8
+ - `needs-info`
9
+ - `ready-for-agent`
10
+ - `ready-for-human`
11
+ - `wontfix`
@@ -0,0 +1,11 @@
1
+ # GitLab issue workflow
2
+
3
+ Use `glab issue` for issue creation, listing, and updates.
4
+
5
+ Default labels:
6
+
7
+ - `needs-triage`
8
+ - `needs-info`
9
+ - `ready-for-agent`
10
+ - `ready-for-human`
11
+ - `wontfix`
@@ -0,0 +1,11 @@
1
+ # Local issue workflow
2
+
3
+ Store issues as markdown under `.scratch/issues/`.
4
+
5
+ Each issue should include:
6
+
7
+ - title
8
+ - status
9
+ - owner
10
+ - acceptance criteria
11
+ - verification command
@@ -0,0 +1,7 @@
1
+ # Triage labels
2
+
3
+ - `needs-triage` — maintainer must evaluate
4
+ - `needs-info` — waiting on reporter/user
5
+ - `ready-for-agent` — fully specified and AFK-ready
6
+ - `ready-for-human` — needs human judgment/implementation
7
+ - `wontfix` — will not be actioned
@@ -0,0 +1,26 @@
1
+ ---
2
+ name: tdd
3
+ description: Red-green-refactor for features and fixes. Use when behavior changes need a tight feedback loop.
4
+ ---
5
+
6
+ # TDD
7
+
8
+ One vertical slice at a time. Tests verify behavior through public interfaces, not implementation details.
9
+
10
+ ## Loop
11
+
12
+ 1. Read `CONTEXT.md` and relevant ADRs.
13
+ 2. Name the public behavior.
14
+ 3. Write one failing test or smallest red-capable check.
15
+ 4. Run it and confirm it fails for the right reason.
16
+ 5. Write the least code to pass.
17
+ 6. Refactor only while green.
18
+ 7. Repeat.
19
+
20
+ ## Rules
21
+
22
+ - No bulk “write all tests first”.
23
+ - No private-method tests unless there is no usable seam; if so, report the seam problem.
24
+ - One runnable command must prove the final state.
25
+
26
+ See `tests.md`, `mocking.md`, and `refactoring.md`.
@@ -0,0 +1,5 @@
1
+ # Mocking
2
+
3
+ Mock network, time, randomness, and external services.
4
+
5
+ Do not mock the module you are trying to gain confidence in. If the only way to test is to mock internals, report the seam problem instead.
@@ -0,0 +1,9 @@
1
+ # Refactoring
2
+
3
+ Refactor only when green.
4
+
5
+ - remove duplication
6
+ - deepen modules
7
+ - simplify interfaces
8
+ - improve naming with domain language
9
+ - rerun the same verification command after each step
@@ -0,0 +1,5 @@
1
+ # Tests
2
+
3
+ Good tests describe observable behavior through public interfaces. Bad tests mirror implementation shape.
4
+
5
+ Prefer integration-style tests at the smallest useful seam. Each test should fail for a user-visible reason and survive internal refactors.