feat: add Claude Code native implementation with multi-agent architecture

[anhyobin]

Summary

Add Claude Code-native AIDLC implementation using agents, skills, hooks, and rules. This provides the same AIDLC methodology with system-level role enforcement, on-demand context loading, and automated workflow management.

• 14 skills (one per AIDLC stage, invoked as /aidlc-* slash commands)
• 4 agents with tool isolation (analyst, architect, developer, reviewer)
• 6 cross-cutting rules (content validation, error handling, terminology, workflow changes, 2 conditional extensions)
• 2 hooks (SessionStart auto-detection, SubagentStop audit logging)

What Changed

New directory: platforms/claude-code/ (or location TBD by maintainers)

.claude/
├── CLAUDE.md                     # Lightweight routing (~73 lines)
├── settings.json                 # Hooks + permissions
├── agents/  (4 files)            # Role-based agents with tool restrictions
├── rules/   (6 files)            # Cross-cutting rules + conditional extensions
└── skills/  (14 directories)     # One skill per AIDLC stage

Plus: README.md, LICENSE (MIT-0)

Why

Claude Code has native capabilities that the single rule-file approach cannot leverage:

Capability	Rule File	Native
Tool isolation	"Don't modify code" (text)	disallowedTools: [Write, Edit] (system)
Context efficiency	538 lines always loaded	73 lines + on-demand skills
Session resumption	Manual state check	SessionStart hook auto-detects
Audit logging	Manual recording	SubagentStop hook auto-records
Extension loading	Always loaded	Conditional via paths frontmatter

Testing

Scenario: Serverless Order Management API (Cognito, Lambda, DynamoDB, SQS, EventBridge, Stripe integration. 4 units, TypeScript/CDK.)

Method: 42 agent evaluations across all 14 AIDLC stages, comparing 3 approaches:

Approach	Assertions Passed	Pass Rate
Claude Code Native	76/76	100%
Upstream Rule File	73/76	96.1%
No Guidance	54/71	76.1%

Native outperforms upstream in:

• functional: Technology-agnostic constraint enforcement (upstream leaked specific service names into business logic design)
• gate: 2-phase pipeline structure compliance (upstream merged code review and testing into a single undifferentiated pass)

76 assertions cover: structural compliance (question format, [Answer]: tags, X) Other options, categorized questions), methodology adherence (4-dimension analysis, INVEST criteria, EXECUTE/SKIP decisions, GO/NO-GO + PASS/FAIL verdicts), and artifact completeness. The implementation is language-agnostic -- output language follows the user's language automatically.

Full benchmark data: aidlc-skills-workspace/full-eval/benchmark.json

Upstream Compatibility

• Same three-phase lifecycle, stage sequence, and gate rules
• Same question file format and artifact structure (aidlc-docs/)
• Extensions aligned with security-baseline and property-based-testing
• Cross-cutting rules derived from upstream common/ (content-validation, error-handling, terminology, workflow-changes)

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[harmjeff]

@anhyobin How do we maintain this? The AIDLC will evolve and your changes fully refactored the AIDLC into a group of skills. Is there any automation that can take the AIDLC flows and create this version of teh AIDLC?

[anhyobin]

@harmjeff Great question. Let me explain the maintenance story.

The mapping is 1:1 and modular.

AIDLC Concept	Claude Code Primitive	Example
Stage	Skill	.claude/skills/aidlc-requirements/SKILL.md
Role	Agent	.claude/agents/aidlc-analyst.md
Cross-cutting rule	Rule	.claude/rules/aidlc-error-handling.md
Orchestration & routing	CLAUDE.md	.claude/CLAUDE.md
State management	Hook	.claude/settings.json

There's no separate automation tool that generates these files, and by design it isn't needed.

Cross-cutting logic (gate protocol, Q&A analysis, answer validation) already lives in the 4 agent files, not in skills. Skills delegate to agents and inherit shared protocols automatically. So when the AIDLC evolves:

• Change how gates work → edit 1 agent file → all skills inherit the change
• Change a specific stage → edit 1 SKILL.md
• Add a new stage → create 1 SKILL.md + update CLAUDE.md routing table
• Change terminology or validation rules → edit 1 rule file

These files are prompts, not compiled source. The content IS the product — each skill's core value is its domain-specific logic (question categories, artifact templates, analysis dimensions), which must be authored by hand regardless of any automation layer. Adding a generator on top would mean maintaining both the spec and the output, for changes that happen a few times per year at most.

The structure follows what Anthropic calls harness design — each skill, agent, and rule is a self-contained file with a single responsibility. When the AIDLC evolves, you update the specific files that correspond to the changed stages. There's no monolithic prompt to reverse-engineer; the mapping from AIDLC stage to file is 1:1.

In short: 24 focused markdown files in git, with shared behavior factored into agents (4) and rules (6). When bulk changes are needed, Claude Code itself is the multi-file edit tool. As the AIDLC methodology evolves, I can take ownership of maintaining the Claude Code harness to keep it in sync.

[harmjeff]

I see what you are syaing, but my question still stands. Do we now need to maintain all changes to AIDLC rules in two places?

1. Rules folder
2. Claude folder

[anhyobin]

@harmjeff You're right — from a repo maintenance perspective, yes.

▎ - aidlc-rules/ is the platform-agnostic spec, usable by any AI coding tool.
▎ - platforms/claude-code/.claude/ is the Claude Code-specific implementation.