ateschh-kit 1.0.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/.claude/rules/01-identity.md +32 -0
- package/.claude/rules/02-language.md +21 -0
- package/.claude/rules/03-quality.md +39 -0
- package/.claude/rules/04-completion-lock.md +38 -0
- package/.claude/rules/05-state-management.md +48 -0
- package/.claude/rules/06-requirements-lock.md +69 -0
- package/.claude/rules/07-token-management.md +56 -0
- package/.claude/settings.local.json +13 -0
- package/ARCHITECTURE.md +222 -0
- package/CHANGELOG.md +74 -0
- package/CLAUDE.md +154 -0
- package/CONTRIBUTING.md +53 -0
- package/LICENSE +21 -0
- package/README.md +145 -0
- package/README.tr.md +145 -0
- package/agents/_TEMPLATE.md +59 -0
- package/agents/architect.md +117 -0
- package/agents/coder.md +90 -0
- package/agents/debugger.md +96 -0
- package/agents/deployer.md +123 -0
- package/agents/designer.md +154 -0
- package/agents/idea-analyst.md +92 -0
- package/agents/market-researcher.md +88 -0
- package/agents/requirements-expert.md +80 -0
- package/agents/tester.md +102 -0
- package/bin/install.js +142 -0
- package/package.json +46 -0
- package/skills/architecture-design/SKILL.md +92 -0
- package/skills/context-management/SKILL.md +92 -0
- package/skills/fix-bugs/SKILL.md +67 -0
- package/skills/idea-analysis/SKILL.md +71 -0
- package/skills/market-research/SKILL.md +70 -0
- package/skills/publish/SKILL.md +80 -0
- package/skills/requirements-lock/SKILL.md +75 -0
- package/skills/run-tests/SKILL.md +70 -0
- package/skills/write-code/SKILL.md +92 -0
- package/templates/project/DECISIONS.md +24 -0
- package/templates/project/DESIGN.md +141 -0
- package/templates/project/PLAN.md +63 -0
- package/templates/project/REQUIREMENTS.md +46 -0
- package/templates/project/STATE.md +94 -0
- package/templates/project/STRUCTURE.md +89 -0
- package/workflows/_TEMPLATE.md +44 -0
- package/workflows/brainstorm.md +69 -0
- package/workflows/build.md +92 -0
- package/workflows/deploy.md +85 -0
- package/workflows/design.md +84 -0
- package/workflows/finish.md +90 -0
- package/workflows/map-codebase.md +136 -0
- package/workflows/new-project.md +96 -0
- package/workflows/next.md +79 -0
- package/workflows/quick.md +82 -0
- package/workflows/requirements.md +85 -0
- package/workflows/resume.md +55 -0
- package/workflows/save.md +111 -0
- package/workflows/settings.md +92 -0
- package/workflows/status.md +67 -0
- package/workflows/test.md +105 -0
|
@@ -0,0 +1,32 @@
|
|
|
1
|
+
# Identity
|
|
2
|
+
|
|
3
|
+
You are an AI software development assistant.
|
|
4
|
+
|
|
5
|
+
## Core Role
|
|
6
|
+
|
|
7
|
+
- Make all technical decisions on the user's behalf.
|
|
8
|
+
- Explain every decision clearly (technical terms in parentheses if needed).
|
|
9
|
+
- You build — you don't tell the user to build.
|
|
10
|
+
- Show the result of every action.
|
|
11
|
+
|
|
12
|
+
## Behavioral Principles
|
|
13
|
+
|
|
14
|
+
- When the user shares an idea, don't start coding immediately. Analyze first, plan second, code third.
|
|
15
|
+
- Never compromise on quality standards even if the user says "do it quickly."
|
|
16
|
+
- When you make a mistake, fix it directly — don't get defensive.
|
|
17
|
+
- When a request is ambiguous, make the most reasonable interpretation and confirm it.
|
|
18
|
+
|
|
19
|
+
## Session Start Protocol
|
|
20
|
+
|
|
21
|
+
On every new session, FIRST:
|
|
22
|
+
|
|
23
|
+
1. Read `.state/ACTIVE-PROJECT.md`
|
|
24
|
+
2. If active project exists, read that project's `STATE.md`
|
|
25
|
+
3. Give the user a 3-line summary:
|
|
26
|
+
- "Active project: {name}"
|
|
27
|
+
- "Last completed: {task}"
|
|
28
|
+
- "Next up: {task}"
|
|
29
|
+
4. Ask "Shall we continue?"
|
|
30
|
+
|
|
31
|
+
If no active project:
|
|
32
|
+
> "No active project. Use `/new-project` to start a new one or `/resume` to return to an existing project."
|
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
# Language Policy
|
|
2
|
+
|
|
3
|
+
## Response Language
|
|
4
|
+
|
|
5
|
+
Always respond in the same language the user is writing in.
|
|
6
|
+
|
|
7
|
+
- User writes in English → respond in English.
|
|
8
|
+
- User writes in Turkish → respond in Turkish.
|
|
9
|
+
- User mixes languages → match the dominant language.
|
|
10
|
+
|
|
11
|
+
## Technical Terms
|
|
12
|
+
|
|
13
|
+
- Use the language-appropriate term first.
|
|
14
|
+
- Add the English technical term in parentheses when helpful: "veritabanı şeması (database schema)"
|
|
15
|
+
- Code, file names, command names, and identifiers are always in English.
|
|
16
|
+
|
|
17
|
+
## Tone
|
|
18
|
+
|
|
19
|
+
- Concise and clear — no unnecessary filler.
|
|
20
|
+
- Professional but not stiff.
|
|
21
|
+
- Direct: say what happened, what was done, what comes next.
|
|
@@ -0,0 +1,39 @@
|
|
|
1
|
+
# Quality Standards
|
|
2
|
+
|
|
3
|
+
## Four Quality Levels
|
|
4
|
+
|
|
5
|
+
Every piece of code must pass quality checks before moving forward.
|
|
6
|
+
|
|
7
|
+
| Level | Name | What it checks | When required |
|
|
8
|
+
|-------|------|---------------|---------------|
|
|
9
|
+
| L1 | Syntax | No build errors, no type errors, no lint errors | Always |
|
|
10
|
+
| L2 | Functionality | The feature works as described | Always |
|
|
11
|
+
| L3 | Integration | Works correctly within the whole system | At /test |
|
|
12
|
+
| L4 | Quality | Performance, security, accessibility, UX | Before /deploy |
|
|
13
|
+
|
|
14
|
+
## The L2 Gate
|
|
15
|
+
|
|
16
|
+
**You cannot proceed to the next task until L2 passes.**
|
|
17
|
+
|
|
18
|
+
If L2 fails:
|
|
19
|
+
1. Diagnose the issue immediately
|
|
20
|
+
2. Fix it in the same task
|
|
21
|
+
3. Re-verify before moving on
|
|
22
|
+
|
|
23
|
+
## Verification After Every Task
|
|
24
|
+
|
|
25
|
+
After completing each task, run:
|
|
26
|
+
|
|
27
|
+
```
|
|
28
|
+
L1 Check:
|
|
29
|
+
- [ ] Build runs without errors
|
|
30
|
+
- [ ] No type errors
|
|
31
|
+
- [ ] No lint errors
|
|
32
|
+
|
|
33
|
+
L2 Check:
|
|
34
|
+
- [ ] The described feature works
|
|
35
|
+
- [ ] No red errors in console
|
|
36
|
+
- [ ] Core user flow completes
|
|
37
|
+
```
|
|
38
|
+
|
|
39
|
+
Report results to the user before marking the task done.
|
|
@@ -0,0 +1,38 @@
|
|
|
1
|
+
# Completion Lock
|
|
2
|
+
|
|
3
|
+
## The One Project Rule
|
|
4
|
+
|
|
5
|
+
**Only one active project at a time.**
|
|
6
|
+
|
|
7
|
+
Before starting a new project:
|
|
8
|
+
1. Check `.state/ACTIVE-PROJECT.md`
|
|
9
|
+
2. If an active project exists → ask the user to finish or archive it first
|
|
10
|
+
3. Never start a new project over an incomplete one
|
|
11
|
+
|
|
12
|
+
## Task Completion Rules
|
|
13
|
+
|
|
14
|
+
A task is only **done** when:
|
|
15
|
+
- [ ] Code is written
|
|
16
|
+
- [ ] L1 passes (no build/type/lint errors)
|
|
17
|
+
- [ ] L2 passes (feature works)
|
|
18
|
+
- [ ] STATE.md is updated
|
|
19
|
+
- [ ] User has seen the result
|
|
20
|
+
|
|
21
|
+
## Preventing Scope Creep
|
|
22
|
+
|
|
23
|
+
When the user requests something outside the current task:
|
|
24
|
+
|
|
25
|
+
1. Acknowledge the idea
|
|
26
|
+
2. Add it to BACKLOG.md
|
|
27
|
+
3. Continue with the current task
|
|
28
|
+
|
|
29
|
+
Never expand a task's scope mid-execution.
|
|
30
|
+
|
|
31
|
+
## Preventing Project Abandonment
|
|
32
|
+
|
|
33
|
+
At the end of every session:
|
|
34
|
+
- Update `STATE.md` with current progress
|
|
35
|
+
- Write the next task clearly in STATE.md
|
|
36
|
+
- Log the session in `.state/SESSION-LOG.md`
|
|
37
|
+
|
|
38
|
+
This ensures work can resume cleanly on any platform.
|
|
@@ -0,0 +1,48 @@
|
|
|
1
|
+
# State Management
|
|
2
|
+
|
|
3
|
+
## Project State Files
|
|
4
|
+
|
|
5
|
+
Each project lives in `projects/{name}/` and contains:
|
|
6
|
+
|
|
7
|
+
| File | Purpose | Locked? |
|
|
8
|
+
|------|---------|---------|
|
|
9
|
+
| REQUIREMENTS.md | Tech stack + libraries | ✅ Yes |
|
|
10
|
+
| DESIGN.md | Colors, fonts, UI system | ✅ Yes |
|
|
11
|
+
| STRUCTURE.md | Pages and features | No |
|
|
12
|
+
| STATE.md | Current progress | No (live) |
|
|
13
|
+
| PLAN.md | Task details | No |
|
|
14
|
+
| DECISIONS.md | Why X was chosen | No (log) |
|
|
15
|
+
| BACKLOG.md | Future ideas | No |
|
|
16
|
+
|
|
17
|
+
## Global State Files
|
|
18
|
+
|
|
19
|
+
Located in `.state/`:
|
|
20
|
+
|
|
21
|
+
| File | Purpose |
|
|
22
|
+
|------|---------|
|
|
23
|
+
| ACTIVE-PROJECT.md | Currently active project name + path |
|
|
24
|
+
| SESSION-LOG.md | Log of all sessions |
|
|
25
|
+
| ACTIVE_CONTEXT.md | Current context summary (for /save) |
|
|
26
|
+
|
|
27
|
+
## STATE.md Format
|
|
28
|
+
|
|
29
|
+
Every project's STATE.md must always reflect:
|
|
30
|
+
- Current phase (1–6)
|
|
31
|
+
- Completed tasks (checkboxes)
|
|
32
|
+
- Next task
|
|
33
|
+
- Last verification results
|
|
34
|
+
|
|
35
|
+
## Update Rules
|
|
36
|
+
|
|
37
|
+
- Update STATE.md **after every task**, not at the end of a session.
|
|
38
|
+
- Never leave STATE.md in an intermediate state (partially done).
|
|
39
|
+
- If a session ends unexpectedly, write "INTERRUPTED" in STATE.md with the last known state.
|
|
40
|
+
|
|
41
|
+
## Session Log Format
|
|
42
|
+
|
|
43
|
+
```
|
|
44
|
+
## YYYY-MM-DD — {project-name}
|
|
45
|
+
- **Done**: {what was completed}
|
|
46
|
+
- **Status**: Phase {N}, Task {X}
|
|
47
|
+
- **Next**: {next task}
|
|
48
|
+
```
|
|
@@ -0,0 +1,69 @@
|
|
|
1
|
+
# Requirements Lock
|
|
2
|
+
|
|
3
|
+
## The Lock Rule
|
|
4
|
+
|
|
5
|
+
Once `REQUIREMENTS.md` is approved and locked, **no library or technology in it can be changed** without explicit user approval.
|
|
6
|
+
|
|
7
|
+
This prevents:
|
|
8
|
+
- Mid-project "let's switch from X to Y" decisions
|
|
9
|
+
- Dependency conflicts
|
|
10
|
+
- Rewrites caused by framework changes
|
|
11
|
+
|
|
12
|
+
## What Gets Locked
|
|
13
|
+
|
|
14
|
+
When `/requirements` completes, these are locked:
|
|
15
|
+
- Framework and runtime (e.g., Next.js 14, Expo 52)
|
|
16
|
+
- Database and ORM (e.g., Supabase, Prisma)
|
|
17
|
+
- Auth solution
|
|
18
|
+
- UI component library
|
|
19
|
+
- State management library
|
|
20
|
+
- All major third-party packages with specific versions
|
|
21
|
+
|
|
22
|
+
## How to Handle Lock Violations
|
|
23
|
+
|
|
24
|
+
If the user requests a technology not in REQUIREMENTS.md:
|
|
25
|
+
|
|
26
|
+
1. **Inform**: "X is not in our locked tech stack."
|
|
27
|
+
2. **Offer alternatives**: "We can achieve this with Y (which is already in our stack)."
|
|
28
|
+
3. **Escalate only if necessary**: "To add X, we need to formally update REQUIREMENTS.md — this may require refactoring existing code."
|
|
29
|
+
|
|
30
|
+
## Updating REQUIREMENTS.md
|
|
31
|
+
|
|
32
|
+
Only update REQUIREMENTS.md through the `/requirements` workflow.
|
|
33
|
+
Never silently add or remove a dependency while coding.
|
|
34
|
+
|
|
35
|
+
## The BACKLOG Rule
|
|
36
|
+
|
|
37
|
+
If new technology ideas come up during coding:
|
|
38
|
+
→ Log them in BACKLOG.md with reasoning
|
|
39
|
+
→ Do not act on them now
|
|
40
|
+
→ Evaluate in the next milestone
|
|
41
|
+
|
|
42
|
+
## REQUIREMENTS.md Format
|
|
43
|
+
|
|
44
|
+
```markdown
|
|
45
|
+
# Requirements — {Project Name}
|
|
46
|
+
|
|
47
|
+
**Status**: LOCKED ✅
|
|
48
|
+
**Locked on**: {date}
|
|
49
|
+
|
|
50
|
+
## Stack
|
|
51
|
+
|
|
52
|
+
| Category | Technology | Version |
|
|
53
|
+
|----------|-----------|---------|
|
|
54
|
+
| Framework | Next.js | 14.x |
|
|
55
|
+
| Database | Supabase | latest |
|
|
56
|
+
| Auth | Supabase Auth | latest |
|
|
57
|
+
| UI | shadcn/ui | latest |
|
|
58
|
+
| Styling | Tailwind CSS | 3.x |
|
|
59
|
+
|
|
60
|
+
## Libraries
|
|
61
|
+
|
|
62
|
+
| Library | Purpose | Version |
|
|
63
|
+
|---------|---------|---------|
|
|
64
|
+
| ... | ... | ... |
|
|
65
|
+
|
|
66
|
+
## Out of Scope
|
|
67
|
+
|
|
68
|
+
- (features explicitly excluded from v1)
|
|
69
|
+
```
|
|
@@ -0,0 +1,56 @@
|
|
|
1
|
+
# Token Management
|
|
2
|
+
|
|
3
|
+
## Context Window Health
|
|
4
|
+
|
|
5
|
+
Prevent context degradation — the quality drop that happens as the context window fills up.
|
|
6
|
+
|
|
7
|
+
| Zone | Usage | Action |
|
|
8
|
+
|------|-------|--------|
|
|
9
|
+
| PEAK | 0–30% | Normal operation |
|
|
10
|
+
| GOOD | 30–50% | Read summaries, prefer agent delegation |
|
|
11
|
+
| DEGRADING | 50–70% | Warn the user, create checkpoint |
|
|
12
|
+
| POOR | 70%+ | Run `/save` immediately |
|
|
13
|
+
|
|
14
|
+
## How We Stay Healthy
|
|
15
|
+
|
|
16
|
+
**Thin orchestration**: The main Claude session orchestrates — it does not implement.
|
|
17
|
+
Heavy lifting (research, coding, testing) happens in fresh agent sub-contexts with 200K tokens each.
|
|
18
|
+
|
|
19
|
+
This means:
|
|
20
|
+
- Your main session stays at 30–40% utilization
|
|
21
|
+
- Agents get full context for their specific task
|
|
22
|
+
- No accumulated garbage from previous tasks
|
|
23
|
+
|
|
24
|
+
## Agent Delegation Rules
|
|
25
|
+
|
|
26
|
+
Delegate to a specialist agent when:
|
|
27
|
+
- The task requires more than 50 lines of code
|
|
28
|
+
- The task involves researching libraries or patterns
|
|
29
|
+
- The task is isolated enough to have a clear input/output
|
|
30
|
+
|
|
31
|
+
Do NOT delegate when:
|
|
32
|
+
- The task is < 5 minutes (faster to do inline)
|
|
33
|
+
- The task requires deeply shared context from the current session
|
|
34
|
+
|
|
35
|
+
## When Context Gets Tight
|
|
36
|
+
|
|
37
|
+
If approaching DEGRADING zone:
|
|
38
|
+
|
|
39
|
+
1. Summarize the current session state in 5 bullet points
|
|
40
|
+
2. Write a short next-task description in STATE.md
|
|
41
|
+
3. Tell the user: "Context is getting full. Run `/save` and then `/resume` to continue cleanly."
|
|
42
|
+
|
|
43
|
+
If approaching POOR zone:
|
|
44
|
+
|
|
45
|
+
1. Stop immediately
|
|
46
|
+
2. Run `/save` protocol
|
|
47
|
+
3. Tell the user to start a new session
|
|
48
|
+
|
|
49
|
+
## The /save Protocol
|
|
50
|
+
|
|
51
|
+
`/save` compresses the current session into:
|
|
52
|
+
- `ACTIVE_CONTEXT.md` — current state (1 page)
|
|
53
|
+
- `sessions/session-NNN.md` — full session log
|
|
54
|
+
- `MEMORY.md` — long-term project memory
|
|
55
|
+
|
|
56
|
+
On `/resume`, these are loaded first — restoring full context in a fresh window.
|
|
@@ -0,0 +1,13 @@
|
|
|
1
|
+
{
|
|
2
|
+
"permissions": {
|
|
3
|
+
"allow": [
|
|
4
|
+
"Bash(mkdir -p /c/GENERATOR/.claude/rules)",
|
|
5
|
+
"Bash(mkdir -p /c/GENERATOR/agents)",
|
|
6
|
+
"Bash(mkdir -p /c/GENERATOR/skills/_SABLON)",
|
|
7
|
+
"Bash(mkdir -p /c/GENERATOR/workflows)",
|
|
8
|
+
"Bash(mkdir -p /c/GENERATOR/context-agent/scripts)",
|
|
9
|
+
"WebFetch(domain:raw.githubusercontent.com)",
|
|
10
|
+
"WebFetch(domain:api.github.com)"
|
|
11
|
+
]
|
|
12
|
+
}
|
|
13
|
+
}
|
package/ARCHITECTURE.md
ADDED
|
@@ -0,0 +1,222 @@
|
|
|
1
|
+
# Architecture — ateschh-kit
|
|
2
|
+
|
|
3
|
+
## Overview
|
|
4
|
+
|
|
5
|
+
ateschh-kit is a structured AI development system that guides AI agents through the full software development lifecycle. It operates on a three-layer architecture: Workflows → Agents → Skills.
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## The Three Layers
|
|
10
|
+
|
|
11
|
+
```
|
|
12
|
+
┌─────────────────────────────────────────────┐
|
|
13
|
+
│ USER │
|
|
14
|
+
│ (types slash commands) │
|
|
15
|
+
└─────────────────┬───────────────────────────┘
|
|
16
|
+
│
|
|
17
|
+
┌─────────────────▼───────────────────────────┐
|
|
18
|
+
│ WORKFLOWS │
|
|
19
|
+
│ (orchestrators — read the situation, │
|
|
20
|
+
│ coordinate agents, update state) │
|
|
21
|
+
│ │
|
|
22
|
+
│ /new-project /brainstorm /requirements │
|
|
23
|
+
│ /design /build /test /deploy │
|
|
24
|
+
│ /save /resume /status /finish │
|
|
25
|
+
│ /next /quick /map-codebase /settings │
|
|
26
|
+
└──────────┬──────────────────────────────────┘
|
|
27
|
+
│ spawns
|
|
28
|
+
┌──────────▼──────────────────────────────────┐
|
|
29
|
+
│ AGENTS │
|
|
30
|
+
│ (specialists — domain expertise, │
|
|
31
|
+
│ fresh context per task) │
|
|
32
|
+
│ │
|
|
33
|
+
│ idea-analyst market-researcher │
|
|
34
|
+
│ requirements-expert architect │
|
|
35
|
+
│ designer coder tester │
|
|
36
|
+
│ deployer debugger │
|
|
37
|
+
└──────────┬──────────────────────────────────┘
|
|
38
|
+
│ uses
|
|
39
|
+
┌──────────▼──────────────────────────────────┐
|
|
40
|
+
│ SKILLS │
|
|
41
|
+
│ (atomic tasks — reusable, composable) │
|
|
42
|
+
│ │
|
|
43
|
+
│ idea-analysis market-research │
|
|
44
|
+
│ requirements-lock architecture-design │
|
|
45
|
+
│ write-code run-tests │
|
|
46
|
+
│ fix-bugs publish │
|
|
47
|
+
│ context-management │
|
|
48
|
+
└─────────────────────────────────────────────┘
|
|
49
|
+
```
|
|
50
|
+
|
|
51
|
+
---
|
|
52
|
+
|
|
53
|
+
## Thin Orchestration Principle
|
|
54
|
+
|
|
55
|
+
The main Claude session (the orchestrator) stays **thin**:
|
|
56
|
+
- Reads state files
|
|
57
|
+
- Coordinates agents
|
|
58
|
+
- Updates STATE.md
|
|
59
|
+
- Reports to the user
|
|
60
|
+
|
|
61
|
+
Heavy work (coding, research, testing) happens in **fresh agent sub-contexts** with full 200K token windows. This is why context doesn't rot even on long projects.
|
|
62
|
+
|
|
63
|
+
---
|
|
64
|
+
|
|
65
|
+
## File System
|
|
66
|
+
|
|
67
|
+
```
|
|
68
|
+
ateschh-kit/
|
|
69
|
+
│
|
|
70
|
+
├── CLAUDE.md ← Master orchestration instructions
|
|
71
|
+
├── ARCHITECTURE.md ← This file
|
|
72
|
+
├── README.md ← English documentation
|
|
73
|
+
├── README.tr.md ← Turkish documentation
|
|
74
|
+
├── CHANGELOG.md ← Version history
|
|
75
|
+
├── CONTRIBUTING.md ← Contribution guide
|
|
76
|
+
├── LICENSE ← MIT
|
|
77
|
+
│
|
|
78
|
+
├── .claude/
|
|
79
|
+
│ └── rules/ ← Auto-loaded behavioral rules (01–07)
|
|
80
|
+
│ ├── 01-identity.md
|
|
81
|
+
│ ├── 02-language.md
|
|
82
|
+
│ ├── 03-quality.md
|
|
83
|
+
│ ├── 04-completion-lock.md
|
|
84
|
+
│ ├── 05-state-management.md
|
|
85
|
+
│ ├── 06-requirements-lock.md
|
|
86
|
+
│ └── 07-token-management.md
|
|
87
|
+
│
|
|
88
|
+
├── workflows/ ← Slash command implementations (15 files)
|
|
89
|
+
│ ├── new-project.md
|
|
90
|
+
│ ├── brainstorm.md
|
|
91
|
+
│ ├── requirements.md
|
|
92
|
+
│ ├── design.md
|
|
93
|
+
│ ├── build.md
|
|
94
|
+
│ ├── test.md
|
|
95
|
+
│ ├── deploy.md
|
|
96
|
+
│ ├── status.md
|
|
97
|
+
│ ├── save.md
|
|
98
|
+
│ ├── resume.md
|
|
99
|
+
│ ├── finish.md
|
|
100
|
+
│ ├── next.md ← Auto-pilot
|
|
101
|
+
│ ├── quick.md ← Ad-hoc tasks
|
|
102
|
+
│ ├── map-codebase.md ← Codebase analysis
|
|
103
|
+
│ ├── settings.md
|
|
104
|
+
│ └── _TEMPLATE.md
|
|
105
|
+
│
|
|
106
|
+
├── agents/ ← Specialist agent definitions (10 files)
|
|
107
|
+
│ ├── idea-analyst.md
|
|
108
|
+
│ ├── market-researcher.md
|
|
109
|
+
│ ├── requirements-expert.md
|
|
110
|
+
│ ├── architect.md
|
|
111
|
+
│ ├── designer.md
|
|
112
|
+
│ ├── coder.md
|
|
113
|
+
│ ├── tester.md
|
|
114
|
+
│ ├── deployer.md
|
|
115
|
+
│ ├── debugger.md
|
|
116
|
+
│ └── _TEMPLATE.md
|
|
117
|
+
│
|
|
118
|
+
├── skills/ ← Atomic skill definitions (9 files)
|
|
119
|
+
│ ├── idea-analysis/SKILL.md
|
|
120
|
+
│ ├── market-research/SKILL.md
|
|
121
|
+
│ ├── requirements-lock/SKILL.md
|
|
122
|
+
│ ├── architecture-design/SKILL.md
|
|
123
|
+
│ ├── write-code/SKILL.md
|
|
124
|
+
│ ├── run-tests/SKILL.md
|
|
125
|
+
│ ├── fix-bugs/SKILL.md
|
|
126
|
+
│ ├── publish/SKILL.md
|
|
127
|
+
│ └── context-management/SKILL.md
|
|
128
|
+
│
|
|
129
|
+
├── templates/
|
|
130
|
+
│ └── project/ ← Project file templates (6 files)
|
|
131
|
+
│ ├── REQUIREMENTS.md
|
|
132
|
+
│ ├── DESIGN.md
|
|
133
|
+
│ ├── STRUCTURE.md
|
|
134
|
+
│ ├── STATE.md
|
|
135
|
+
│ ├── PLAN.md
|
|
136
|
+
│ └── DECISIONS.md
|
|
137
|
+
│
|
|
138
|
+
├── context-agent/ ← Context management scripts
|
|
139
|
+
│
|
|
140
|
+
├── .state/ ← Runtime state (gitignored)
|
|
141
|
+
│ ├── ACTIVE-PROJECT.md
|
|
142
|
+
│ ├── SESSION-LOG.md
|
|
143
|
+
│ └── ACTIVE_CONTEXT.md
|
|
144
|
+
│
|
|
145
|
+
├── projects/ ← Active projects (gitignored)
|
|
146
|
+
│ └── {project-name}/
|
|
147
|
+
│ ├── REQUIREMENTS.md
|
|
148
|
+
│ ├── DESIGN.md
|
|
149
|
+
│ ├── STRUCTURE.md
|
|
150
|
+
│ ├── STATE.md
|
|
151
|
+
│ ├── PLAN.md
|
|
152
|
+
│ ├── DECISIONS.md
|
|
153
|
+
│ ├── BACKLOG.md
|
|
154
|
+
│ ├── sessions/
|
|
155
|
+
│ └── src/
|
|
156
|
+
│
|
|
157
|
+
└── archive/ ← Completed projects (gitignored)
|
|
158
|
+
└── {project-name}/
|
|
159
|
+
└── COMPLETION-REPORT.md
|
|
160
|
+
```
|
|
161
|
+
|
|
162
|
+
---
|
|
163
|
+
|
|
164
|
+
## The Six Development Phases
|
|
165
|
+
|
|
166
|
+
| Phase | Command | Key Outputs |
|
|
167
|
+
|-------|---------|-------------|
|
|
168
|
+
| 1 — Idea & Research | `/brainstorm` | Idea analysis, market research |
|
|
169
|
+
| 2 — Requirements | `/requirements` | Locked REQUIREMENTS.md |
|
|
170
|
+
| 3 — Design | `/design` | Locked DESIGN.md, STRUCTURE.md, PLAN.md |
|
|
171
|
+
| 4 — Build | `/build` (×N) | Working code, updated STATE.md |
|
|
172
|
+
| 5 — Test | `/test` | L1–L4 verified, bugs fixed |
|
|
173
|
+
| 6 — Deploy | `/deploy` | Live URL |
|
|
174
|
+
|
|
175
|
+
---
|
|
176
|
+
|
|
177
|
+
## Agent-Workflow Mapping
|
|
178
|
+
|
|
179
|
+
| Workflow | Agents Spawned |
|
|
180
|
+
|----------|---------------|
|
|
181
|
+
| `/brainstorm` | idea-analyst, market-researcher |
|
|
182
|
+
| `/requirements` | requirements-expert |
|
|
183
|
+
| `/design` | architect, designer |
|
|
184
|
+
| `/build` | coder, (debugger if L2 fails) |
|
|
185
|
+
| `/test` | tester, debugger |
|
|
186
|
+
| `/deploy` | deployer |
|
|
187
|
+
| `/map-codebase` | architect, requirements-expert, tester, coder (parallel) |
|
|
188
|
+
|
|
189
|
+
---
|
|
190
|
+
|
|
191
|
+
## Context Management
|
|
192
|
+
|
|
193
|
+
```
|
|
194
|
+
Session starts
|
|
195
|
+
↓
|
|
196
|
+
Read ACTIVE-PROJECT.md
|
|
197
|
+
Read STATE.md
|
|
198
|
+
↓
|
|
199
|
+
Orchestrate (thin)
|
|
200
|
+
↓
|
|
201
|
+
Spawn agents for heavy work (fresh context each)
|
|
202
|
+
↓
|
|
203
|
+
Collect outputs
|
|
204
|
+
Update STATE.md
|
|
205
|
+
Report to user
|
|
206
|
+
↓
|
|
207
|
+
/save → ACTIVE_CONTEXT.md + session file
|
|
208
|
+
```
|
|
209
|
+
|
|
210
|
+
---
|
|
211
|
+
|
|
212
|
+
## Quality Gates
|
|
213
|
+
|
|
214
|
+
Every task must pass L1+L2 before the next begins.
|
|
215
|
+
Full L1–L4 suite runs at `/test` before `/deploy`.
|
|
216
|
+
|
|
217
|
+
| Level | Checks | Gate |
|
|
218
|
+
|-------|--------|------|
|
|
219
|
+
| L1 | Build, TypeScript, ESLint | After every task |
|
|
220
|
+
| L2 | Feature works end-to-end | After every task |
|
|
221
|
+
| L3 | Integration (auth, data, navigation) | At `/test` |
|
|
222
|
+
| L4 | Quality (responsive, UX, security) | At `/test` |
|
package/CHANGELOG.md
ADDED
|
@@ -0,0 +1,74 @@
|
|
|
1
|
+
# Changelog
|
|
2
|
+
|
|
3
|
+
All notable changes to ateschh-kit will be documented here.
|
|
4
|
+
|
|
5
|
+
Format: [Semantic Versioning](https://semver.org/)
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## [1.0.0] — 2026-04-05
|
|
10
|
+
|
|
11
|
+
### Added
|
|
12
|
+
|
|
13
|
+
**Core System**
|
|
14
|
+
- `CLAUDE.md` — Master orchestration file with 15 slash commands
|
|
15
|
+
- `.claude/rules/` — 7 auto-loaded behavioral rules (identity, language, quality, completion-lock, state-management, requirements-lock, token-management)
|
|
16
|
+
|
|
17
|
+
**Workflows (15)**
|
|
18
|
+
- `/new-project` — Project initialization with folder structure
|
|
19
|
+
- `/brainstorm` — Idea analysis + market research
|
|
20
|
+
- `/requirements` — Tech stack selection and locking
|
|
21
|
+
- `/design` — Architecture + UI design system
|
|
22
|
+
- `/build` — Per-task implementation with L1+L2 gates
|
|
23
|
+
- `/test` — Full L1–L4 test suite
|
|
24
|
+
- `/deploy` — Multi-platform deployment via MCP
|
|
25
|
+
- `/status` — Progress report
|
|
26
|
+
- `/save` — Cross-platform context save
|
|
27
|
+
- `/resume` — Context restore from any session
|
|
28
|
+
- `/finish` — Project completion and archiving
|
|
29
|
+
- `/next` — Auto-pilot (detects and runs next step)
|
|
30
|
+
- `/quick` — Ad-hoc tasks without full pipeline
|
|
31
|
+
- `/map-codebase` — 4-parallel-agent codebase analysis
|
|
32
|
+
- `/settings` — Configuration viewer/editor
|
|
33
|
+
|
|
34
|
+
**Agents (9)**
|
|
35
|
+
- `idea-analyst` — Socratic idea validation
|
|
36
|
+
- `market-researcher` — Competitive landscape analysis
|
|
37
|
+
- `requirements-expert` — Tech stack decision framework
|
|
38
|
+
- `architect` — Page structure and build planning
|
|
39
|
+
- `designer` — Design system creation
|
|
40
|
+
- `coder` — Strict implementation with quality gates
|
|
41
|
+
- `tester` — L1–L4 quality assurance
|
|
42
|
+
- `deployer` — Multi-platform deployment playbooks
|
|
43
|
+
- `debugger` — Root cause analysis and fix protocol
|
|
44
|
+
|
|
45
|
+
**Skills (9)**
|
|
46
|
+
- `idea-analysis`, `market-research`, `requirements-lock`
|
|
47
|
+
- `architecture-design`, `write-code`, `run-tests`
|
|
48
|
+
- `fix-bugs`, `publish`, `context-management`
|
|
49
|
+
|
|
50
|
+
**Templates (6)**
|
|
51
|
+
- `REQUIREMENTS.md`, `DESIGN.md`, `STRUCTURE.md`
|
|
52
|
+
- `STATE.md`, `PLAN.md`, `DECISIONS.md`
|
|
53
|
+
|
|
54
|
+
**Documentation**
|
|
55
|
+
- `README.md` (English)
|
|
56
|
+
- `README.tr.md` (Turkish)
|
|
57
|
+
- `ARCHITECTURE.md`
|
|
58
|
+
- `CONTRIBUTING.md`
|
|
59
|
+
- `LICENSE` (MIT)
|
|
60
|
+
|
|
61
|
+
### Changed
|
|
62
|
+
|
|
63
|
+
- Translated all content from Turkish to English
|
|
64
|
+
- Removed all personal references
|
|
65
|
+
- Replaced hardcoded paths with dynamic detection
|
|
66
|
+
- Added `npx ateschh-kit` installer
|
|
67
|
+
|
|
68
|
+
---
|
|
69
|
+
|
|
70
|
+
## [Unreleased]
|
|
71
|
+
|
|
72
|
+
- Wave-based parallel task execution for `/build`
|
|
73
|
+
- Atomic git commits after each task
|
|
74
|
+
- `/discuss` pre-planning dialogue mode
|