Skip to content

Commit becaea1

Browse files
codeaholicguycodeaholicguy
committed
Test dev-lifecycle skill
1 parent d2ce7ad commit becaea1

13 files changed

Lines changed: 523 additions & 2 deletions

File tree

‎.ai-devkit.json‎

Lines changed: 4 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,10 @@
11
{
22
"version": "0.4.2",
33
"environments": [
4-
"cursor"
4+
"cursor",
5+
"claude",
6+
"antigravity",
7+
"codex"
58
],
69
"initializedPhases": [
710
"requirements",

‎.claude/skills/dev-lifecycle/SKILL.md‎

Lines changed: 66 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,66 @@
1+
---
2+
name: dev-lifecycle
3+
description: Full software development lifecycle workflow covering requirements, design, planning, implementation, testing, and code review. Use this skill when a user wants to build a new feature end-to-end, clarify or document requirements, review requirements or design docs, execute a feature plan, check implementation against design, perform code review, or write tests. Triggers on requests like "new feature", "add requirement", "review requirements", "review design", "execute plan", "check implementation", "code review", "write tests", or any structured SDLC workflow.
4+
---
5+
6+
# Dev Lifecycle
7+
8+
Structured development lifecycle from requirements through testing. Each phase produces documentation in `docs/ai/` and feeds into the next.
9+
10+
## Phases
11+
12+
| # | Phase | Reference | Trigger |
13+
|---|-------|-----------|---------|
14+
| 1 | **New Requirement** | [references/new-requirement.md](references/new-requirement.md) | User wants to add a feature or define a requirement |
15+
| 2 | **Review Requirements** | [references/review-requirements.md](references/review-requirements.md) | Requirements doc exists and needs validation |
16+
| 3 | **Review Design** | [references/review-design.md](references/review-design.md) | Design doc exists and needs validation |
17+
| 4 | **Execute Plan** | [references/execute-plan.md](references/execute-plan.md) | Planning doc exists and user is ready to implement |
18+
| 5 | **Check Implementation** | [references/check-implementation.md](references/check-implementation.md) | Code changes exist and need validation against design |
19+
| 6 | **Code Review** | [references/code-review.md](references/code-review.md) | Changes are ready for pre-push review |
20+
| 7 | **Write Tests** | [references/writing-test.md](references/writing-test.md) | Feature needs unit/integration/E2E tests |
21+
22+
## Phase Selection
23+
24+
1. If the user has no docs yet and wants to build something new → start at **Phase 1**.
25+
2. If requirements doc exists but hasn't been reviewed → **Phase 2**.
26+
3. If design doc exists but hasn't been reviewed → **Phase 3**.
27+
4. If planning doc exists and user says "implement" or "execute" → **Phase 4**.
28+
5. If code is written and user wants to verify against design → **Phase 5**.
29+
6. If code is ready to push → **Phase 6**.
30+
7. If user asks for tests at any point → **Phase 7**.
31+
32+
When starting a new feature end-to-end, walk through phases 1→2→3→4→5→7→6 sequentially. Load only the reference file for the current phase.
33+
34+
## Documentation Structure
35+
36+
All phase docs live under `docs/ai/`:
37+
38+
```
39+
docs/ai/
40+
├── requirements/feature-{name}.md
41+
├── design/feature-{name}.md
42+
├── planning/feature-{name}.md
43+
├── implementation/feature-{name}.md
44+
└── testing/feature-{name}.md
45+
```
46+
47+
Each feature doc is created by copying the corresponding `README.md` template in that directory, preserving frontmatter and section headings.
48+
49+
## Operating Rules
50+
51+
- Read the relevant phase reference file before guiding the user through that phase.
52+
- Always read existing docs in `docs/ai/` before making changes.
53+
- Keep diffs minimal; avoid unrelated edits.
54+
- Use mermaid diagrams for architecture and data-flow visuals.
55+
- After each phase, summarize what was produced and suggest the next phase.
56+
- If blocked, surface the issue and suggest alternatives before escalating.
57+
58+
## Supplementary Workflows
59+
60+
These can be invoked at any point during the lifecycle:
61+
62+
- **Debug**: Structured debugging with root cause analysis before code changes.
63+
- **Update Planning**: Reconcile planning docs with current implementation progress.
64+
- **Simplify Implementation**: Analyze and reduce complexity in existing code.
65+
- **Capture Knowledge**: Document understanding of a code entry point.
66+
- **Remember**: Store reusable guidance in the knowledge memory service.

‎.claude/skills/dev-lifecycle/references/check-implementation.md‎

Lines changed: 35 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,35 @@
1+
# Phase 5: Check Implementation
2+
3+
Compare current implementation with design and requirements docs to ensure alignment.
4+
5+
## Step 1: Gather Context
6+
7+
Ask for:
8+
- Feature/branch description
9+
- List of modified files
10+
- Relevant design doc(s) (feature-specific and/or project-level)
11+
- Known constraints or assumptions
12+
13+
## Step 2: Summarize Design
14+
15+
For each design doc:
16+
- Summarize key architectural decisions and constraints
17+
- Highlight components, interfaces, and data flows that must be respected
18+
19+
## Step 3: File-by-File Comparison
20+
21+
For each modified file:
22+
- Confirm implementation matches design intent
23+
- Note deviations or missing pieces
24+
- Flag logic gaps, edge cases, or security issues
25+
- Suggest simplifications or refactors
26+
- Identify missing tests or documentation updates
27+
28+
## Step 4: Output
29+
30+
Summarize findings with:
31+
- Alignment status per component
32+
- Deviations from design (with severity)
33+
- Missing pieces or incomplete implementations
34+
- Security or performance concerns
35+
- Recommended next steps (fixes, tests, doc updates)

‎.claude/skills/dev-lifecycle/references/code-review.md‎

Lines changed: 74 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,74 @@
1+
# Phase 6: Code Review
2+
3+
Perform a local code review **before** pushing changes.
4+
5+
## Step 1: Gather Context
6+
7+
Ask for:
8+
- Brief feature/branch description
9+
- List of modified files (with optional summaries)
10+
- Relevant design doc(s)
11+
- Known constraints or risky areas
12+
- Open bugs or TODOs linked to this work
13+
- Which tests have been run
14+
15+
Request the latest diff: `git status -sb` and `git diff --stat`
16+
17+
## Step 2: Understand Design Alignment
18+
19+
For each provided design doc:
20+
- Summarize architectural intent
21+
- Note critical requirements, patterns, or constraints
22+
23+
## Step 3: File-by-File Review
24+
25+
For every modified file:
26+
1. Deviations from design or requirements
27+
2. Logic or flow issues and edge cases
28+
3. Redundant or duplicate code
29+
4. Simplification opportunities (clarity over cleverness)
30+
5. Security concerns (input validation, secrets, auth, data handling)
31+
6. Performance pitfalls or scalability risks
32+
7. Error handling, logging, and observability
33+
8. Missing comments or docs
34+
9. Missing or outdated tests
35+
36+
## Step 4: Cross-Cutting Concerns
37+
38+
- Naming consistency and project conventions
39+
- Documentation/comments updated where behavior changed
40+
- Missing tests (unit, integration, E2E)
41+
- Configuration/migration updates captured
42+
43+
## Step 5: Summarize Findings
44+
45+
```
46+
### Summary
47+
- Blocking issues: [count]
48+
- Important follow-ups: [count]
49+
- Nice-to-have improvements: [count]
50+
51+
### Detailed Notes
52+
1. **[File or Component]**
53+
- Issue/Observation: ...
54+
- Impact: blocking / important / nice-to-have
55+
- Recommendation: ...
56+
- Design reference: [...]
57+
58+
### Recommended Next Steps
59+
- [ ] Address blocking issues
60+
- [ ] Update design/implementation docs if needed
61+
- [ ] Add/adjust tests (unit, integration, E2E)
62+
- [ ] Rerun local test suite
63+
- [ ] Re-run code review after fixes
64+
```
65+
66+
## Step 6: Final Checklist
67+
68+
Confirm each item (yes/no/needs follow-up):
69+
- Implementation matches design & requirements
70+
- No obvious logic or edge-case gaps
71+
- Redundant code removed or justified
72+
- Security considerations addressed
73+
- Tests cover new/changed behavior
74+
- Documentation/design notes updated

‎.claude/skills/dev-lifecycle/references/execute-plan.md‎

Lines changed: 69 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,69 @@
1+
# Phase 4: Execute Plan
2+
3+
Work through a feature plan one task at a time, interactively.
4+
5+
## Step 1: Gather Context
6+
7+
Ask for:
8+
- Feature name (kebab-case)
9+
- Brief feature/branch description
10+
- Planning doc path (default `docs/ai/planning/feature-{name}.md`)
11+
- Supporting docs (design, requirements, implementation)
12+
- Current branch and diff summary (`git status -sb`, `git diff --stat`)
13+
14+
## Step 2: Load the Plan
15+
16+
- Read the planning doc
17+
- Parse task lists (headings + checkboxes `[ ]`, `[x]`)
18+
- Build an ordered queue grouped by section (e.g., Foundation, Core, Testing)
19+
20+
## Step 3: Present Task Queue
21+
22+
```
23+
### Task Queue: <Feature Name>
24+
1. [status] Section - Task title
25+
2. ...
26+
```
27+
28+
Status legend: `todo`, `in-progress`, `done`, `blocked`
29+
30+
## Step 4: Interactive Task Execution
31+
32+
For each task:
33+
1. Display section/context, full bullet text, and existing notes
34+
2. Suggest relevant docs to reference (requirements/design/implementation)
35+
3. Ask: "Plan for this task?" — offer to outline sub-steps from design doc
36+
4. Prompt to mark status (`done`, `in-progress`, `blocked`, `skipped`) and capture notes
37+
5. Offer commands/snippets when useful
38+
6. If blocked, record blocker and move to end or "Blocked" list
39+
40+
## Step 5: Update Planning Doc
41+
42+
After each status change, generate a markdown snippet for the planning doc:
43+
```
44+
- [x] Task: Description (Notes: what was done)
45+
```
46+
47+
## Step 6: Check for New Work
48+
49+
After each section, ask if new tasks were discovered. Capture in "New Work" list.
50+
51+
## Step 7: Session Summary
52+
53+
```
54+
### Execution Summary
55+
- Completed: (list)
56+
- In Progress: (list + next steps)
57+
- Blocked: (list + blockers)
58+
- Skipped / Deferred: (list + rationale)
59+
- New Tasks: (list)
60+
```
61+
62+
## Step 8: Next Actions
63+
64+
Remind the user to:
65+
- Update `docs/ai/planning/feature-{name}.md` with new statuses
66+
- Sync related docs if decisions changed
67+
- Run **Check Implementation** (Phase 5) to validate against design
68+
- Run **Write Tests** (Phase 7) for coverage
69+
- Run **Code Review** (Phase 6) when ready for final review

‎.claude/skills/dev-lifecycle/references/new-requirement.md‎

Lines changed: 105 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,105 @@
1+
# Phase 1: New Requirement
2+
3+
Guide the user through capturing a new feature requirement and setting up the full documentation structure.
4+
5+
## Step 1: Capture Requirement
6+
7+
Ask for:
8+
- Feature name (kebab-case, e.g., `user-authentication`)
9+
- Problem it solves
10+
- Target users
11+
- Key user stories
12+
13+
## Step 2: Create Documentation Structure
14+
15+
Copy each `README.md` template, preserving YAML frontmatter and section headings:
16+
17+
| Template | Target |
18+
|----------|--------|
19+
| `docs/ai/requirements/README.md` | `docs/ai/requirements/feature-{name}.md` |
20+
| `docs/ai/design/README.md` | `docs/ai/design/feature-{name}.md` |
21+
| `docs/ai/planning/README.md` | `docs/ai/planning/feature-{name}.md` |
22+
| `docs/ai/implementation/README.md` | `docs/ai/implementation/feature-{name}.md` |
23+
| `docs/ai/testing/README.md` | `docs/ai/testing/feature-{name}.md` |
24+
25+
## Step 3: Requirements Phase
26+
27+
Fill `docs/ai/requirements/feature-{name}.md`:
28+
- Problem statement
29+
- Goals and non-goals
30+
- Detailed user stories
31+
- Success criteria
32+
- Constraints and assumptions
33+
- Open questions
34+
35+
## Step 4: Design Phase
36+
37+
Fill `docs/ai/design/feature-{name}.md`:
38+
- System architecture changes (include mermaid diagram)
39+
- Data models / schema changes
40+
- API endpoints or interfaces
41+
- Components to create/modify
42+
- Key design decisions
43+
- Security and performance considerations
44+
45+
## Step 5: Planning Phase
46+
47+
Fill `docs/ai/planning/feature-{name}.md`:
48+
- Task breakdown with subtasks
49+
- Dependencies
50+
- Effort estimates
51+
- Implementation order
52+
- Risks and mitigation
53+
54+
## Step 6: Documentation Review
55+
56+
After drafting, run:
57+
1. **Review Requirements** (Phase 2) to validate completeness and clarity
58+
2. **Review Design** (Phase 3) to ensure alignment and highlight key decisions
59+
60+
## Step 7: Implementation (Deferred)
61+
62+
This phase focuses on documentation only. Actual implementation happens via **Execute Plan** (Phase 4).
63+
64+
## Step 8: Testing Plan
65+
66+
In `docs/ai/testing/feature-{name}.md`:
67+
- Unit test cases
68+
- Integration test scenarios
69+
- Manual testing steps
70+
- Verify all success criteria are testable
71+
72+
## Step 9: PR Template
73+
74+
When ready, provide this MR/PR description:
75+
76+
```markdown
77+
## Feature: [Feature Name]
78+
79+
### Summary
80+
[Brief description]
81+
82+
### Requirements
83+
- Documented in: `docs/ai/requirements/feature-{name}.md`
84+
85+
### Changes
86+
- [Key changes]
87+
- [New files/components]
88+
- [Modified files]
89+
90+
### Design
91+
- Architecture: [Link to design doc]
92+
- Key decisions: [Summary]
93+
94+
### Testing
95+
- Unit tests: [coverage/status]
96+
- Integration tests: [status]
97+
- Test documentation: `docs/ai/testing/feature-{name}.md`
98+
99+
### Checklist
100+
- [ ] Code follows project standards
101+
- [ ] All tests pass
102+
- [ ] Documentation updated
103+
- [ ] No breaking changes (or documented)
104+
- [ ] Ready for review
105+
```

‎.claude/skills/dev-lifecycle/references/review-design.md‎

Lines changed: 26 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,26 @@
1+
# Phase 3: Review Design
2+
3+
Review `docs/ai/design/feature-{name}.md` (and the project-level README if relevant) for completeness and accuracy.
4+
5+
## What to Review
6+
7+
1. **Architecture overview** — Is a mermaid diagram present and accurate?
8+
2. **Key components** — Are responsibilities clearly defined?
9+
3. **Technology choices** — Is the rationale documented?
10+
4. **Data models and relationships** — Are schemas complete?
11+
5. **API/interface contracts** — Are inputs, outputs, and auth specified?
12+
6. **Design decisions and trade-offs** — Are alternatives considered?
13+
7. **Non-functional requirements** — Performance, security, scalability addressed?
14+
15+
## Output
16+
17+
Summarize:
18+
- Architecture overview with diagram assessment
19+
- Key components and their responsibilities
20+
- Technology choices and rationale
21+
- Data models and relationships
22+
- API/interface contracts (inputs, outputs, auth)
23+
- Major design decisions and trade-offs
24+
- Non-functional requirements that must be preserved
25+
26+
Highlight inconsistencies, missing sections, or diagrams that need updates. Provide actionable recommendations.

0 commit comments

Comments
 (0)