methodology

Name: methodology
Author: pavel-molyanov

241stars75forks

How to install methodology?

pavel-molyanov/molyanov-ai-dev/methodology

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

Installs into the current project.

Summary

AI-First development methodology: spec-driven pipeline, project structure, skills/agents ecosystem, quality gates. Use when: "изучи методологию", "изучи глобальную папку", "как работает методология", "how does the methodology work", "explain the workflow" For infrastructure tasks

Files · 1

View on GitHub

SKILL.md

1	<!-- Generated by sync-to-codex v1. Do not edit directly. -->
2
3	# AI-First Development Methodology
4
5	## What Is This
6
7	A structured development approach for AI agents. Every feature goes through a pipeline: idea → spec → architecture → tasks → implementation → documentation update. Each stage has automated validators and quality gates. QA and deploy are regular tasks in the tech-spec, not separate pipeline steps.
8
9	Core problems it solves:
10	- Context loss between sessions — distributed knowledge base persists across sessions
11	- Quality without human review — automated validators at every stage
12	- Scope creep — specs approved before coding starts
13	- Outdated agent knowledge — Context7 MCP fetches current library docs
14
15	---
16
17	## Development Pipeline
18
19	The full path from idea to production. Each step has a command, a skill behind it, and validators.
20
21	### Step 1: User Spec — `/new-user-spec`
22
23	What: Structured interview to capture requirements in human-readable form (in the user's language).
24
25	Process:
26	- Agent reads Project Knowledge files to understand the project
27	- Scans codebase for relevant code, patterns, integration points
28	- Runs 3 interview cycles with the user (general → code-informed → edge cases)
29	- `interview-completeness-checker` agent verifies coverage
30	- Creates `user-spec.md` from interview data → git commit draft
31	- 2 validators run in parallel (up to 3 iterations):
32	- `userspec-quality-validator` — document structure, acceptance criteria testability
33	- `userspec-adequacy-validator` — solution feasibility, over/underengineering
34	- Git commit after each validation round
35	- User approves → git commit approval (status: approved)
36
37	Output: `work/{feature}/user-spec.md` (status: approved)
38
39	Skill: `user-spec-planning`
40
41	### Step 2: Tech Spec — `/new-tech-spec`
42
43	What: Technical architecture, decisions, testing strategy, implementation plan.
44
45	Process:
46	- Reads approved user-spec
47	- Researches codebase, checks dependencies, uses Context7 for external libraries
48	- Asks technical clarification questions
49	- Copies tech-spec template, edits sections in place → `tech-spec.md` with architecture (including Shared Resources for heavy objects like ML models, DB pools), decisions, testing strategy, brief Implementation Tasks (scope only — AC and TDD are added during task-decomposition) → git commit draft
50	- Implementation Tasks include Verify-smoke (executable checks: curl, python -c, docker) and Verify-user (manual UI/UX checks) fields where applicable
51	- Last two waves are always Audit Wave (3 parallel auditors: code, security, test) and Final Wave (QA + deploy)
52	- 5 validators run in parallel (up to 3 iterations):
53	- `skeptic` — detects non-existent files, functions, APIs (mirages)
54	- `completeness-validator` — bidirectional requirements traceability, over/underengineering, solution depth
55	- `security-auditor` — OWASP Top 10 review
56	- `test-reviewer` — test plan adequacy
57	- `tech-spec-validator` — template compliance, task quality, wave conflict detection
58	- Git commit after each validation round
59	- User approves → git commit approval (status: approved)
60
61	Output: `work/{feature}/tech-spec.md` (status: approved)
62
63	Skill: `tech-spec-planning`
64
65	### Step 3: Task Decomposition — `/decompose-tech-spec`
66
67	What: Break tech-spec into atomic task files.
68
69	Process:
70	- For each Implementation Task in tech-spec, `task-creator` agent copies task template and fills it (parallel)
71	- Each task file expands brief tech-spec scope into: acceptance criteria, TDD anchor (from Testing Strategy), context files, skills, reviewers, wave, dependencies → git commit draft
72	- 2 validators run in parallel (up to 3 iterations):
73	- `task-validator` — template compliance, content quality
74	- `reality-checker` — validates against actual codebase (file existence, feasibility)
75	- Cross-task integration check: both validators re-run on all tasks together — catches shared resource conflicts, duplicate heavy resource init, hidden dependencies (max 2 extra iterations)
76	- Git commit after each validation round
77	- User approves → git commit approval
78
79	Output: `work/{feature}/tasks/*.md` (validated)
80
81	Skill: `task-decomposition`
82
83	### Step 4: Implementation
84
85	Choose `/do-task` when: single task, manual control, debugging, iterating on one piece.
86	Choose `/do-feature` when: multiple tasks ready, standard feature work, want parallel execution.
87
88	Two modes:
89
90	#### Mode A: Single Task — `/do-task`
91
92	One task per session. Suited for manual, controlled execution.
93
94	Process:
95	- Reads task file and all its Context Files
96	- Loads skills specified in

People who liked this also viewed

6 picks

Type

methodology

241stars75forks

View on GitHub

How to install methodology?

pavel-molyanov/molyanov-ai-dev/methodology

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

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	# AI-First Development Methodology
4
5	## What Is This
6
7	A structured development approach for AI agents. Every feature goes through a pipeline: idea → spec → architecture → tasks → implementation → documentation update. Each stage has automated validators and quality gates. QA and deploy are regular tasks in the tech-spec, not separate pipeline steps.
8
9	Core problems it solves:
10	- Context loss between sessions — distributed knowledge base persists across sessions
11	- Quality without human review — automated validators at every stage
12	- Scope creep — specs approved before coding starts
13	- Outdated agent knowledge — Context7 MCP fetches current library docs
14
15	---
16
17	## Development Pipeline
18
19	The full path from idea to production. Each step has a command, a skill behind it, and validators.
20
21	### Step 1: User Spec — `/new-user-spec`
22
23	What: Structured interview to capture requirements in human-readable form (in the user's language).
24
25	Process:
26	- Agent reads Project Knowledge files to understand the project
27	- Scans codebase for relevant code, patterns, integration points
28	- Runs 3 interview cycles with the user (general → code-informed → edge cases)
29	- `interview-completeness-checker` agent verifies coverage
30	- Creates `user-spec.md` from interview data → git commit draft
31	- 2 validators run in parallel (up to 3 iterations):
32	- `userspec-quality-validator` — document structure, acceptance criteria testability
33	- `userspec-adequacy-validator` — solution feasibility, over/underengineering
34	- Git commit after each validation round
35	- User approves → git commit approval (status: approved)
36
37	Output: `work/{feature}/user-spec.md` (status: approved)
38
39	Skill: `user-spec-planning`
40
41	### Step 2: Tech Spec — `/new-tech-spec`
42
43	What: Technical architecture, decisions, testing strategy, implementation plan.
44
45	Process:
46	- Reads approved user-spec
47	- Researches codebase, checks dependencies, uses Context7 for external libraries
48	- Asks technical clarification questions
49	- Copies tech-spec template, edits sections in place → `tech-spec.md` with architecture (including Shared Resources for heavy objects like ML models, DB pools), decisions, testing strategy, brief Implementation Tasks (scope only — AC and TDD are added during task-decomposition) → git commit draft
50	- Implementation Tasks include Verify-smoke (executable checks: curl, python -c, docker) and Verify-user (manual UI/UX checks) fields where applicable
51	- Last two waves are always Audit Wave (3 parallel auditors: code, security, test) and Final Wave (QA + deploy)
52	- 5 validators run in parallel (up to 3 iterations):
53	- `skeptic` — detects non-existent files, functions, APIs (mirages)
54	- `completeness-validator` — bidirectional requirements traceability, over/underengineering, solution depth
55	- `security-auditor` — OWASP Top 10 review
56	- `test-reviewer` — test plan adequacy
57	- `tech-spec-validator` — template compliance, task quality, wave conflict detection
58	- Git commit after each validation round
59	- User approves → git commit approval (status: approved)
60
61	Output: `work/{feature}/tech-spec.md` (status: approved)
62
63	Skill: `tech-spec-planning`
64
65	### Step 3: Task Decomposition — `/decompose-tech-spec`
66
67	What: Break tech-spec into atomic task files.
68
69	Process:
70	- For each Implementation Task in tech-spec, `task-creator` agent copies task template and fills it (parallel)
71	- Each task file expands brief tech-spec scope into: acceptance criteria, TDD anchor (from Testing Strategy), context files, skills, reviewers, wave, dependencies → git commit draft
72	- 2 validators run in parallel (up to 3 iterations):
73	- `task-validator` — template compliance, content quality
74	- `reality-checker` — validates against actual codebase (file existence, feasibility)
75	- Cross-task integration check: both validators re-run on all tasks together — catches shared resource conflicts, duplicate heavy resource init, hidden dependencies (max 2 extra iterations)
76	- Git commit after each validation round
77	- User approves → git commit approval
78
79	Output: `work/{feature}/tasks/*.md` (validated)
80
81	Skill: `task-decomposition`
82
83	### Step 4: Implementation
84
85	Choose `/do-task` when: single task, manual control, debugging, iterating on one piece.
86	Choose `/do-feature` when: multiple tasks ready, standard feature work, want parallel execution.
87
88	Two modes:
89
90	#### Mode A: Single Task — `/do-task`
91
92	One task per session. Suited for manual, controlled execution.
93
94	Process:
95	- Reads task file and all its Context Files
96	- Loads skills specified in

People who liked this also viewed

6 picks

Type