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.
中文简介正在准备中。当前显示原文说明。
查看安装方法安装前可以查看交给 AI 代理的指令内容。
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.
中文简介正在准备中。当前显示原文说明。