code-writing

Name: code-writing
Author: pavel-molyanov

241stars75forks

How to install code-writing?

pavel-molyanov/molyanov-ai-dev/code-writing

$npx -y skills add pavel-molyanov/molyanov-ai-dev --skill code-writing

Installs into the current project.

Summary

Universal quality coding process: plan, TDD, reviews. Use whenever code needs to be written — ad-hoc or as part of a task. Use when: "напиши код", "закодь", "реализуй", "write code", "implement" Do NOT use for pure layout from Figma, Claude Design, screenshots, or an existing vis

Files · 1

View on GitHub

SKILL.md

1	<!-- Generated by sync-to-codex v1. Do not edit directly. -->
2
3	# Code Writing
4
5	## Phase 1: Preparation
6
7	1. Parse Requirements
8	- Extract what needs to be built from user message or passed acceptance criteria
9	- Clarify ambiguities — ask user if unclear
10	- Formulate acceptance criteria (what "done" looks like)
11
12	2. Read Project Context (Graceful)
13
14	Working on a task? Read all files listed in the task's "Context" section — it already specifies everything needed.
15
16	Standalone (no task file)? Read (skip if missing):
17	- `.claude/skills/project-knowledge/references/project.md` — project overview
18	- `.claude/skills/project-knowledge/references/architecture.md` — system structure
19	- `.claude/skills/project-knowledge/references/patterns.md` — project conventions
20
21	Then read `.claude/skills/project-knowledge/SKILL.md` (if exists).
22	Consider which domain-specific guides are relevant to your task and read those
23	(e.g., `architecture.md` Data Model section for DB work, `ux-guidelines.md` for UI tasks).
24
25	No project patterns? Apply baseline from [universal-patterns.md](references/universal-patterns.md) — naming, error handling, structure.
26
27	3. Analyze & Review Approach
28
29	Before coding, output your findings:
30	- Grep for usages of code to be modified
31	- Read all files that will be changed
32	- Verify solution follows project patterns (or universal patterns)
33	- Identify existing code that can be reused
34	- If modifying existing code, run existing tests for the area to establish baseline
35
36	If concerns → discuss with user before proceeding.
37
38	Checkpoint: List completed preparation steps before moving to implementation.
39
40	## Phase 2: Implementation (TDD)
41
42	1. Write Tests First
43
44	Before writing tests, read [testing-guide.md](references/testing-guide.md) — when to write which test type, test structure.
45
46	- Write tests for: business logic, validations, transforms, error handling. Skip trivial code without logic (simple getters, one-liners, configs)
47	- Write tests for requirements and edge cases
48	- Tests should fail initially (no implementation yet)
49	- One test = one scenario, test behavior not implementation
50	- If mocking >3 dependencies → wrong test type, use integration test
51
52	2. Critique Tests (before writing code)
53
54	Spawn a fresh `test-reviewer` in `design` mode. No implementation exists yet, so it
55	attacks test design (behavior-not-implementation, edge/error coverage, meaningful
56	assertions, right test type) rather than the litmus test, which needs running code.
57	Pass: paths to the test files you wrote + acceptance criteria.
58	Report path: `logs/working/task-{N}/test-reviewer-design-{round}.json`
59	(`{N}` = task number, `"standalone"` if no task file). This phase's 2-round cap is
60	independent of the Phase 3 code-review cap — each critic phase gets its own two rounds.
61
62	Process findings by the Phase 3 "Process Findings" rules (in-scope fix / disagree →
63	discuss / out-of-scope → surface to user). Strengthen the tests, then spawn a new
64	`test-reviewer` for the next round — a fresh instance, not the same one.
65	Limit: 2 rounds. If in-scope findings remain after round 2 → ask the user before
66	writing code. Reason: catching a hollow test now is cheaper than discovering after
67	the code is built that the tests never protected it.
68
69	3. Write Code
70	- Implement to pass tests
71	- Follow project patterns (from Phase 1) or apply baseline from [universal-patterns.md](references/universal-patterns.md)
72	- Use env vars for secrets, validate inputs at boundaries
73	- Handle edge cases, comment WHY not WHAT
74
75	4. Run Tests
76	- All new tests pass
77	- Fix any failures
78
79	Checkpoint: List implemented functionality and test results.
80
81	## Phase 3: Post-work
82
83	1. Run Lint/Format
84	- Run project's linter and formatter before reviews
85
86	2. Run Relevant Tests
87	- Tests for files changed
88	- Tests mentioned in task (if applicable)
89	- Save full test suite for end of feature
90
91	3. Smoke Verification (if task has Verification Steps → Smoke or User)
92
93	Execute each command from the Smoke section. Record results in decisions.md Verification section.
94	If a check fails — fix the code before proceeding to reviews.
95	If the task has User checks — ask the user to verify, wait for confirmation.
96
97	Smoke catches integration bugs that mocked tests miss:

