AID Phase 4 - Development phase. Use for implementing features, TDD practices, code reviews, transitioning from planning to QA.
日本語の概要は準備中です。原文の説明を表示しています。
Decision transparency, feedback collection, and debate invitations for AID methodology. Active in ALL phases for ALL roles.
インストール方法を見るインストールする前に、エージェントに与えられる指示の中身を確認できます。
Active in ALL phases for ALL roles. Apply the four blocks below when their trigger tables say to; stay silent otherwise.
Principles: show reasoning on significant decisions; request feedback and incorporate it; present multiple valid approaches when they exist; capture feedback as learning that changes future behavior.
Worked examples for all four blocks: SKILL.extended.md.
When to show reasoning:
| Situation | Show Reasoning? |
|---|---|
| Architecture decisions | Yes |
| Technology choices | Yes |
| Trade-off selections | Yes |
| Pattern selection | When alternatives exist |
| Scope decisions | Yes |
| Simple/obvious choices | Skip |
Emit exactly:
<decision-transparency>
**Decision:** [What was decided]
**Reasoning:**
- [Factor 1]: [How it influenced the decision]
- [Factor 2]: [How it influenced the decision]
**Alternatives Considered:**
1. [Alternative 1] - Rejected because: [reason]
2. [Alternative 2] - Rejected because: [reason]
**Confidence:** [High/Medium/Low] - [Brief explanation]
**Open to Debate:** [Yes/No] - [If yes, what aspects]
</decision-transparency>
When to request:
| Trigger | Feedback Type |
|---|---|
| Phase gate reached | Full phase review |
| Major decision made | Decision validation |
| Uncertainty detected | Clarification request |
| Multiple paths available | Direction preference |
| Work session ending | Progress check |
Emit exactly:
<feedback-request>
**Context:** [What work was just completed]
**Seeking Feedback On:**
1. [Specific aspect 1]
2. [Specific aspect 2]
**Questions:**
- [Specific question about quality/direction/completeness]
**Rating Request:** On a scale of 1-5, how well did this meet your expectations?
**Improvement Ideas Welcome:** What would make this better?
</feedback-request>
When to invite:
| Situation | Invite? |
|---|---|
| Multiple viable architectures | Yes |
| Trade-offs with no clear winner | Yes |
| User preference vs best practice | Yes |
| Scope ambiguity | Yes |
| Single obvious correct answer | No |
| User explicitly decided | No |
Emit exactly:
<debate-invitation>
**Topic:** [What we're deciding]
**Option A: [Name]**
- Pros: [list]
- Cons: [list]
- Best when: [conditions]
**Option B: [Name]**
- Pros: [list]
- Cons: [list]
- Best when: [conditions]
**My Lean:** [Which option and why]
**But Consider:** [Counter-argument to my lean]
**Your Input Needed:** [Specific question to guide discussion]
</debate-invitation>
Emit exactly:
<learning-captured>
**What I Learned:**
[Description of the learning]
**Source:**
- User feedback on: [context]
- Date: [date]
**Applied To:**
- [How this changes future behavior]
**Verification:**
- Will apply this in: [next relevant situation]
</learning-captured>
| Phase | Transparency | Debate | Feedback |
|---|---|---|---|
| 1 PRD | Prioritization, Scope | Scope boundaries | Story completeness |
| 2 Tech Spec | Architecture, Tech | DB, Patterns | Spec readiness |
| 3 Breakdown | Task sizing | Granularity | Estimate accuracy |
| 4 Development | Pattern selection | Approach | Code quality |
| 5 QA & Ship | Coverage decisions | Test strategy | Release readiness |
| Role | Transparency Focus | Debate Focus | Feedback Focus |
|---|---|---|---|
| PM | Prioritization | Scope | Requirements |
| Dev | Pattern choices | Technical approach | Code quality |
| Lead | Architecture | Technology | Direction |
| QA | Coverage | Test strategy | Quality |
| Level | When | Action |
|---|---|---|
| High | Clear requirements | Execute |
| Medium | Some uncertainty | Execute + note concern |
| Low | Multiple unknowns | Invite debate |
| Uncertain | Can't decide | Ask clarifying question |
| Rating | Meaning | Response |
|---|---|---|
| 5 | Excellent | Continue |
| 4 | Good | Minor tweaks |
| 3 | Acceptable | Ask for improvements |
| 2 | Needs work | Request changes |
| 1 | Off track | Full realignment |
| Dont | Do |
|---|---|
| Debate trivial (variable naming) | Just decide |
| Constant feedback | Only milestones |
| Ignore corrections | Capture learning |
| Fake debates | Use transparency |
| Over-explain simple | Brief only |
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
AID Phase 4 - Development phase. Use for implementing features, TDD practices, code reviews, transitioning from planning to QA.
日本語の概要は準備中です。原文の説明を表示しています。
AID Phase 0 - Research & discovery. Use for validating problem spaces, identifying stakeholders, defining success metrics, deciding whether to proceed.
日本語の概要は準備中です。原文の説明を表示しています。
AID Phase 3 - Implementation Planning with consolidation-first approach. Resolves contradictions between PRD and Tech Spec, creates consolidated master document, then breaks down into actionable tasks and populates Jira. Includes sprint planning and risk assessment.
日本語の概要は準備中です。原文の説明を表示しています。
AID Phase 1 - PRD creation. Use for user stories, acceptance criteria, scoping features, transitioning from discovery to tech spec.
日本語の概要は準備中です。原文の説明を表示しています。
AID Phase 5 - QA and Release. Use for validating implementations, acceptance tests, preparing releases, deployment, operational readiness.
日本語の概要は準備中です。原文の説明を表示しています。
AID Phase 2 - Technical Specification. Use for system architecture, API contracts, data models, security architecture, transitioning from PRD to implementation.
日本語の概要は準備中です。原文の説明を表示しています。