People who liked this also viewed

6 picks

Type

code-writing

241stars75forks

View on GitHub

How to install code-writing?

pavel-molyanov/molyanov-ai-dev/code-writing

$npx -y skills add pavel-molyanov/molyanov-ai-dev --skill code-writing

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	<!-- Generated by sync-to-codex v1. Do not edit directly. -->
2
3	# Code Writing
4
5	## Phase 1: Preparation
6
7	1. Parse Requirements
8	- Extract what needs to be built from user message or passed acceptance criteria
9	- Clarify ambiguities — ask user if unclear
10	- Formulate acceptance criteria (what "done" looks like)
11
12	2. Read Project Context (Graceful)
13
14	Working on a task? Read all files listed in the task's "Context" section — it already specifies everything needed.
15
16	Standalone (no task file)? Read (skip if missing):
17	- `.claude/skills/project-knowledge/references/project.md` — project overview
18	- `.claude/skills/project-knowledge/references/architecture.md` — system structure
19	- `.claude/skills/project-knowledge/references/patterns.md` — project conventions
20
21	Then read `.claude/skills/project-knowledge/SKILL.md` (if exists).
22	Consider which domain-specific guides are relevant to your task and read those
23	(e.g., `architecture.md` Data Model section for DB work, `ux-guidelines.md` for UI tasks).
24
25	No project patterns? Apply baseline from [universal-patterns.md](references/universal-patterns.md) — naming, error handling, structure.
26
27	3. Analyze & Review Approach
28
29	Before coding, output your findings:
30	- Grep for usages of code to be modified
31	- Read all files that will be changed
32	- Verify solution follows project patterns (or universal patterns)
33	- Identify existing code that can be reused
34	- If modifying existing code, run existing tests for the area to establish baseline
35
36	If concerns → discuss with user before proceeding.
37
38	Checkpoint: List completed preparation steps before moving to implementation.
39
40	## Phase 2: Implementation (TDD)
41
42	1. Write Tests First
43
44	Before writing tests, read [testing-guide.md](references/testing-guide.md) — when to write which test type, test structure.
45
46	- Write tests for: business logic, validations, transforms, error handling. Skip trivial code without logic (simple getters, one-liners, configs)
47	- Write tests for requirements and edge cases
48	- Tests should fail initially (no implementation yet)
49	- One test = one scenario, test behavior not implementation
50	- If mocking >3 dependencies → wrong test type, use integration test
51
52	2. Critique Tests (before writing code)
53
54	Spawn a fresh `test-reviewer` in `design` mode. No implementation exists yet, so it
55	attacks test design (behavior-not-implementation, edge/error coverage, meaningful
56	assertions, right test type) rather than the litmus test, which needs running code.
57	Pass: paths to the test files you wrote + acceptance criteria.
58	Report path: `logs/working/task-{N}/test-reviewer-design-{round}.json`
59	(`{N}` = task number, `"standalone"` if no task file). This phase's 2-round cap is
60	independent of the Phase 3 code-review cap — each critic phase gets its own two rounds.
61
62	Process findings by the Phase 3 "Process Findings" rules (in-scope fix / disagree →
63	discuss / out-of-scope → surface to user). Strengthen the tests, then spawn a new
64	`test-reviewer` for the next round — a fresh instance, not the same one.
65	Limit: 2 rounds. If in-scope findings remain after round 2 → ask the user before
66	writing code. Reason: catching a hollow test now is cheaper than discovering after
67	the code is built that the tests never protected it.
68
69	3. Write Code
70	- Implement to pass tests
71	- Follow project patterns (from Phase 1) or apply baseline from [universal-patterns.md](references/universal-patterns.md)
72	- Use env vars for secrets, validate inputs at boundaries
73	- Handle edge cases, comment WHY not WHAT
74
75	4. Run Tests
76	- All new tests pass
77	- Fix any failures
78
79	Checkpoint: List implemented functionality and test results.
80
81	## Phase 3: Post-work
82
83	1. Run Lint/Format
84	- Run project's linter and formatter before reviews
85
86	2. Run Relevant Tests
87	- Tests for files changed
88	- Tests mentioned in task (if applicable)
89	- Save full test suite for end of feature
90
91	3. Smoke Verification (if task has Verification Steps → Smoke or User)
92
93	Execute each command from the Smoke section. Record results in decisions.md Verification section.
94	If a check fails — fix the code before proceeding to reviews.
95	If the task has User checks — ask the user to verify, wait for confirmation.
96
97	Smoke catches integration bugs that mocked tests miss:

People who liked this also viewed

6 picks

Type