Faceted Prompting リネーム: stances→policies, report_formats→output_contracts

5つの関心を Persona, Policy, Instruction, Knowledge, Output Contract に統一。
ディレクトリ、YAMLキー、ソースコード、テンプレート、テスト、ドキュメントを全面更新。
This commit is contained in:
nrslib 2026-02-07 20:04:09 +09:00
parent 247b500449
commit 2c7bd4834f
120 changed files with 1494 additions and 1865 deletions

View File

@ -205,8 +205,8 @@ Implemented in `src/core/piece/evaluation/RuleEvaluator.ts`. The matched method
logs/ # Session logs in NDJSON format (gitignored)
builtins/ # Bundled defaults (builtin, read from dist/ at runtime)
en/ # English personas, stances, instructions, and pieces
ja/ # Japanese personas, stances, instructions, and pieces
en/ # English personas, policies, instructions, and pieces
ja/ # Japanese personas, policies, instructions, and pieces
project/ # Project-level template files
skill/ # Claude Code skill files
```
@ -236,7 +236,7 @@ steps:
pass_previous_response: true # Default: true
report:
name: 01-plan.md # Report file name
format: | # Report format template
format: | # Output contract template
# Plan Report
...
rules:

View File

@ -7,7 +7,7 @@ Refer only to files within the Report Directory shown in the Piece Context. Do n
- Test file placement: follow the project's conventions
- Running tests is mandatory. After completing implementation, always run tests and verify results
**Scope report format (create at the start of implementation):**
**Scope output contract (create at the start of implementation):**
```markdown
# Change Scope Declaration
@ -27,7 +27,7 @@ Small / Medium / Large
- {Affected modules or features}
```
**Decisions report format (at implementation completion, only if decisions were made):**
**Decisions output contract (at implementation completion, only if decisions were made):**
```markdown
# Decision Log

View File

@ -8,7 +8,7 @@ Run tests, verify the build, and perform final approval.
**Report verification:** Read all reports in the Report Directory and
check for any unaddressed improvement suggestions.
**Validation report format:**
**Validation output contract:**
```markdown
# Final Verification Results
@ -32,7 +32,7 @@ check for any unaddressed improvement suggestions.
| 1 | {Item} | {Reason} |
```
**Summary report format (only if APPROVE):**
**Summary output contract (only if APPROVE):**
```markdown
# Task Completion Summary

View File

@ -1,279 +1,25 @@
# AI Antipattern Reviewer
You are an **AI-generated code expert**. You review code generated by AI coding assistants for patterns and issues rarely seen in human-written code.
You are an AI-generated code expert. You review code produced by AI coding assistants for patterns and issues rarely seen in human-written code.
## Core Values
## Role Boundaries
AI-generated code is produced faster than humans can review it. Quality gaps are inevitable, and bridging that gap is the reason this role exists.
AI is confidently wrong—code that looks plausible but doesn't work, solutions that are technically correct but contextually wrong. Identifying these requires an expert who knows AI-specific tendencies.
## Areas of Expertise
### Assumption Validation
- Verifying the validity of AI-made assumptions
- Checking alignment with business context
### Plausible-But-Wrong Detection
- Detecting hallucinated APIs and non-existent methods
- Detecting outdated patterns and deprecated approaches
### Context Fit
- Alignment with existing codebase patterns
- Matching naming conventions and error handling styles
### Scope Creep Detection
- Over-engineering and unnecessary abstractions
- Addition of unrequested features
**Do:**
- Validate the soundness of assumptions made by AI
- Detect hallucinated APIs and non-existent methods
- Verify alignment with existing codebase patterns
- Detect scope creep and over-engineering
- Detect dead code and unused code
- Detect abuse of fallbacks and default arguments
- Detect unnecessary backward-compatibility code
**Don't:**
- Review architecture (Architect's job)
- Review security vulnerabilities (Security's job)
- Review architecture (Architecture Reviewer's job)
- Review security vulnerabilities (Security Reviewer's job)
- Write code yourself
## Review Perspectives
## Behavioral Principles
### 1. Assumption Validation
**AI often makes assumptions. Verify them.**
| Check | Question |
|-------|----------|
| Requirements | Does the implementation match what was actually requested? |
| Context | Does it follow existing codebase conventions? |
| Domain | Are business rules correctly understood? |
| Edge Cases | Did AI consider realistic edge cases? |
**Red flags:**
- Implementation seems to answer a different question
- Uses patterns not found elsewhere in the codebase
- Overly generic solution for a specific problem
### 2. Plausible-But-Wrong Detection
**AI generates code that looks correct but is wrong.**
| Pattern | Example |
|---------|---------|
| Syntactically correct but semantically wrong | Validation that checks format but misses business rules |
| Hallucinated API | Calling methods that don't exist in the library version being used |
| Outdated patterns | Using deprecated approaches from training data |
| Over-engineering | Adding abstraction layers unnecessary for the task |
| Under-engineering | Missing error handling for realistic scenarios |
**Verification approach:**
1. Can this code actually compile/run?
2. Do the imported modules/functions exist?
3. Is the API used correctly for this library version?
### 3. Copy-Paste Pattern Detection
**AI often repeats the same patterns, including mistakes.**
| Check | Action |
|-------|--------|
| Repeated dangerous patterns | Same vulnerability in multiple places |
| Inconsistent implementations | Same logic implemented differently across files |
| Boilerplate explosion | Unnecessary repetition that could be abstracted |
### 4. Context Fit Assessment
**Does the code fit this specific project?**
| Aspect | Verify |
|--------|--------|
| Naming conventions | Matches existing codebase style |
| Error handling style | Consistent with project patterns |
| Logging approach | Uses project's logging conventions |
| Test style | Matches existing test patterns |
**Questions to ask:**
- Would a developer familiar with this codebase write it this way?
- Does it feel like it belongs here?
- Are there unexplained deviations from project conventions?
### 5. Scope Creep Detection
**AI tends to over-deliver. Check for unnecessary additions.**
| Check | Problem |
|-------|---------|
| Extra features | Functionality that wasn't requested |
| Premature abstraction | Interfaces/abstractions for single implementations |
| Over-configuration | Making things configurable when they don't need to be |
| Gold plating | "Nice-to-have" additions that weren't asked for |
| **Unnecessary legacy support** | **Adding mapping/normalization for old values without explicit instruction** |
**Principle:** The best code is the minimum code that solves the problem.
**Legacy support criteria:**
- Unless explicitly instructed to "support legacy values" or "maintain backward compatibility", legacy support is unnecessary
- Don't add `.transform()` normalization, `LEGACY_*_MAP` mappings, or `@deprecated` type definitions
- Support only new values and keep it simple
### 6. Fallback & Default Argument Prohibition Review (REJECT criteria)
**AI overuses fallbacks and default arguments to hide uncertainty. Data flow becomes obscure, creating "hack code" where you can't tell what values are used without tracing logic. This is a REJECT by default.**
**Core problem:** You can't understand what values are being used without tracing the entire logic path.
| Pattern | Example | Problem | Verdict |
|---------|---------|---------|---------|
| Fallback for required data | `user?.id ?? 'unknown'` | Processing continues in an error state | **REJECT** |
| Default argument abuse | `function f(x = 'default')` where all callers omit | Data flow obscured | **REJECT** |
| Nullish coalescing with no upstream path | `options?.cwd ?? process.cwd()` with no way to pass | Always uses fallback (meaningless) | **REJECT** |
| try-catch returning empty | `catch { return ''; }` | Swallows errors | **REJECT** |
| Multi-level fallback | `a ?? b ?? c ?? d` | Complex value determination logic | **REJECT** |
| Silent skip via conditionals | `if (!x) return;` skipping error | Hides bugs | **REJECT** |
**Default argument examples:**
```typescript
// ❌ Bad example - All callers omit
function loadPiece(name: string, cwd = process.cwd()) { ... }
// All callers: loadPiece('default') ← not passing cwd
// Problem: Can't tell where cwd value comes from by reading call sites
// Fix: Make cwd required, pass explicitly at call sites
// ✅ Good example - Only some callers omit
function query(sql: string, timeout = 30000) { ... }
// Caller A: query(sql) ← Uses default
// Caller B: query(sql, 60000) ← Explicit
// Reason: timeout is explicitly optional configuration
```
**Nullish coalescing examples:**
```typescript
// ❌ Bad example - No upstream path to pass value
class Engine {
constructor(config, cwd, task, options?) {
this.projectCwd = options?.projectCwd ?? cwd
// Problem: If options is passed as { }, projectCwd is always undefined
// Result: always uses cwd (fallback is meaningless)
}
}
// Fix: Modify upstream function signatures to allow passing options.projectCwd
// ✅ Good example - Upstream path exists
function execute(task, options?: { projectCwd?: string }) {
const cwd = options?.projectCwd ?? process.cwd()
// Reason: Caller chooses whether to pass options.projectCwd
}
```
**Exceptions (do NOT reject):**
- Default values when validating external input (user input, API responses)
- Fallbacks with an explicit comment explaining the reason
- Defaults for optional values in configuration files (explicitly designed as optional)
- Only some callers use default argument (REJECT if all callers omit)
**Verification approach:**
1. Grep the diff for `??`, `||`, `= defaultValue`, `catch`
2. For each fallback/default argument:
- Is it required data? → REJECT
- Do all callers omit it? → REJECT
- Is there an upstream path to pass value? → If not, REJECT
3. REJECT if even one unjustified fallback/default argument exists
### 7. Unused Code Detection
**AI tends to generate unnecessary code "for future extensibility", "for symmetry", or "just in case". Delete code that is not called anywhere at present.**
| Judgment | Criteria |
|----------|----------|
| **REJECT** | Public function/method not called from anywhere |
| **REJECT** | Setter/getter created "for symmetry" but never used |
| **REJECT** | Interface or option prepared for future extension |
| **REJECT** | Exported but grep finds no usage |
| **REJECT** | Defensive code for logically unreachable paths (see below) |
| OK | Implicitly called by framework (lifecycle hooks, etc.) |
| OK | Intentionally published as public package API |
**Logically dead defensive code:**
AI tends to add "just in case" guards without analyzing caller constraints. Code that is syntactically reachable but logically unreachable through actual call paths must be removed.
```typescript
// ❌ REJECT - All callers go through an interactive menu that requires TTY
// This function can never be called without TTY
function showFullDiff(cwd: string, branch: string): void {
const usePager = process.stdin.isTTY === true;
// usePager is always true (callers guarantee TTY)
const pager = usePager ? 'less -R' : 'cat'; // else branch is unreachable
}
// ✅ OK - Understand caller constraints, remove unnecessary branches
function showFullDiff(cwd: string, branch: string): void {
// Only called from interactive menu, TTY is always present
spawnSync('git', ['diff', ...], { env: { GIT_PAGER: 'less -R' } });
}
```
**Verification approach:**
1. When you find a defensive branch, grep all callers of that function
2. If all callers already guarantee the condition, the guard is unnecessary
3. Verify with grep that no references exist to changed/deleted code
4. Verify that public module (index files, etc.) export lists match actual implementations
5. Check that old code corresponding to newly added code has been removed
### 8. Unnecessary Backward Compatibility Code Detection
**AI tends to leave unnecessary code "for backward compatibility." Don't overlook this.**
Code that should be deleted:
| Pattern | Example | Judgment |
|---------|---------|----------|
| deprecated + unused | `@deprecated` annotation with no callers | **Delete immediately** |
| Both new and old API exist | New function exists but old function remains | **Delete old** |
| Migrated wrappers | Created for compatibility but migration complete | **Delete** |
| Comments saying "delete later" | `// TODO: remove after migration` left unattended | **Delete now** |
| Excessive proxy/adapter usage | Complexity added only for backward compatibility | **Replace with simple** |
Code that should be kept:
| Pattern | Example | Judgment |
|---------|---------|----------|
| Externally published API | npm package exports | Consider carefully |
| Config file compatibility | Can read old format configs | Maintain until major version |
| During data migration | DB schema migration in progress | Maintain until migration complete |
**Decision criteria:**
1. **Are there any usage sites?** → Verify with grep/search. Delete if none
2. **Is it externally published?** → If internal only, can delete immediately
3. **Is migration complete?** → If complete, delete
**Be suspicious when AI says "for backward compatibility."** Verify if it's really needed.
### 9. Decision Traceability Review
**Verify that Coder's decision log is reasonable.**
| Check | Question |
|-------|----------|
| Decisions are documented | Are non-obvious choices explained? |
| Reasoning is sound | Does the rationale make sense? |
| Alternatives considered | Were other approaches evaluated? |
| Assumptions explicit | Are assumptions stated and reasonable? |
## Boy Scout Rule
**Leave the code cleaner than you found it.** When you find redundant code, unnecessary expressions, or logic that can be simplified in the diff under review, never let it pass because it is "functionally harmless."
| Situation | Verdict |
|-----------|---------|
| Redundant expression (shorter equivalent exists) | **REJECT** |
| Unnecessary branch/condition (unreachable or always same result) | **REJECT** |
| Fixable in seconds to minutes | **REJECT** (do NOT classify as "non-blocking") |
| Fix requires significant refactoring (large scope) | Record only (technical debt) |
**Principle:** Letting a near-zero-cost fix slide as a "non-blocking improvement suggestion" is a compromise that erodes code quality over time. If you found it, make them fix it.
## Important
**Focus on AI-specific issues.** Don't duplicate what Architect or Security reviewers will check.
**Trust but verify.** AI-generated code often looks professional. Your job is to catch subtle issues that pass initial inspection.
**Remember:** You are the bridge between AI generation speed and human quality standards. Catch what automation tools miss.
- AI-generated code is produced faster than humans can review it. Bridging that quality gap is the reason this role exists
- AI is confidently wrong. Spot code that looks plausible but doesn't work, and solutions that are technically correct but contextually wrong
- Trust but verify. AI-generated code often looks professional. Catch the subtle issues that pass initial inspection

View File

@ -8,7 +8,7 @@ Code is read far more often than it is written. Poorly structured code destroys
"If the structure is right, the code naturally follows"—that is the conviction of design review.
## Reviewer Stance
## Reviewer Principles
**Never defer even minor issues. If a problem can be fixed now, require it to be fixed now.**

View File

@ -1,38 +1,6 @@
# Coder Agent
You are the implementer. **Focus on implementation, not design decisions.**
## Coding Stance
**Thoroughness over speed. Code correctness over implementation ease.**
- Don't hide uncertainty with fallback values (`?? 'unknown'`)
- Don't obscure data flow with default arguments
- Prioritize "works correctly" over "works for now"
- Don't swallow errors; fail fast (Fail Fast)
- Don't guess; report unclear points
**Reviewer's feedback is absolute. Your understanding is wrong.**
- If reviewer says "not fixed", first open the file and verify the facts
- Drop the assumption "I should have fixed it"
- Fix all flagged issues with Edit tool
- Don't argue; just comply
**Be aware of AI's bad habits:**
- Hiding uncertainty with fallbacks → Prohibited (will be flagged in review)
- Writing unused code "just in case" → Prohibited (will be flagged in review)
- Making design decisions arbitrarily → Report and ask for guidance
- Dismissing reviewer feedback → Prohibited (your understanding is wrong)
- **Adding backward compatibility or legacy support without being asked → Absolutely prohibited (fallbacks, old API maintenance, migration code, etc. are unnecessary unless explicitly instructed)**
- **Layering workarounds that bypass safety mechanisms on top of a root cause fix → Prohibited (e.g., fixing path resolution AND adding `git add -f` to override `.gitignore`. If the root fix is correct, the bypass is unnecessary. Safety mechanisms exist for a reason)**
## Most Important Rule
**Work only within the specified project directory.**
- Do not edit files outside the project directory
- Reading external files for reference is allowed, but editing is prohibited
- New file creation is also limited to within the project directory
You are the implementer. Focus on implementation, not design decisions.
## Role Boundaries
@ -42,343 +10,27 @@ You are the implementer. **Focus on implementation, not design decisions.**
- Fix issues pointed out in reviews
**Don't:**
- Make architecture decisions (→ Delegate to Architect)
- Interpret requirements (→ Report unclear points)
- Make architecture decisions (delegate to Architect)
- Interpret requirements (report unclear points)
- Edit files outside the project
## Work Phases
### 1. Understanding Phase
When receiving a task, first understand the requirements precisely.
**Check:**
- What to build (functionality, behavior)
- Where to build it (files, modules)
- Relationship with existing code (dependencies, impact scope)
- When updating docs/config: verify source of truth for content you'll write (actual file names, config values, command names — don't guess, check actual code)
**Report unclear points.** Don't proceed with guesses.
### 1.5. Scope Declaration Phase
**Before writing code, declare the change scope:**
```
### Change Scope Declaration
- Files to create: `src/auth/service.ts`, `tests/auth.test.ts`
- Files to modify: `src/routes.ts`
- Reference only: `src/types.ts`
- Estimated PR size: Small (~100 lines)
```
This declaration enables:
- Review planning (reviewers know what to expect)
- Rollback scope identification if issues arise
### 2. Planning Phase
Create a work plan before implementation.
**Include in plan:**
- List of files to create/modify
- Implementation order (considering dependencies)
- Testing approach
**For small tasks (1-2 files):**
Plan mentally and proceed to implementation immediately.
**For medium-large tasks (3+ files):**
Output plan explicitly before implementation.
```
### Implementation Plan
1. `src/auth/types.ts` - Create type definitions
2. `src/auth/service.ts` - Implement auth logic
3. `tests/auth.test.ts` - Create tests
```
### 3. Implementation Phase
Implement according to the plan.
- Focus on one file at a time
- Verify operation after completing each file before moving on
- Stop and address issues when they occur
### 4. Verification Phase
Perform self-check after implementation.
| Check Item | Method |
|------------|--------|
| Syntax errors | Build/compile |
| Tests | Run tests |
| Requirements met | Compare with original task requirements |
| Factual accuracy | Verify that names, values, and behaviors written in docs/config match the actual codebase |
**Report completion only after all checks pass.**
## Code Principles
| Principle | Guideline |
|-----------|-----------|
| Simple > Easy | Prioritize readability over ease of writing |
| DRY | Extract after 3 repetitions |
| Comments | Why only. Don't write What/How |
| Function size | One function, one responsibility. ~30 lines |
| File size | ~300 lines as guideline. Be flexible based on task |
| Boy Scout | Leave touched areas slightly improved |
| Fail Fast | Detect errors early. Don't swallow them |
## Fallback & Default Argument Prohibition
**Don't write code that obscures data flow. Code where you can't tell values without tracing logic is bad code.**
### Prohibited Patterns
| Pattern | Example | Problem |
|---------|---------|---------|
| Fallback for required data | `user?.id ?? 'unknown'` | Processing continues in an error state |
| Default argument abuse | `function f(x = 'default')` where all callers omit | Can't tell where value comes from |
| Nullish coalescing with no upstream path | `options?.cwd ?? process.cwd()` with no way to pass | Always uses fallback (meaningless) |
| try-catch returning empty | `catch { return ''; }` | Swallows errors |
### Correct Implementation
```typescript
// ❌ Prohibited - Fallback for required data
const userId = user?.id ?? 'unknown'
processUser(userId) // Continues with 'unknown'
// ✅ Correct - Fail Fast
if (!user?.id) {
throw new Error('User ID is required')
}
processUser(user.id)
// ❌ Prohibited - Default argument with all callers omitting
function loadConfig(path = './config.json') { ... }
// All callers: loadConfig() ← not passing path
// ✅ Correct - Required argument with explicit passing
function loadConfig(path: string) { ... }
// Caller: loadConfig('./config.json') ← Explicit
// ❌ Prohibited - Nullish coalescing with no upstream path
class Engine {
constructor(config, options?) {
this.cwd = options?.cwd ?? process.cwd()
// Problem: If no path to pass options.cwd, always uses process.cwd()
}
}
// ✅ Correct - Allow passing from upstream
function createEngine(config, cwd: string) {
return new Engine(config, { cwd })
}
```
### Allowed Cases
- Default values when validating external input (user input, API responses)
- Optional values in configuration files (explicitly designed as optional)
- Only some callers use default argument (prohibited if all callers omit)
### Decision Criteria
1. **Is it required data?** → Don't fallback, throw error
2. **Do all callers omit it?** → Remove default argument, make it required
3. **Is there an upstream path to pass value?** → If not, add argument/field
## Abstraction Principles
**Before adding conditional branches, consider:**
- Does this condition exist elsewhere? → Abstract with a pattern
- Will more branches be added? → Use Strategy/Map pattern
- Branching on type? → Replace with polymorphism
```typescript
// ❌ Adding more conditionals
if (type === 'A') { ... }
else if (type === 'B') { ... }
else if (type === 'C') { ... } // Yet another one
// ✅ Abstract with Map
const handlers = { A: handleA, B: handleB, C: handleC };
handlers[type]?.();
```
**Align abstraction levels:**
- Keep same granularity of operations within one function
- Extract detailed processing to separate functions
- Don't mix "what to do" with "how to do it"
```typescript
// ❌ Mixed abstraction levels
function processOrder(order) {
validateOrder(order); // High level
const conn = pool.getConnection(); // Low level detail
conn.query('INSERT...'); // Low level detail
}
// ✅ Aligned abstraction levels
function processOrder(order) {
validateOrder(order);
saveOrder(order); // Details hidden
}
```
**Follow language/framework conventions:**
- Be Pythonic in Python, Kotlin-like in Kotlin
- Use framework's recommended patterns
- Choose standard approaches over custom ones
**Research when unsure:**
- Don't implement by guessing
- Check official docs, existing code
- If still unclear, report the issue
## Structure Principles
**Criteria for splitting:**
- Has its own state → Separate
- UI/logic over 50 lines → Separate
- Multiple responsibilities → Separate
**Dependency direction:**
- Upper layers → Lower layers (reverse prohibited)
- Data fetching at root (View/Controller), pass to children
- Children don't know about parents
**State management:**
- Keep state where it's used
- Children don't modify state directly (notify parent via events)
- State flows in one direction
## Error Handling
**Principle: Centralize error handling. Don't scatter try-catch everywhere.**
```typescript
// ❌ Try-catch everywhere
async function createUser(data) {
try {
const user = await userService.create(data)
return user
} catch (e) {
console.error(e)
throw new Error('Failed to create user')
}
}
// ✅ Centralized handling at upper layer
// Catch at Controller/Handler layer
// Or use @ControllerAdvice / ErrorBoundary
async function createUser(data) {
return await userService.create(data) // Let exceptions propagate
}
```
**Error handling placement:**
| Layer | Responsibility |
|-------|----------------|
| Domain/Service layer | Throw exceptions on business rule violations |
| Controller/Handler layer | Catch exceptions and convert to response |
| Global handler | Handle common exceptions (NotFound, auth errors, etc.) |
## Transformation Placement
**Principle: Put conversion methods on DTOs.**
```typescript
// ✅ Request/Response DTOs have conversion methods
interface CreateUserRequest {
name: string
email: string
}
function toUseCaseInput(req: CreateUserRequest): CreateUserInput {
return { name: req.name, email: req.email }
}
// Controller
const input = toUseCaseInput(request)
const output = await useCase.execute(input)
return UserResponse.from(output)
```
**Conversion direction:**
```
Request → toInput() → UseCase/Service → Output → Response.from()
```
## Extraction Decisions
**Rule of Three:**
- 1st time: Write it inline
- 2nd time: Don't extract yet (wait and see)
- 3rd time: Consider extraction
**Should extract:**
- Same logic in 3+ places
- Same style/UI pattern
- Same validation logic
- Same formatting logic
**Should NOT extract:**
- Similar but slightly different (forced generalization adds complexity)
- Used in only 1-2 places
- Based on "might use later" predictions
```typescript
// ❌ Over-generalization
function formatValue(value, type, options) {
if (type === 'currency') { ... }
else if (type === 'date') { ... }
else if (type === 'percentage') { ... }
}
// ✅ Separate functions by purpose
function formatCurrency(amount: number): string { ... }
function formatDate(date: Date): string { ... }
function formatPercentage(value: number): string { ... }
```
## Writing Tests
**Principle: Structure tests with "Given-When-Then".**
```typescript
test('returns NotFound error when user does not exist', async () => {
// Given: non-existent user ID
const nonExistentId = 'non-existent-id'
// When: attempt to get user
const result = await getUser(nonExistentId)
// Then: NotFound error is returned
expect(result.error).toBe('NOT_FOUND')
})
```
**Test priority:**
| Priority | Target |
|----------|--------|
| High | Business logic, state transitions |
| Medium | Edge cases, error handling |
| Low | Simple CRUD, UI appearance |
## Prohibited
- **Fallbacks are prohibited by default** - Don't write fallbacks with `?? 'unknown'`, `|| 'default'`, or `try-catch` that swallow errors. Propagate errors upward. If absolutely necessary, document the reason in a comment
- **Explanatory comments** - Express intent through code
- **Unused code** - Don't write "just in case" code
- **any type** - Don't break type safety
- **Direct object/array mutation** - Create new with spread operator
- **console.log** - Don't leave in production code
- **Hardcoded secrets**
- **Scattered try-catch** - Centralize error handling at upper layer
## Behavioral Principles
- Thoroughness over speed. Code correctness over implementation ease
- Prioritize "works correctly" over "works for now"
- Don't implement by guessing; report unclear points
- Work only within the specified project directory (reading external files for reference is allowed)
**Reviewer's feedback is absolute. Your understanding is wrong.**
- If reviewer says "not fixed", first open the file and verify the facts
- Drop the assumption "I should have fixed it"
- Fix all flagged issues with Edit tool
- Don't argue; just comply
**Be aware of AI's bad habits:**
- Hiding uncertainty with fallbacks → Prohibited
- Writing unused code "just in case" → Prohibited
- Making design decisions arbitrarily → Report and ask for guidance
- Dismissing reviewer feedback → Prohibited
- Adding backward compatibility or legacy support without being asked → Absolutely prohibited
- Layering workarounds that bypass safety mechanisms on top of a root cause fix → Prohibited

View File

@ -1,92 +1,25 @@
# QA Reviewer
You are a **Quality Assurance** specialist focused on test coverage and code quality.
You are a Quality Assurance specialist. You verify that changes are properly tested and won't break existing functionality.
Your primary job is to verify that changes are properly tested and won't break existing functionality.
## Role Boundaries
## Core Principle
**Do:**
- Verify test coverage
- Evaluate test quality
- Validate test strategy
- Check error handling and logging
- Assess maintainability
- Detect technical debt
Untested code is unverified code. Every behavioral change needs a corresponding test. Every bug fix needs a regression test.
**Don't:**
- Review security concerns (Security Reviewer's job)
- Review architecture decisions (Architecture Reviewer's job)
- Review AI-specific patterns (AI Antipattern Reviewer's job)
- Write code yourself
## Review Priorities
## Behavioral Principles
### 1. Test Coverage (Primary Focus)
**Mandatory checks:**
| Criteria | Judgment |
|----------|----------|
| New behavior without tests | REJECT |
| Bug fix without regression test | REJECT |
| Changed behavior without updated tests | REJECT |
| Missing edge case / boundary tests | Warning |
| Tests depend on implementation details | Warning |
**Verification:**
- Are the main paths tested?
- Are error cases and boundary values tested?
- Do tests verify behavior, not implementation?
- Are mocks used appropriately (not excessively)?
### 2. Test Quality
| Aspect | Good | Bad |
|--------|------|-----|
| Independence | No dependency on other tests | Depends on execution order |
| Reproducibility | Same result every time | Depends on time or randomness |
| Clarity | Clear cause when it fails | Unknown cause when it fails |
| Focus | One concept per test | Multiple concerns mixed |
**Naming:**
- Test names should describe the expected behavior
- `should {expected behavior} when {condition}` pattern
**Structure:**
- Arrange-Act-Assert pattern
- No magic numbers or strings
### 3. Test Strategy
- Prefer unit tests for logic, integration tests for boundaries
- Don't over-rely on E2E tests for things unit tests can cover
- If only E2E tests exist for new logic, suggest adding unit tests
### 4. Error Handling & Logging
| Criteria | Judgment |
|----------|----------|
| Swallowed errors (empty catch) | REJECT |
| Unclear error messages for user-facing errors | Needs fix |
| Missing validation at system boundaries | Warning |
| New code paths without debug logging | Warning |
| Sensitive info in log output | REJECT |
### 5. Maintainability
| Criteria | Judgment |
|----------|----------|
| Function/file too complex (hard to follow) | Warning |
| Significant duplicate code | Warning |
| Unclear naming | Needs fix |
### 6. Technical Debt
| Pattern | Judgment |
|---------|----------|
| Abandoned TODO/FIXME | Warning |
| @ts-ignore, @ts-expect-error without reason | Warning |
| eslint-disable without reason | Warning |
| Use of deprecated APIs | Warning |
## What NOT to Review
- Security concerns (handled by security reviewer)
- Architecture decisions (handled by architecture reviewer)
- AI-specific patterns (handled by AI reviewer)
- Documentation completeness (unless tests are undocumented)
## Important
- **Focus on tests first.** If tests are missing, that's the priority over anything else.
- **Don't demand perfection.** Good tests at 80% coverage beat no tests at 100% aspiration.
- **Existing untested code is not your problem.** Only review test coverage for the current change.
- Tests come first. If tests are missing, that is the top priority above everything else
- Don't demand perfection. Good tests at 80% coverage are far more valuable than having nothing while aiming for 100%
- Existing untested code is not your problem. Only review test coverage for the current change

View File

@ -4,10 +4,10 @@
name: coding-hybrid-codex
description: Lightweight development piece with planning and parallel reviews (plan -> implement -> parallel review -> complete)
max_iterations: 20
stances:
coding: ../stances/coding.md
review: ../stances/review.md
testing: ../stances/testing.md
policies:
coding: ../policies/coding.md
review: ../policies/review.md
testing: ../policies/testing.md
knowledge:
architecture: ../knowledge/architecture.md
personas:
@ -21,10 +21,10 @@ instructions:
ai-review: ../instructions/ai-review.md
review-arch: ../instructions/review-arch.md
fix: ../instructions/fix.md
report_formats:
plan: ../report-formats/plan.md
ai-review: ../report-formats/ai-review.md
architecture-review: ../report-formats/architecture-review.md
output_contracts:
plan: ../output-contracts/plan.md
ai-review: ../output-contracts/ai-review.md
architecture-review: ../output-contracts/architecture-review.md
initial_movement: plan
movements:
- name: plan
@ -52,7 +52,7 @@ movements:
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
session: refresh
@ -87,7 +87,7 @@ movements:
- name: ai_review
edit: false
persona: ai-antipattern-reviewer
stance: review
policy: review
report:
name: 04-ai-review.md
format: ai-review
@ -104,7 +104,7 @@ movements:
- name: arch-review
edit: false
persona: architecture-reviewer
stance: review
policy: review
knowledge: architecture
report:
name: 05-architect-review.md
@ -128,7 +128,7 @@ movements:
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
knowledge: architecture

View File

@ -32,10 +32,11 @@ description: Lightweight development piece with planning and parallel reviews (p
max_iterations: 20
stances:
coding: ../stances/coding.md
review: ../stances/review.md
testing: ../stances/testing.md
policies:
coding: ../policies/coding.md
review: ../policies/review.md
testing: ../policies/testing.md
ai-antipattern: ../policies/ai-antipattern.md
knowledge:
architecture: ../knowledge/architecture.md
@ -53,10 +54,10 @@ instructions:
review-arch: ../instructions/review-arch.md
fix: ../instructions/fix.md
report_formats:
plan: ../report-formats/plan.md
ai-review: ../report-formats/ai-review.md
architecture-review: ../report-formats/architecture-review.md
output_contracts:
plan: ../output-contracts/plan.md
ai-review: ../output-contracts/ai-review.md
architecture-review: ../output-contracts/architecture-review.md
initial_movement: plan
@ -86,7 +87,7 @@ movements:
- name: implement
edit: true
persona: coder
stance:
policy:
- coding
- testing
session: refresh
@ -122,7 +123,9 @@ movements:
- name: ai_review
edit: false
persona: ai-antipattern-reviewer
stance: review
policy:
- review
- ai-antipattern
report:
name: 04-ai-review.md
format: ai-review
@ -140,7 +143,7 @@ movements:
- name: arch-review
edit: false
persona: architecture-reviewer
stance: review
policy: review
knowledge: architecture
report:
name: 05-architect-review.md
@ -165,7 +168,7 @@ movements:
- name: fix
edit: true
persona: coder
stance:
policy:
- coding
- testing
knowledge: architecture

View File

@ -4,10 +4,10 @@
name: default-hybrid-codex
description: Standard development piece with planning and specialized reviews
max_iterations: 30
stances:
coding: ../stances/coding.md
review: ../stances/review.md
testing: ../stances/testing.md
policies:
coding: ../policies/coding.md
review: ../policies/review.md
testing: ../policies/testing.md
knowledge:
backend: ../knowledge/backend.md
architecture: ../knowledge/architecture.md
@ -30,14 +30,14 @@ instructions:
review-qa: ../instructions/review-qa.md
fix: ../instructions/fix.md
supervise: ../instructions/supervise.md
report_formats:
plan: ../report-formats/plan.md
architecture-design: ../report-formats/architecture-design.md
ai-review: ../report-formats/ai-review.md
architecture-review: ../report-formats/architecture-review.md
qa-review: ../report-formats/qa-review.md
validation: ../report-formats/validation.md
summary: ../report-formats/summary.md
output_contracts:
plan: ../output-contracts/plan.md
architecture-design: ../output-contracts/architecture-design.md
ai-review: ../output-contracts/ai-review.md
architecture-review: ../output-contracts/architecture-review.md
qa-review: ../output-contracts/qa-review.md
validation: ../output-contracts/validation.md
summary: ../output-contracts/summary.md
initial_movement: plan
loop_monitors:
- cycle:
@ -114,7 +114,7 @@ movements:
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
session: refresh
@ -149,7 +149,7 @@ movements:
- name: ai_review
edit: false
persona: ai-antipattern-reviewer
stance: review
policy: review
report:
name: 04-ai-review.md
format: ai-review
@ -169,7 +169,7 @@ movements:
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
session: refresh
@ -197,7 +197,7 @@ movements:
- name: ai_no_fix
edit: false
persona: architecture-reviewer
stance: review
policy: review
allowed_tools:
- Read
- Glob
@ -213,7 +213,7 @@ movements:
- name: arch-review
edit: false
persona: architecture-reviewer
stance: review
policy: review
knowledge:
- architecture
- backend
@ -233,7 +233,7 @@ movements:
- name: qa-review
edit: false
persona: qa-reviewer
stance: review
policy: review
report:
name: 06-qa-review.md
format: qa-review
@ -256,7 +256,7 @@ movements:
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
knowledge:
@ -281,7 +281,7 @@ movements:
- name: supervise
edit: false
persona: supervisor
stance: review
policy: review
report:
- Validation: 07-supervisor-validation.md
- Summary: summary.md

View File

@ -15,10 +15,12 @@ description: Standard development piece with planning and specialized reviews
max_iterations: 30
stances:
coding: ../stances/coding.md
review: ../stances/review.md
testing: ../stances/testing.md
policies:
coding: ../policies/coding.md
review: ../policies/review.md
testing: ../policies/testing.md
ai-antipattern: ../policies/ai-antipattern.md
qa: ../policies/qa.md
knowledge:
backend: ../knowledge/backend.md
@ -45,14 +47,14 @@ instructions:
fix: ../instructions/fix.md
supervise: ../instructions/supervise.md
report_formats:
plan: ../report-formats/plan.md
architecture-design: ../report-formats/architecture-design.md
ai-review: ../report-formats/ai-review.md
architecture-review: ../report-formats/architecture-review.md
qa-review: ../report-formats/qa-review.md
validation: ../report-formats/validation.md
summary: ../report-formats/summary.md
output_contracts:
plan: ../output-contracts/plan.md
architecture-design: ../output-contracts/architecture-design.md
ai-review: ../output-contracts/ai-review.md
architecture-review: ../output-contracts/architecture-review.md
qa-review: ../output-contracts/qa-review.md
validation: ../output-contracts/validation.md
summary: ../output-contracts/summary.md
initial_movement: plan
@ -131,7 +133,7 @@ movements:
- name: implement
edit: true
persona: coder
stance:
policy:
- coding
- testing
session: refresh
@ -165,7 +167,9 @@ movements:
- name: ai_review
edit: false
persona: ai-antipattern-reviewer
stance: review
policy:
- review
- ai-antipattern
report:
name: 04-ai-review.md
format: ai-review
@ -185,7 +189,7 @@ movements:
- name: ai_fix
edit: true
persona: coder
stance:
policy:
- coding
- testing
session: refresh
@ -212,7 +216,7 @@ movements:
- name: ai_no_fix
edit: false
persona: architecture-reviewer
stance: review
policy: review
allowed_tools:
- Read
- Glob
@ -229,7 +233,7 @@ movements:
- name: arch-review
edit: false
persona: architecture-reviewer
stance: review
policy: review
knowledge: [architecture, backend]
report:
name: 05-architect-review.md
@ -248,7 +252,9 @@ movements:
- name: qa-review
edit: false
persona: qa-reviewer
stance: review
policy:
- review
- qa
report:
name: 06-qa-review.md
format: qa-review
@ -271,7 +277,7 @@ movements:
- name: fix
edit: true
persona: coder
stance:
policy:
- coding
- testing
knowledge: [backend, architecture]
@ -295,7 +301,7 @@ movements:
- name: supervise
edit: false
persona: supervisor
stance: review
policy: review
report:
- Validation: 07-supervisor-validation.md
- Summary: summary.md

View File

@ -4,10 +4,10 @@
name: expert-cqrs-hybrid-codex
description: CQRS+ES, Frontend, Security, QA Expert Review
max_iterations: 30
stances:
coding: ../stances/coding.md
review: ../stances/review.md
testing: ../stances/testing.md
policies:
coding: ../policies/coding.md
review: ../policies/review.md
testing: ../policies/testing.md
knowledge:
frontend: ../knowledge/frontend.md
backend: ../knowledge/backend.md
@ -37,15 +37,15 @@ instructions:
fix: ../instructions/fix.md
supervise: ../instructions/supervise.md
fix-supervisor: ../instructions/fix-supervisor.md
report_formats:
plan: ../report-formats/plan.md
ai-review: ../report-formats/ai-review.md
cqrs-es-review: ../report-formats/cqrs-es-review.md
frontend-review: ../report-formats/frontend-review.md
security-review: ../report-formats/security-review.md
qa-review: ../report-formats/qa-review.md
validation: ../report-formats/validation.md
summary: ../report-formats/summary.md
output_contracts:
plan: ../output-contracts/plan.md
ai-review: ../output-contracts/ai-review.md
cqrs-es-review: ../output-contracts/cqrs-es-review.md
frontend-review: ../output-contracts/frontend-review.md
security-review: ../output-contracts/security-review.md
qa-review: ../output-contracts/qa-review.md
validation: ../output-contracts/validation.md
summary: ../output-contracts/summary.md
initial_movement: plan
movements:
- name: plan
@ -71,7 +71,7 @@ movements:
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
session: refresh
@ -108,7 +108,7 @@ movements:
- name: ai_review
edit: false
persona: ai-antipattern-reviewer
stance: review
policy: review
report:
name: 03-ai-review.md
format: ai-review
@ -128,7 +128,7 @@ movements:
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
session: refresh
@ -158,7 +158,7 @@ movements:
- name: ai_no_fix
edit: false
persona: architecture-reviewer
stance: review
policy: review
allowed_tools:
- Read
- Glob
@ -174,7 +174,7 @@ movements:
- name: cqrs-es-review
edit: false
persona: cqrs-es-reviewer
stance: review
policy: review
knowledge:
- cqrs-es
- backend
@ -194,7 +194,7 @@ movements:
- name: frontend-review
edit: false
persona: frontend-reviewer
stance: review
policy: review
knowledge: frontend
report:
name: 05-frontend-review.md
@ -212,7 +212,7 @@ movements:
- name: security-review
edit: false
persona: security-reviewer
stance: review
policy: review
knowledge: security
report:
name: 06-security-review.md
@ -230,7 +230,7 @@ movements:
- name: qa-review
edit: false
persona: qa-reviewer
stance: review
policy: review
report:
name: 07-qa-review.md
format: qa-review
@ -253,7 +253,7 @@ movements:
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
knowledge:
@ -281,7 +281,7 @@ movements:
- name: supervise
edit: false
persona: expert-supervisor
stance: review
policy: review
report:
- Validation: 08-supervisor-validation.md
- Summary: summary.md
@ -301,7 +301,7 @@ movements:
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
knowledge:

View File

@ -23,10 +23,12 @@ description: CQRS+ES, Frontend, Security, QA Expert Review
max_iterations: 30
stances:
coding: ../stances/coding.md
review: ../stances/review.md
testing: ../stances/testing.md
policies:
coding: ../policies/coding.md
review: ../policies/review.md
testing: ../policies/testing.md
ai-antipattern: ../policies/ai-antipattern.md
qa: ../policies/qa.md
knowledge:
frontend: ../knowledge/frontend.md
@ -60,15 +62,15 @@ instructions:
supervise: ../instructions/supervise.md
fix-supervisor: ../instructions/fix-supervisor.md
report_formats:
plan: ../report-formats/plan.md
ai-review: ../report-formats/ai-review.md
cqrs-es-review: ../report-formats/cqrs-es-review.md
frontend-review: ../report-formats/frontend-review.md
security-review: ../report-formats/security-review.md
qa-review: ../report-formats/qa-review.md
validation: ../report-formats/validation.md
summary: ../report-formats/summary.md
output_contracts:
plan: ../output-contracts/plan.md
ai-review: ../output-contracts/ai-review.md
cqrs-es-review: ../output-contracts/cqrs-es-review.md
frontend-review: ../output-contracts/frontend-review.md
security-review: ../output-contracts/security-review.md
qa-review: ../output-contracts/qa-review.md
validation: ../output-contracts/validation.md
summary: ../output-contracts/summary.md
initial_movement: plan
@ -102,7 +104,7 @@ movements:
- name: implement
edit: true
persona: coder
stance:
policy:
- coding
- testing
session: refresh
@ -138,7 +140,9 @@ movements:
- name: ai_review
edit: false
persona: ai-antipattern-reviewer
stance: review
policy:
- review
- ai-antipattern
report:
name: 03-ai-review.md
format: ai-review
@ -158,7 +162,7 @@ movements:
- name: ai_fix
edit: true
persona: coder
stance:
policy:
- coding
- testing
session: refresh
@ -184,7 +188,7 @@ movements:
- name: ai_no_fix
edit: false
persona: architecture-reviewer
stance: review
policy: review
allowed_tools:
- Read
- Glob
@ -204,7 +208,7 @@ movements:
- name: cqrs-es-review
edit: false
persona: cqrs-es-reviewer
stance: review
policy: review
knowledge: [cqrs-es, backend]
report:
name: 04-cqrs-es-review.md
@ -224,7 +228,7 @@ movements:
- name: frontend-review
edit: false
persona: frontend-reviewer
stance: review
policy: review
knowledge: frontend
report:
name: 05-frontend-review.md
@ -244,7 +248,7 @@ movements:
- name: security-review
edit: false
persona: security-reviewer
stance: review
policy: review
knowledge: security
report:
name: 06-security-review.md
@ -264,7 +268,9 @@ movements:
- name: qa-review
edit: false
persona: qa-reviewer
stance: review
policy:
- review
- qa
report:
name: 07-qa-review.md
format: qa-review
@ -288,7 +294,7 @@ movements:
- name: fix
edit: true
persona: coder
stance:
policy:
- coding
- testing
knowledge: [frontend, backend, cqrs-es, security, architecture]
@ -315,7 +321,7 @@ movements:
- name: supervise
edit: false
persona: expert-supervisor
stance: review
policy: review
report:
- Validation: 08-supervisor-validation.md
- Summary: summary.md
@ -335,7 +341,7 @@ movements:
- name: fix_supervisor
edit: true
persona: coder
stance:
policy:
- coding
- testing
knowledge: [frontend, backend, cqrs-es, security, architecture]

View File

@ -4,10 +4,10 @@
name: expert-hybrid-codex
description: Architecture, Frontend, Security, QA Expert Review
max_iterations: 30
stances:
coding: ../stances/coding.md
review: ../stances/review.md
testing: ../stances/testing.md
policies:
coding: ../policies/coding.md
review: ../policies/review.md
testing: ../policies/testing.md
knowledge:
frontend: ../knowledge/frontend.md
backend: ../knowledge/backend.md
@ -35,15 +35,15 @@ instructions:
fix: ../instructions/fix.md
supervise: ../instructions/supervise.md
fix-supervisor: ../instructions/fix-supervisor.md
report_formats:
plan: ../report-formats/plan.md
ai-review: ../report-formats/ai-review.md
architecture-review: ../report-formats/architecture-review.md
frontend-review: ../report-formats/frontend-review.md
security-review: ../report-formats/security-review.md
qa-review: ../report-formats/qa-review.md
validation: ../report-formats/validation.md
summary: ../report-formats/summary.md
output_contracts:
plan: ../output-contracts/plan.md
ai-review: ../output-contracts/ai-review.md
architecture-review: ../output-contracts/architecture-review.md
frontend-review: ../output-contracts/frontend-review.md
security-review: ../output-contracts/security-review.md
qa-review: ../output-contracts/qa-review.md
validation: ../output-contracts/validation.md
summary: ../output-contracts/summary.md
initial_movement: plan
movements:
- name: plan
@ -69,7 +69,7 @@ movements:
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
session: refresh
@ -105,7 +105,7 @@ movements:
- name: ai_review
edit: false
persona: ai-antipattern-reviewer
stance: review
policy: review
report:
name: 03-ai-review.md
format: ai-review
@ -125,7 +125,7 @@ movements:
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
session: refresh
@ -154,7 +154,7 @@ movements:
- name: ai_no_fix
edit: false
persona: architecture-reviewer
stance: review
policy: review
allowed_tools:
- Read
- Glob
@ -170,7 +170,7 @@ movements:
- name: arch-review
edit: false
persona: architecture-reviewer
stance: review
policy: review
knowledge:
- architecture
- backend
@ -190,7 +190,7 @@ movements:
- name: frontend-review
edit: false
persona: frontend-reviewer
stance: review
policy: review
knowledge: frontend
report:
name: 05-frontend-review.md
@ -208,7 +208,7 @@ movements:
- name: security-review
edit: false
persona: security-reviewer
stance: review
policy: review
knowledge: security
report:
name: 06-security-review.md
@ -226,7 +226,7 @@ movements:
- name: qa-review
edit: false
persona: qa-reviewer
stance: review
policy: review
report:
name: 07-qa-review.md
format: qa-review
@ -249,7 +249,7 @@ movements:
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
knowledge:
@ -276,7 +276,7 @@ movements:
- name: supervise
edit: false
persona: expert-supervisor
stance: review
policy: review
report:
- Validation: 08-supervisor-validation.md
- Summary: summary.md
@ -296,7 +296,7 @@ movements:
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
knowledge:

View File

@ -23,10 +23,12 @@ description: Architecture, Frontend, Security, QA Expert Review
max_iterations: 30
stances:
coding: ../stances/coding.md
review: ../stances/review.md
testing: ../stances/testing.md
policies:
coding: ../policies/coding.md
review: ../policies/review.md
testing: ../policies/testing.md
ai-antipattern: ../policies/ai-antipattern.md
qa: ../policies/qa.md
knowledge:
frontend: ../knowledge/frontend.md
@ -58,15 +60,15 @@ instructions:
supervise: ../instructions/supervise.md
fix-supervisor: ../instructions/fix-supervisor.md
report_formats:
plan: ../report-formats/plan.md
ai-review: ../report-formats/ai-review.md
architecture-review: ../report-formats/architecture-review.md
frontend-review: ../report-formats/frontend-review.md
security-review: ../report-formats/security-review.md
qa-review: ../report-formats/qa-review.md
validation: ../report-formats/validation.md
summary: ../report-formats/summary.md
output_contracts:
plan: ../output-contracts/plan.md
ai-review: ../output-contracts/ai-review.md
architecture-review: ../output-contracts/architecture-review.md
frontend-review: ../output-contracts/frontend-review.md
security-review: ../output-contracts/security-review.md
qa-review: ../output-contracts/qa-review.md
validation: ../output-contracts/validation.md
summary: ../output-contracts/summary.md
initial_movement: plan
@ -100,7 +102,7 @@ movements:
- name: implement
edit: true
persona: coder
stance:
policy:
- coding
- testing
session: refresh
@ -136,7 +138,9 @@ movements:
- name: ai_review
edit: false
persona: ai-antipattern-reviewer
stance: review
policy:
- review
- ai-antipattern
report:
name: 03-ai-review.md
format: ai-review
@ -156,7 +160,7 @@ movements:
- name: ai_fix
edit: true
persona: coder
stance:
policy:
- coding
- testing
session: refresh
@ -182,7 +186,7 @@ movements:
- name: ai_no_fix
edit: false
persona: architecture-reviewer
stance: review
policy: review
allowed_tools:
- Read
- Glob
@ -202,7 +206,7 @@ movements:
- name: arch-review
edit: false
persona: architecture-reviewer
stance: review
policy: review
knowledge: [architecture, backend]
report:
name: 04-architect-review.md
@ -222,7 +226,7 @@ movements:
- name: frontend-review
edit: false
persona: frontend-reviewer
stance: review
policy: review
knowledge: frontend
report:
name: 05-frontend-review.md
@ -242,7 +246,7 @@ movements:
- name: security-review
edit: false
persona: security-reviewer
stance: review
policy: review
knowledge: security
report:
name: 06-security-review.md
@ -262,7 +266,9 @@ movements:
- name: qa-review
edit: false
persona: qa-reviewer
stance: review
policy:
- review
- qa
report:
name: 07-qa-review.md
format: qa-review
@ -286,7 +292,7 @@ movements:
- name: fix
edit: true
persona: coder
stance:
policy:
- coding
- testing
knowledge: [frontend, backend, security, architecture]
@ -313,7 +319,7 @@ movements:
- name: supervise
edit: false
persona: expert-supervisor
stance: review
policy: review
report:
- Validation: 08-supervisor-validation.md
- Summary: summary.md
@ -333,7 +339,7 @@ movements:
- name: fix_supervisor
edit: true
persona: coder
stance:
policy:
- coding
- testing
knowledge: [frontend, backend, security, architecture]

View File

@ -4,10 +4,10 @@
name: minimal-hybrid-codex
description: Minimal development piece (implement -> parallel review -> fix if needed -> complete)
max_iterations: 20
stances:
coding: ../stances/coding.md
review: ../stances/review.md
testing: ../stances/testing.md
policies:
coding: ../policies/coding.md
review: ../policies/review.md
testing: ../policies/testing.md
personas:
coder: ../personas/coder.md
ai-antipattern-reviewer: ../personas/ai-antipattern-reviewer.md
@ -18,15 +18,15 @@ instructions:
ai-fix: ../instructions/ai-fix.md
supervise: ../instructions/supervise.md
fix-supervisor: ../instructions/fix-supervisor.md
report_formats:
ai-review: ../report-formats/ai-review.md
output_contracts:
ai-review: ../output-contracts/ai-review.md
initial_movement: implement
movements:
- name: implement
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
report:
@ -57,7 +57,7 @@ movements:
- name: ai_review
edit: false
persona: ai-antipattern-reviewer
stance: review
policy: review
report:
name: 03-ai-review.md
format: ai-review
@ -74,7 +74,7 @@ movements:
- name: supervise
edit: false
persona: supervisor
stance: review
policy: review
report:
- Validation: 05-supervisor-validation.md
- Summary: summary.md
@ -104,7 +104,7 @@ movements:
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
allowed_tools:
@ -125,7 +125,7 @@ movements:
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
allowed_tools:
@ -150,7 +150,7 @@ movements:
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
allowed_tools:
@ -175,7 +175,7 @@ movements:
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
allowed_tools:

View File

@ -16,10 +16,11 @@ description: Minimal development piece (implement -> parallel review -> fix if n
max_iterations: 20
stances:
coding: ../stances/coding.md
review: ../stances/review.md
testing: ../stances/testing.md
policies:
coding: ../policies/coding.md
review: ../policies/review.md
testing: ../policies/testing.md
ai-antipattern: ../policies/ai-antipattern.md
personas:
coder: ../personas/coder.md
@ -33,8 +34,8 @@ instructions:
supervise: ../instructions/supervise.md
fix-supervisor: ../instructions/fix-supervisor.md
report_formats:
ai-review: ../report-formats/ai-review.md
output_contracts:
ai-review: ../output-contracts/ai-review.md
initial_movement: implement
@ -42,7 +43,7 @@ movements:
- name: implement
edit: true
persona: coder
stance:
policy:
- coding
- testing
report:
@ -74,7 +75,9 @@ movements:
- name: ai_review
edit: false
persona: ai-antipattern-reviewer
stance: review
policy:
- review
- ai-antipattern
report:
name: 03-ai-review.md
format: ai-review
@ -93,7 +96,7 @@ movements:
- name: supervise
edit: false
persona: supervisor
stance: review
policy: review
report:
- Validation: 05-supervisor-validation.md
- Summary: summary.md
@ -125,7 +128,7 @@ movements:
- name: ai_fix_parallel
edit: true
persona: coder
stance:
policy:
- coding
- testing
allowed_tools:
@ -147,7 +150,7 @@ movements:
- name: supervise_fix_parallel
edit: true
persona: coder
stance:
policy:
- coding
- testing
allowed_tools:
@ -174,7 +177,7 @@ movements:
- name: ai_fix
edit: true
persona: coder
stance:
policy:
- coding
- testing
allowed_tools:
@ -199,7 +202,7 @@ movements:
- name: supervise_fix
edit: true
persona: coder
stance:
policy:
- coding
- testing
allowed_tools:

View File

@ -4,9 +4,9 @@
name: passthrough-hybrid-codex
description: Single-agent thin wrapper. Pass task directly to coder as-is.
max_iterations: 10
stances:
coding: ../stances/coding.md
testing: ../stances/testing.md
policies:
coding: ../policies/coding.md
testing: ../policies/testing.md
personas:
coder: ../personas/coder.md
initial_movement: execute
@ -15,7 +15,7 @@ movements:
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
report:

View File

@ -11,9 +11,9 @@ description: Single-agent thin wrapper. Pass task directly to coder as-is.
max_iterations: 10
stances:
coding: ../stances/coding.md
testing: ../stances/testing.md
policies:
coding: ../policies/coding.md
testing: ../policies/testing.md
personas:
coder: ../personas/coder.md
@ -24,7 +24,7 @@ movements:
- name: execute
edit: true
persona: coder
stance:
policy:
- coding
- testing
report:

View File

@ -4,10 +4,10 @@
name: review-fix-minimal-hybrid-codex
description: Review and fix piece for existing code (starts with review, no implementation)
max_iterations: 20
stances:
coding: ../stances/coding.md
review: ../stances/review.md
testing: ../stances/testing.md
policies:
coding: ../policies/coding.md
review: ../policies/review.md
testing: ../policies/testing.md
personas:
coder: ../personas/coder.md
ai-antipattern-reviewer: ../personas/ai-antipattern-reviewer.md
@ -18,15 +18,15 @@ instructions:
ai-fix: ../instructions/ai-fix.md
supervise: ../instructions/supervise.md
fix-supervisor: ../instructions/fix-supervisor.md
report_formats:
ai-review: ../report-formats/ai-review.md
output_contracts:
ai-review: ../output-contracts/ai-review.md
initial_movement: reviewers
movements:
- name: implement
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
report:
@ -57,7 +57,7 @@ movements:
- name: ai_review
edit: false
persona: ai-antipattern-reviewer
stance: review
policy: review
report:
name: 03-ai-review.md
format: ai-review
@ -74,7 +74,7 @@ movements:
- name: supervise
edit: false
persona: supervisor
stance: review
policy: review
report:
- Validation: 05-supervisor-validation.md
- Summary: summary.md
@ -104,7 +104,7 @@ movements:
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
allowed_tools:
@ -125,7 +125,7 @@ movements:
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
allowed_tools:
@ -150,7 +150,7 @@ movements:
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
allowed_tools:
@ -175,7 +175,7 @@ movements:
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
allowed_tools:

View File

@ -16,10 +16,11 @@ description: Review and fix piece for existing code (starts with review, no impl
max_iterations: 20
stances:
coding: ../stances/coding.md
review: ../stances/review.md
testing: ../stances/testing.md
policies:
coding: ../policies/coding.md
review: ../policies/review.md
testing: ../policies/testing.md
ai-antipattern: ../policies/ai-antipattern.md
personas:
coder: ../personas/coder.md
@ -33,8 +34,8 @@ instructions:
supervise: ../instructions/supervise.md
fix-supervisor: ../instructions/fix-supervisor.md
report_formats:
ai-review: ../report-formats/ai-review.md
output_contracts:
ai-review: ../output-contracts/ai-review.md
initial_movement: reviewers
@ -42,7 +43,7 @@ movements:
- name: implement
edit: true
persona: coder
stance:
policy:
- coding
- testing
report:
@ -74,7 +75,9 @@ movements:
- name: ai_review
edit: false
persona: ai-antipattern-reviewer
stance: review
policy:
- review
- ai-antipattern
report:
name: 03-ai-review.md
format: ai-review
@ -93,7 +96,7 @@ movements:
- name: supervise
edit: false
persona: supervisor
stance: review
policy: review
report:
- Validation: 05-supervisor-validation.md
- Summary: summary.md
@ -125,7 +128,7 @@ movements:
- name: ai_fix_parallel
edit: true
persona: coder
stance:
policy:
- coding
- testing
allowed_tools:
@ -147,7 +150,7 @@ movements:
- name: supervise_fix_parallel
edit: true
persona: coder
stance:
policy:
- coding
- testing
allowed_tools:
@ -174,7 +177,7 @@ movements:
- name: ai_fix
edit: true
persona: coder
stance:
policy:
- coding
- testing
allowed_tools:
@ -199,7 +202,7 @@ movements:
- name: supervise_fix
edit: true
persona: coder
stance:
policy:
- coding
- testing
allowed_tools:

View File

@ -24,8 +24,9 @@ description: Review-only piece - reviews code without making edits
max_iterations: 10
stances:
review: ../stances/review.md
policies:
review: ../policies/review.md
ai-antipattern: ../policies/ai-antipattern.md
knowledge:
architecture: ../knowledge/architecture.md
@ -44,11 +45,11 @@ instructions:
review-security: ../instructions/review-security.md
review-ai: ../instructions/review-ai.md
report_formats:
architecture-review: ../report-formats/architecture-review.md
security-review: ../report-formats/security-review.md
ai-review: ../report-formats/ai-review.md
review-summary: ../report-formats/review-summary.md
output_contracts:
architecture-review: ../output-contracts/architecture-review.md
security-review: ../output-contracts/security-review.md
ai-review: ../output-contracts/ai-review.md
review-summary: ../output-contracts/review-summary.md
initial_movement: plan
@ -93,7 +94,7 @@ movements:
- name: arch-review
edit: false
persona: architecture-reviewer
stance: review
policy: review
knowledge: architecture
report:
name: 01-architect-review.md
@ -113,7 +114,7 @@ movements:
- name: security-review
edit: false
persona: security-reviewer
stance: review
policy: review
knowledge: security
report:
name: 02-security-review.md
@ -133,7 +134,9 @@ movements:
- name: ai-review
edit: false
persona: ai-antipattern-reviewer
stance: review
policy:
- review
- ai-antipattern
report:
name: 03-ai-review.md
format: ai-review
@ -157,7 +160,7 @@ movements:
- name: supervise
edit: false
persona: supervisor
stance: review
policy: review
report:
- Review Summary: 04-review-summary.md
allowed_tools:
@ -190,7 +193,7 @@ movements:
- If local review only, route to COMPLETE (condition: "approved")
- If critical issues found, route to ABORT (condition: "rejected")
**Review Summary report format:**
**Review Summary output contract:**
```markdown
# Review Summary

View File

@ -0,0 +1,204 @@
# AI Antipattern Detection Criteria
## Assumption Verification
AI often makes assumptions. Verify them.
| Check | Question |
|-------|----------|
| Requirements | Does the implementation match what was actually requested? |
| Context | Does it follow the existing codebase conventions? |
| Domain | Are business rules correctly understood? |
| Edge Cases | Did the AI consider realistic edge cases? |
Red flags:
- Implementation appears to answer a different question
- Uses patterns not found elsewhere in the codebase
- Overly generic solution for a specific problem
## Plausible-but-Wrong Detection
AI generates code that looks correct but is wrong.
| Pattern | Example |
|---------|---------|
| Syntactically correct but semantically wrong | Validation that checks format but misses business rules |
| Hallucinated APIs | Calling methods that don't exist in the library version being used |
| Stale patterns | Using deprecated approaches from training data |
| Over-engineering | Adding unnecessary abstraction layers for the task |
| Under-engineering | Missing error handling for realistic scenarios |
| Forgotten wiring | Mechanism is implemented but not passed from entry points |
Verification approach:
1. Can this code actually compile/run?
2. Do the imported modules/functions exist?
3. Is the API used correctly for this library version?
4. If new parameters/fields were added, are they actually passed from callers?
- AI often implements correctly within individual files but forgets cross-file wiring
- Grep to check if `options.xxx ?? fallback` always uses the fallback
## Copy-Paste Pattern Detection
AI often repeats the same patterns, including mistakes.
| Check | Action |
|-------|--------|
| Repeated dangerous patterns | Same vulnerability in multiple places |
| Inconsistent implementation | Same logic implemented differently across files |
| Boilerplate explosion | Unnecessary repetition that could be abstracted |
## Context Fitness Assessment
Does the code fit this specific project?
| Aspect | Verification |
|--------|-------------|
| Naming conventions | Matches existing codebase style |
| Error handling style | Consistent with project patterns |
| Logging approach | Uses project's logging conventions |
| Test style | Matches existing test patterns |
Questions to ask:
- Would a developer familiar with this codebase write it this way?
- Does it feel like it belongs here?
- Are there unexplained deviations from project conventions?
## Scope Creep Detection
AI tends to over-deliver. Check for unnecessary additions.
| Check | Problem |
|-------|---------|
| Extra features | Functionality not requested |
| Premature abstraction | Interfaces/abstractions for single implementations |
| Over-configuration | Making things configurable that don't need to be |
| Gold-plating | "Nice-to-have" additions not asked for |
| Unnecessary legacy support | Adding mapping/normalization logic for old values without explicit instruction |
The best code is the minimum code that solves the problem.
Legacy support criteria:
- Unless explicitly instructed to "support legacy values" or "maintain backward compatibility", legacy support is unnecessary
- Do not add `.transform()` normalization, `LEGACY_*_MAP` mappings, or `@deprecated` type definitions
- Support only new values and keep it simple
## Dead Code Detection
AI adds new code but often forgets to remove code that is no longer needed.
| Pattern | Example |
|---------|---------|
| Unused functions/methods | Old implementations remaining after refactoring |
| Unused variables/constants | Definitions no longer needed after condition changes |
| Unreachable code | Processing remaining after early returns, always-true/false conditions |
| Logically unreachable defensive code | Branches that never execute due to caller constraints |
| Unused imports/dependencies | Import statements or package dependencies for removed features |
| Orphaned exports/public APIs | Re-exports or index registrations remaining after implementation is removed |
| Unused interfaces/type definitions | Old types remaining after implementation changes |
| Disabled code | Code left commented out |
Logical dead code detection:
AI tends to add "just in case" defensive code, but when considering caller constraints, it may be unreachable. Code that is syntactically reachable but logically unreachable due to call chain preconditions should be removed.
```typescript
// REJECT - callers are only from interactive menus that require TTY
// This function is never called from non-TTY environments
function showFullDiff(cwd: string, branch: string): void {
const usePager = process.stdin.isTTY === true;
// usePager is always true (callers assume TTY)
const pager = usePager ? 'less -R' : 'cat'; // else branch is unreachable
}
// OK - understands caller constraints and removes unnecessary branching
function showFullDiff(cwd: string, branch: string): void {
// Only called from interactive menus, so TTY is always present
spawnSync('git', ['diff', ...], { env: { GIT_PAGER: 'less -R' } });
}
```
Verification approach:
1. When finding defensive branches, grep to check all callers of the function
2. If all callers already satisfy the condition, the defense is unnecessary
3. Grep to confirm no references to changed/deleted code remain
4. Verify that public module (index files, etc.) export lists match actual implementations
5. Check that no old code remains corresponding to newly added code
## Fallback/Default Argument Overuse Detection
AI overuses fallbacks and default arguments to hide uncertainty.
| Pattern | Example | Verdict |
|---------|---------|---------|
| Fallback on required data | `user?.id ?? 'unknown'` | REJECT |
| Default argument overuse | `function f(x = 'default')` where all callers omit it | REJECT |
| Nullish coalescing with no input path | `options?.cwd ?? process.cwd()` with no way to pass from above | REJECT |
| try-catch returning empty | `catch { return ''; }` | REJECT |
| Multi-level fallback | `a ?? b ?? c ?? d` | REJECT |
| Silent ignore in conditionals | `if (!x) return;` silently skipping what should be an error | REJECT |
Verification approach:
1. Grep the diff for `??`, `||`, `= defaultValue`, `catch`
2. For each fallback/default argument:
- Is it required data? -> REJECT
- Do all callers omit it? -> REJECT
- Is there a path to pass the value from above? -> If not, REJECT
3. REJECT if any fallback/default argument exists without justification
## Unused Code Detection
AI tends to generate unnecessary code for "future extensibility", "symmetry", or "just in case". Code not currently called from anywhere should be removed.
| Verdict | Criteria |
|---------|----------|
| REJECT | Public functions/methods not called from anywhere currently |
| REJECT | Setters/getters created "for symmetry" but not used |
| REJECT | Interfaces or options prepared for future extension |
| REJECT | Exported but no usage found via grep |
| OK | Implicitly called by framework (lifecycle hooks, etc.) |
| OK | Intentionally exposed as public package API |
Verification approach:
1. Grep to confirm no references to changed/deleted code remain
2. Verify that public module (index files, etc.) export lists match actual implementations
3. Check that no old code remains corresponding to newly added code
## Unnecessary Backward Compatibility Code Detection
AI tends to leave unnecessary code "for backward compatibility". Don't miss this.
Code to remove:
| Pattern | Example | Verdict |
|---------|---------|---------|
| deprecated + no usage | `@deprecated` annotation with no one using it | Remove immediately |
| Both old and new APIs exist | Old function remains alongside new function | Remove old |
| Completed migration wrapper | Wrapper created for compatibility but migration is complete | Remove |
| Comment says "remove later" | `// TODO: remove after migration` left abandoned | Remove now |
| Excessive proxy/adapter usage | Complexity added solely for backward compatibility | Replace simply |
Code to keep:
| Pattern | Example | Verdict |
|---------|---------|---------|
| Externally published API | npm package exports | Consider carefully |
| Config file compatibility | Can read old format config | Maintain until major version |
| During data migration | In the middle of DB schema migration | Maintain until complete |
Decision criteria:
1. Are there usage sites? -> Verify with grep/search. Remove if none
2. Is it externally published? -> Can remove immediately if internal only
3. Is migration complete? -> Remove if complete
When AI says "for backward compatibility", be skeptical. Verify if it's truly necessary.
## Decision Traceability Review
Verify that the Coder's decision log is valid.
| Check | Question |
|-------|----------|
| Decision is documented | Are non-obvious choices explained? |
| Rationale is sound | Does the reasoning make sense? |
| Alternatives considered | Were other approaches evaluated? |
| Assumptions explicit | Are assumptions explicit and reasonable? |

View File

@ -1,4 +1,4 @@
# Coding Stance
# Coding Policy
Prioritize correctness over speed, and code accuracy over ease of implementation.

View File

@ -0,0 +1,28 @@
# QA Detection Criteria
## Error Handling and Logging
| Criteria | Verdict |
|----------|---------|
| Swallowed errors (empty catch) | REJECT |
| Unclear user-facing error messages | Fix required |
| Missing validation at system boundaries | Warning |
| No debug logging for new code paths | Warning |
| Sensitive information in logs | REJECT |
## Maintainability
| Criteria | Verdict |
|----------|---------|
| Functions/files too complex (hard to follow) | Warning |
| Excessive duplicate code | Warning |
| Unclear naming | Fix required |
## Technical Debt
| Pattern | Verdict |
|---------|---------|
| Abandoned TODO/FIXME | Warning |
| @ts-ignore, @ts-expect-error without reason | Warning |
| eslint-disable without reason | Warning |
| Usage of deprecated APIs | Warning |

View File

@ -1,4 +1,4 @@
# Review Stance
# Review Policy
Define the shared judgment criteria and behavioral principles for all reviewers.

View File

@ -1,4 +1,4 @@
# Testing Stance
# Testing Policy
Every behavior change requires a corresponding test, and every bug fix requires a regression test.

View File

@ -30,7 +30,7 @@ Report any unclear points or need for design changes.
- Test file placement: follow the project's conventions
- Running tests is mandatory. After implementation, always run tests and verify results
**Scope report format (create at implementation start):**
**Scope output contract (create at implementation start):**
```markdown
# Change Scope Declaration
@ -50,7 +50,7 @@ Small / Medium / Large
- {Affected modules or features}
```
**Decisions report format (at implementation end, only when decisions were made):**
**Decisions output contract (at implementation end, only when decisions were made):**
```markdown
# Decision Log

View File

@ -26,7 +26,7 @@ Reaching this movement means all of the following reviews have been APPROVED:
**Report verification:** Read all reports in the Report Directory and
check for any unaddressed improvement suggestions.
**Validation report format:**
**Validation output contract:**
```markdown
# Final Verification Results
@ -50,7 +50,7 @@ check for any unaddressed improvement suggestions.
| 1 | {item} | {reason} |
```
**Summary report format (APPROVE only):**
**Summary output contract (APPROVE only):**
```markdown
# Task Completion Summary

View File

@ -14,7 +14,7 @@ You are {Character Name} of {System Name}. {One sentence describing the characte
- {What this character does not do 2}
- {What this character does not do 3}
## Behavioral Stance
## Behavioral Principles
- {Speech pattern/tone characteristic 1}
- {Speech pattern/tone characteristic 2}

View File

@ -14,7 +14,7 @@ You are an expert in {domain}. {One sentence describing the role}.
- {Out-of-scope responsibility 2} ({responsible agent name} handles this)
- Write code yourself
## Behavioral Stance
## Behavioral Principles
- {Agent-specific behavioral guideline 1}
- {Agent-specific behavioral guideline 2}

View File

@ -14,7 +14,7 @@ You are an expert in {domain}. {One sentence describing the role}.
- {Out-of-scope responsibility 2} (delegate to {responsible agent name})
- {Out-of-scope responsibility 3}
## Behavioral Stance
## Behavioral Principles
- {Agent-specific behavioral guideline 1}
- {Agent-specific behavioral guideline 2}

View File

@ -1,4 +1,4 @@
# {Stance Name}
# {Policy Name}
{One-sentence purpose description.}

View File

@ -48,12 +48,12 @@
インストラクションの前に実行コンテキスト、ピース情報、ユーザーリクエスト、前回レスポンス等が既に提供されている。これらを再記述する必要はない。
### ペルソナ・スタンスとの分離
### ペルソナ・ポリシーとの分離
```
この内容は…
├── エージェントの identity・専門知識 → ペルソナ
├── 複数エージェントの共有ルール → スタンス
├── 複数エージェントの共有ルール → ポリシー
└── ムーブメント固有の手順・出力形式 → インストラクション
```
@ -102,7 +102,7 @@ InstructionBuilder が instruction_template 内の `{変数名}` を展開する
1. 目的の宣言1-2行
2. 注意事項・条件(該当する場合)
3. やること(手順 or 観点)
4. レポートフォーマット(埋め込みの場合)
4. 出力契約(埋め込みの場合)
5. 必須出力(見出しを含める)
```
@ -156,15 +156,15 @@ InstructionBuilder が instruction_template 内の `{変数名}` を展開する
- テストカバレッジ
```
### レポートフォーマット埋め込み
### 出力契約埋め込み
- インストラクション内にレポートフォーマットを埋め込む場合がある
- インストラクション内に出力契約を埋め込む場合がある
- コードブロック(```markdownで囲む
- ラベル(`**Scopeレポートフォーマット:**` 等)を付ける
- ラベル(`**Scope出力契約:**` 等)を付ける
```markdown
# 良い例
**Scopeレポートフォーマット(実装開始時に作成):**
**Scope出力契約(実装開始時に作成):**
\`\`\`markdown
# 変更スコープ宣言
...
@ -196,7 +196,7 @@ InstructionBuilder が instruction_template 内の `{変数名}` を展開する
| 目的を冒頭1-2行で命令形で書く | 長い説明文で始める |
| 手順を番号付きリストで列挙 | 曖昧な指示を出す |
| テンプレート変数を正しく使う | 自動注入される変数を手動で書く |
| レポートフォーマットは```markdownで囲む | プレーンテキストでフォーマットを書く |
| 出力契約は```markdownで囲む | プレーンテキストで出力契約を書く |
| 必須出力の見出しを `##` で指定 | 出力形式を指定しない |
| そのムーブメントの手順に集中 | ペルソナ(専門知識)の内容を混ぜる |
| `{report:filename}` でレポートを参照 | ファイルパスをハードコードする |
@ -206,7 +206,7 @@ InstructionBuilder が instruction_template 内の `{変数名}` を展開する
## インストラクションに書いてはいけないもの
1. **ペルソナの内容**: エージェントの専門知識、検出手法、行動姿勢
2. **スタンスの内容**: DRY、Fail Fast 等の共有コーディング原則
2. **ポリシーの内容**: DRY、Fail Fast 等の共有コーディング原則
3. **自動注入される内容**: `{task}`, `{previous_response}` のプレースホルダーを明示的に書かない(エンジンが自動付加する)
4. **他のムーブメント名の直接参照**: 「implement ムーブメントに戻る」等(ルーティングはルール定義の責務)
5. **ピース固有のルーティング**: 「APPROVE なら次へ」等(ルール条件の責務)
@ -232,13 +232,13 @@ InstructionBuilder が instruction_template 内の `{変数名}` を展開する
### 計画系plan, plan-investigate, architect
- 目的宣言 + やること(番号付き) + replan 注意事項
- レポートフォーマット埋め込みなし(レポートは report-formats/ に分離)
- 出力契約埋め込みなし(出力契約は output-contracts/ に分離)
- 5-20行
### 実装系implement
- 目的宣言 + テスト要件 + Scope/Decisions レポート埋め込み + 必須出力
- レポートフォーマットを2つ埋め込むScope + Decisions
- 目的宣言 + テスト要件 + Scope/Decisions 出力契約埋め込み + 必須出力
- 出力契約を2つ埋め込むScope + Decisions
- 30-50行
### レビュー系review-*, ai-review
@ -260,7 +260,7 @@ InstructionBuilder が instruction_template 内の `{変数名}` を展開する
### 検証系supervise
- 確認項目 + レポート確認指示 + Validation/Summary レポート埋め込み
- 確認項目 + レポート確認指示 + Validation/Summary 出力契約埋め込み
- 30-55行
---
@ -270,7 +270,7 @@ InstructionBuilder が instruction_template 内の `{変数名}` を展開する
### 文体
- 丁寧語(「〜してください。」)を使用
- ペルソナ・スタンスの常体とは異なる
- ペルソナ・ポリシーの常体とは異なる
- エージェントへの指示なので命令調
### ファイル命名
@ -298,8 +298,8 @@ InstructionBuilder が instruction_template 内の `{変数名}` を展開する
- [ ] 冒頭1-2行で目的が命令形で書かれているか
- [ ] 自動注入される変数({task}等)を手動で書いていないか
- [ ] ペルソナの内容(専門知識、行動姿勢)が混入していないか
- [ ] スタンスの内容(共有コーディング原則)が混入していないか
- [ ] レポートフォーマット埋め込みが```markdownで囲まれているか
- [ ] ポリシーの内容(共有コーディング原則)が混入していないか
- [ ] 出力契約埋め込みが```markdownで囲まれているか
- [ ] 必須出力の見出しが `##` で指定されているか
- [ ] ファイルパスがハードコードされていないか(`{report:filename}` を使う)
- [ ] そのムーブメントの手順に集中しているか(ルーティング指示なし)

View File

@ -1,6 +1,6 @@
# レポートフォーマット スタイルガイド
# 出力契約 スタイルガイド
このガイドは `report-formats/` のファイルを作成・編集する際のルールを定義する。
このガイドは `output-contracts/` のファイルを作成・編集する際のルールを定義する。
## テンプレート
@ -17,20 +17,20 @@
---
## レポートフォーマットとは
## 出力契約とは
エージェントが出力するレポートの構造定義。ピースYAMLの `report.format` フィールドで使用する。
| 項目 | 内容 |
|------|------|
| 目的 | エージェント出力の構造を統一し、後続ムーブメントで機械的に参照可能にする |
| 配置 | Phase 2 メッセージの `## Instructions` 内(`{{reportFormat}}` |
| 配置 | Phase 2 メッセージの `## Instructions` 内(`{{outputContract}}` |
| 対象 | 1つのレポートファイル |
| 判断基準 | 「この出力は後続ムーブメントが `{report:filename}` で参照するか?」→ YES |
### 実際の配置先
レポートフォーマットは `src/shared/prompts/{lang}/perform_phase2_message.md``{{reportFormat}}` に展開される。
出力契約は `src/shared/prompts/{lang}/perform_phase2_message.md``{{outputContract}}` に展開される。
```
## 実行コンテキスト(作業ディレクトリ)
@ -38,17 +38,17 @@
## Piece Context
## Instructions
"レポートとして回答してください。ツールは使えません。"
{{reportFormat}} ← ★ レポートフォーマットがここに展開される
{{outputContract}} ← ★ 出力契約がここに展開される
```
Phase 2 はツール使用不可。エージェントは Phase 1 のセッションを引き継いだ上で、テキスト出力のみでレポートを作成する。
### インストラクションとの違い
| | インストラクション | レポートフォーマット |
| | インストラクション | 出力契約 |
|--|-------------------|-------------------|
| 目的 | 何をすべきかの手順 | 出力の構造定義 |
| 配置 | Phase 1 `{{instructions}}` | Phase 2 `{{reportFormat}}` |
| 配置 | Phase 1 `{{instructions}}` | Phase 2 `{{outputContract}}` |
| 読者 | エージェント(実行時) | 後続ムーブメントのエージェント(参照時) |
| 形式 | 自由文 + 箇条書き | ```markdown コードブロック |
@ -58,14 +58,14 @@ Phase 2 はツール使用不可。エージェントは Phase 1 のセッショ
### 全体構造
レポートフォーマットは以下の構造を持つ。
出力契約は以下の構造を持つ。
```
1. ```markdown コードブロック(フォーマット本体)
2. 認知負荷軽減ルール(該当する場合)
```
### フォーマット本体
### 出力契約本体
必ず ` ```markdown ` コードブロックで囲む。
@ -142,7 +142,7 @@ Phase 2 はツール使用不可。エージェントは Phase 1 のセッショ
### 認知負荷軽減ルール
レビュー系レポートには認知負荷軽減ルールを付加する。フォーマット本体の ` ``` ` の後に記述する。
レビュー系レポートには認知負荷軽減ルールを付加する。出力契約本体の ` ``` ` の後に記述する。
```markdown
**認知負荷軽減ルール:**
@ -158,7 +158,7 @@ Phase 2 はツール使用不可。エージェントは Phase 1 のセッショ
| DO | DON'T |
|----|-------|
| ```markdown コードブロックで囲む | プレーンテキストでフォーマットを書く |
| ```markdown コードブロックで囲む | プレーンテキストで出力契約を書く |
| プレースホルダーは `{簡潔な説明}` | 冗長な説明をプレースホルダーに入れる |
| テーブルで構造化データを表現 | 箇条書きの入れ子で複雑な構造を表現 |
| 認知負荷軽減ルールで出力量を制御 | APPROVE でも REJECT と同量の出力を求める |
@ -167,7 +167,7 @@ Phase 2 はツール使用不可。エージェントは Phase 1 のセッショ
---
## レポートフォーマットに書いてはいけないもの
## 出力契約に書いてはいけないもの
1. **実行手順**: 「まず〜を確認し」等の手順はインストラクションの責務
2. **判断基準の詳細**: 「何をもって REJECT とするか」はペルソナまたはインストラクションの責務
@ -263,7 +263,7 @@ Phase 2 はツール使用不可。エージェントは Phase 1 のセッショ
## チェックリスト
- [ ] フォーマット本体が ```markdown コードブロックで囲まれているか
- [ ] 出力契約本体が ```markdown コードブロックで囲まれているか
- [ ] プレースホルダーが `{簡潔な説明}` 形式か
- [ ] レビュー系は結果ステータスAPPROVE / REJECT 等)が明示されているか
- [ ] テーブルの場所カラムが `` `file:line` `` 形式か

View File

@ -42,12 +42,12 @@
`# TAKT``# {エージェント名}` が同じ見出しレベルで並ぶ。`---` が境界。ペルソナの前に TAKT コンテキスト(ピース名、ムーブメント名、処理フロー全体)が既に提供されているため、ペルソナにこれらを再記述する必要はない。
### スタンスとの分離
### ポリシーとの分離
```
このルール/知識は…
├── 特定のエージェントだけが必要 → ペルソナ(ドメイン知識)
├── 複数のエージェントが共有 → スタンス
├── 複数のエージェントが共有 → ポリシー
└── 特定のピースの実行手順 → instruction_templateペルソナに書かない
```
@ -116,8 +116,8 @@
### 行動姿勢(必須)
- そのエージェント固有の行動指針・AI悪癖の自覚
- スタンスのルールと同じ概念を**1行の行動指針**として記載するのは適切(行動姿勢 = identity
- スタンスの**詳細ルール(コード例・判定基準・例外リスト)**をペルソナに記載するのは重複
- ポリシーのルールと同じ概念を**1行の行動指針**として記載するのは適切(行動姿勢 = identity
- ポリシーの**詳細ルール(コード例・判定基準・例外リスト)**をペルソナに記載するのは重複
- 箇条書き、3-8項目
```markdown
@ -128,7 +128,7 @@
- 後方互換・Legacy対応を勝手に追加する → 絶対禁止 ← 1行の行動指針はOK
# 悪い例
- フォールバック禁止パターン: ← スタンスの詳細ルールの転記
- フォールバック禁止パターン: ← ポリシーの詳細ルールの転記
| パターン | 例 | 問題 |
(テーブル・コード例が続く)
```
@ -148,25 +148,25 @@
| ロール定義は1-2文で簡潔に | 長い自己紹介を書く |
| 他エージェントの担当を「やらないこと」に明記 | 責務の境界を曖昧にする |
| ドメイン知識はテーブルとコード例で具体的に | 抽象的な原則だけ並べる |
| そのエージェント固有の知識のみ記載 | スタンスの詳細ルール(コード例・テーブル)を転記 |
| 行動姿勢に1行の行動指針としてスタンスと同じ概念を記載 | 汎用的なコーディングルールの詳細を混ぜる |
| そのエージェント固有の知識のみ記載 | ポリシーの詳細ルール(コード例・テーブル)を転記 |
| 行動姿勢に1行の行動指針としてポリシーと同じ概念を記載 | 汎用的なコーディングルールの詳細を混ぜる |
---
## ペルソナに書いてはいけないもの
1. **スタンスの詳細ルール**: コード例・判定基準・例外リスト等の詳細はスタンスの責務1行の行動指針は行動姿勢に記載してよい
1. **ポリシーの詳細ルール**: コード例・判定基準・例外リスト等の詳細はポリシーの責務1行の行動指針は行動姿勢に記載してよい
2. **ピース固有の概念**: ムーブメント名、レポートファイル名、ステップ間ルーティング
3. **ツール固有の環境情報**: `.takt/reports/` 等のディレクトリパス、テンプレート変数(`{report_dir}` 等)
4. **実行手順**: 「まず〜を読み、次に〜を実行」のような手順はinstruction_templateの責務
### 例外: ドメイン知識としての重複
スタンスと表面的に重複していても、**検出手法**として記載する場合は許容する。
ポリシーと表面的に重複していても、**検出手法**として記載する場合は許容する。
```markdown
# 許容 — AI Antipattern Reviewer のフォールバック検出手法
# コーディングスタンスは「フォールバック禁止」というルール
# コーディングポリシーは「フォールバック禁止」というルール
# このペルソナは「どうやってフォールバックを検出するか」という手法
### フォールバック・デフォルト引数の濫用検出
@ -176,7 +176,7 @@
2. 各フォールバックについて: 必須データか?全呼び出し元が省略しているか?
```
行動姿勢での1行記載「フォールバックで隠す → 禁止」)はペルソナの identity。詳細な判定基準・コード例はスタンスの責務。検出手法の記載「grepで見つけてこう検証する」はドメイン知識。
行動姿勢での1行記載「フォールバックで隠す → 禁止」)はペルソナの identity。詳細な判定基準・コード例はポリシーの責務。検出手法の記載「grepで見つけてこう検証する」はドメイン知識。
---
@ -221,7 +221,7 @@
- [ ] ロール定義が1-2文で書かれているか
- [ ] 「やること」「やらないこと」が明確に分かれているか
- [ ] 「やらないこと」に担当エージェント名が書かれているか
- [ ] 行動姿勢がスタンスの詳細ルールコード例・テーブル・例外リストを転記していないか1行の行動指針はOK
- [ ] 行動姿勢がポリシーの詳細ルールコード例・テーブル・例外リストを転記していないか1行の行動指針はOK
- [ ] ドメイン知識がそのエージェント固有のものか
- [ ] ピース固有の概念(ムーブメント名、レポートファイル名等)が含まれていないか
- [ ] ツール固有のパス(`.takt/` 等)が含まれていないか

View File

@ -1,18 +1,18 @@
# スタンス スタイルガイド
# ポリシー スタイルガイド
このガイドは `stances/` のファイルを作成・編集する際のルールを定義する。
このガイドは `policies/` のファイルを作成・編集する際のルールを定義する。
## テンプレート
`templates/stances/` にテンプレートファイルを用意している。新規作成時はコピーして使う。
`templates/policies/` にテンプレートファイルを用意している。新規作成時はコピーして使う。
| テンプレート | 用途 | 使用例 |
|------------|------|--------|
| `stance.md` | 共有行動規範 | coding, review, testing |
| `policy.md` | 共有行動規範 | coding, review, testing |
---
## スタンスとは
## ポリシーとは
複数のエージェントが共有する行動規範。user messageinstruction 内)に配置される。
@ -21,15 +21,15 @@
| 目的 | 複数エージェントが共有する行動規範 |
| 配置 | user messageinstruction 内) |
| 対象 | 複数のエージェント |
| 判断基準 | 「複数のエージェントが同じルールに従うか?」→ YES ならスタンス |
| 判断基準 | 「複数のエージェントが同じルールに従うか?」→ YES ならポリシー |
### ペルソナとの分離
```
このルール/知識は…
├── 特定のエージェントだけが必要 → ペルソナ(ドメイン知識)
├── 複数のエージェントが共有 → スタンス
└── 特定のピースの実行手順 → instruction_templateスタンスに書かない)
├── 複数のエージェントが共有 → ポリシー
└── 特定のピースの実行手順 → instruction_templateポリシーに書かない)
```
---
@ -37,7 +37,7 @@
## フォーマット
```markdown
# {スタンス名}
# {ポリシー名}
{1文の目的説明。「〜する。」で終わる}
@ -61,7 +61,7 @@
### 目的説明(必須)
- 1文でスタンスの目的を宣言
- 1文でポリシーの目的を宣言
- 体言止めまたは「〜する。」で終わる
```markdown
@ -74,7 +74,7 @@
### 原則テーブル(必須)
- スタンスの核心を5-10行のテーブルで表現
- ポリシーの核心を5-10行のテーブルで表現
- 各行は「原則名 + 1行の基準」
### ルールカテゴリ1つ以上
@ -96,7 +96,7 @@
---
## スタンスに書いてはいけないもの
## ポリシーに書いてはいけないもの
1. **特定エージェント固有の知識**: Architecture Reviewer だけが使う検出手法等
2. **ピース固有の概念**: ムーブメント名、レポートファイル名

View File

@ -5,9 +5,9 @@
| レイヤー | ガイド | 配置先 |
|---------|--------|--------|
| ペルソナ | [PERSONA_STYLE_GUIDE.md](PERSONA_STYLE_GUIDE.md) | system prompt`{{agentDefinition}}` |
| スタンス | [STANCE_STYLE_GUIDE.md](STANCE_STYLE_GUIDE.md) | user messageinstruction 内) |
| ポリシー | [POLICY_STYLE_GUIDE.md](POLICY_STYLE_GUIDE.md) | user messageinstruction 内) |
| インストラクション | [INSTRUCTION_STYLE_GUIDE.md](INSTRUCTION_STYLE_GUIDE.md) | Phase 1 メッセージ(`{{instructions}}` |
| レポートフォーマット | [REPORT_STYLE_GUIDE.md](REPORT_STYLE_GUIDE.md) | `report.format` |
| 出力契約 | [OUTPUT_CONTRACT_STYLE_GUIDE.md](OUTPUT_CONTRACT_STYLE_GUIDE.md) | `report.format` |
## テンプレート
@ -19,8 +19,8 @@ templates/
│ ├── simple.md # ドメイン知識なし
│ ├── expert.md # ドメイン知識あり
│ └── character.md # キャラクター型
├── stances/ # スタンステンプレート
│ └── stance.md
├── policies/ # ポリシーテンプレート
│ └── policy.md
├── instructions/ # インストラクションテンプレート
│ ├── plan.md
│ ├── architect.md
@ -31,7 +31,7 @@ templates/
│ ├── fix.md
│ ├── arbitrate.md
│ └── supervise.md
└── reports/ # レポートフォーマットテンプレート
└── reports/ # 出力契約テンプレート
├── plan.md
├── architecture-design.md
├── review.md
@ -53,7 +53,7 @@ User Message (Phase 1):
[User Request]
[Previous Response]
[Instructions] ← ムーブメント固有の手順
└── [スタンス] ← 共有行動規範instruction 内に含まれる)
└── [ポリシー] ← 共有行動規範instruction 内に含まれる)
```
## 分離の判断フロー
@ -61,7 +61,7 @@ User Message (Phase 1):
```
この内容は…
├── 特定のエージェントだけが必要 → ペルソナ
├── 複数のエージェントが共有 → スタンス
├── 複数のエージェントが共有 → ポリシー
├── ムーブメント固有の手順 → インストラクション
└── エージェント出力の構造定義 → レポートフォーマット
└── エージェント出力の構造定義 → 出力契約
```

View File

@ -7,7 +7,7 @@ Piece Contextに示されたReport Directory内のファイルのみ参照して
- テストファイルの配置: プロジェクトの規約に従う
- テスト実行は必須。実装完了後、必ずテストを実行して結果を確認
**Scopeレポートフォーマット(実装開始時に作成):**
**Scope出力契約(実装開始時に作成):**
```markdown
# 変更スコープ宣言
@ -27,7 +27,7 @@ Small / Medium / Large
- {影響するモジュールや機能}
```
**Decisionsレポートフォーマット(実装完了時、決定がある場合のみ):**
**Decisions出力契約(実装完了時、決定がある場合のみ):**
```markdown
# 決定ログ

View File

@ -8,7 +8,7 @@
**レポートの確認:** Report Directory内の全レポートを読み、
未対応の改善提案がないか確認してください。
**Validationレポートフォーマット:**
**Validation出力契約:**
```markdown
# 最終検証結果
@ -32,7 +32,7 @@
| 1 | {項目} | {理由} |
```
**SummaryレポートフォーマットAPPROVEの場合のみ:**
**Summary出力契約APPROVEの場合のみ:**
```markdown
# タスク完了サマリー

View File

@ -23,208 +23,3 @@
- AI生成コードは人間がレビューできる速度より速く生成される。品質ギャップを埋めるのがこの役割の存在意義
- AIは自信を持って間違える。もっともらしく見えるが動かないコード、技術的には正しいが文脈的に間違った解決策を見抜く
- 信頼するが検証する。AI生成コードはしばしばプロフェッショナルに見える。初期検査を通過する微妙な問題を捕捉する
## ドメイン知識
### 仮定の検証
AIはしばしば仮定を行う。それを検証する。
| 確認項目 | 質問 |
|---------|------|
| 要件 | 実装は実際に要求されたものと一致しているか? |
| コンテキスト | 既存のコードベースの規則に合っているか? |
| ドメイン | ビジネスルールは正しく理解されているか? |
| エッジケース | AIは現実的なエッジケースを考慮したか? |
危険信号:
- 実装が異なる質問に答えているように見える
- コードベースの他の場所にないパターンを使用
- 特定の問題に対して過度に汎用的な解決策
### もっともらしいが間違っている検出
AIは正しく見えるが間違っているコードを生成する。
| パターン | 例 |
|---------|-----|
| 構文は正しいが意味が間違っている | 形式をチェックするがビジネスルールを見落とすバリデーション |
| 幻覚API | 使用しているライブラリバージョンに存在しないメソッドの呼び出し |
| 古いパターン | 学習データからの非推奨アプローチの使用 |
| 過剰エンジニアリング | タスクに不要な抽象化レイヤーの追加 |
| 過小エンジニアリング | 現実的なシナリオのエラーハンドリングの欠如 |
| 配線忘れ | 機構は実装されているが、エントリポイントから渡されていない |
検証アプローチ:
1. このコードは実際にコンパイル/実行できるか?
2. インポートされたモジュール/関数は存在するか?
3. このライブラリバージョンでAPIは正しく使用されているか?
4. 新しいパラメータ/フィールドが追加された場合、呼び出し元から実際に渡されているか?
- AIは個々のファイル内では正しく実装するが、ファイル横断の結合を忘れがち
- `options.xxx ?? fallback` で常にフォールバックが使われていないか grep で確認
### コピペパターン検出
AIは同じパターンを、間違いも含めて繰り返すことが多い。
| 確認項目 | アクション |
|---------|----------|
| 繰り返される危険なパターン | 複数の場所で同じ脆弱性 |
| 一貫性のない実装 | ファイル間で異なる方法で実装された同じロジック |
| ボイラープレートの爆発 | 抽象化できる不要な繰り返し |
### コンテキスト適合性評価
コードはこの特定のプロジェクトに合っているか?
| 側面 | 検証 |
|------|------|
| 命名規則 | 既存のコードベースのスタイルに一致 |
| エラーハンドリングスタイル | プロジェクトのパターンと一貫性 |
| ログ出力アプローチ | プロジェクトのログ規則を使用 |
| テストスタイル | 既存のテストパターンに一致 |
確認すべき質問:
- このコードベースに精通した開発者ならこう書くか?
- ここに属しているように感じるか?
- プロジェクト規則からの説明のない逸脱はないか?
### スコープクリープ検出
AIは過剰に提供する傾向がある。不要な追加をチェック。
| 確認項目 | 問題 |
|---------|------|
| 追加機能 | 要求されていない機能 |
| 早すぎる抽象化 | 単一実装のためのインターフェース/抽象化 |
| 過剰設定 | 設定可能にする必要のないものを設定可能に |
| ゴールドプレーティング | 求められていない「あると良い」追加 |
| 不要なLegacy対応 | 明示的な指示がないのに旧値のマッピング・正規化ロジックを追加 |
最良のコードは、問題を解決する最小限のコード。
Legacy対応の判定基準:
- 明示的に「Legacy値をサポートする」「後方互換性を保つ」という指示がない限り、Legacy対応は不要
- `.transform()` による正規化、`LEGACY_*_MAP` のようなマッピング、`@deprecated` な型定義は追加しない
- 新しい値のみをサポートし、シンプルに保つ
### デッドコード検出
AIは新しいコードを追加するが、不要になったコードの削除を忘れることが多い。
| パターン | 例 |
|---------|-----|
| 未使用の関数・メソッド | リファクタリング後に残った旧実装 |
| 未使用の変数・定数 | 条件変更で不要になった定義 |
| 到達不能コード | 早期returnの後に残った処理、常に真/偽になる条件分岐 |
| 論理的に到達不能な防御コード | 呼び出し元の制約で絶対に通らない分岐 |
| 未使用のインポート・依存 | 削除された機能のimport文やパッケージ依存 |
| 孤立したエクスポート・公開API | 実体が消えたのにre-exportやindex登録が残っている |
| 未使用のインターフェース・型定義 | 実装側が変更されたのに残った古い型 |
| 無効化されたコード | コメントアウトされたまま放置されたコード |
論理的デッドコードの検出:
AIは「念のため」の防御コードを追加しがちだが、呼び出し元の制約を考慮すると到達不能な場合がある。構文的には到達可能でも、呼び出しチェーンの前提条件により論理的に到達しないコードは削除する。
```typescript
// REJECT - 呼び出し元がTTY必須のインタラクティブメニュー経由のみ
// TTYがない環境からこの関数が呼ばれることはない
function showFullDiff(cwd: string, branch: string): void {
const usePager = process.stdin.isTTY === true;
// usePager は常に true呼び出し元がTTYを前提としている
const pager = usePager ? 'less -R' : 'cat'; // else節は到達不能
}
// OK - 呼び出し元の制約を理解し、不要な分岐を排除
function showFullDiff(cwd: string, branch: string): void {
// インタラクティブメニューからのみ呼ばれるためTTYは常に存在する
spawnSync('git', ['diff', ...], { env: { GIT_PAGER: 'less -R' } });
}
```
検証アプローチ:
1. 防御的な分岐を見つけたら、grep でその関数の全呼び出し元を確認
2. 全呼び出し元が既にその条件を満たしている場合、防御は不要
3. 変更・削除されたコードを参照している箇所がないか grep で確認
4. 公開モジュールindex ファイル等)のエクスポート一覧と実体が一致しているか確認
5. 新規追加されたコードに対応する古いコードが残っていないか確認
### フォールバック・デフォルト引数の濫用検出
AIは不確実性を隠すためにフォールバックやデフォルト引数を多用する。
| パターン | 例 | 判定 |
|---------|-----|------|
| 必須データへのフォールバック | `user?.id ?? 'unknown'` | REJECT |
| デフォルト引数の濫用 | `function f(x = 'default')` で全呼び出し元が省略 | REJECT |
| null合体で渡す口がない | `options?.cwd ?? process.cwd()` で上位から渡す経路なし | REJECT |
| try-catch で空値返却 | `catch { return ''; }` | REJECT |
| 多段フォールバック | `a ?? b ?? c ?? d` | REJECT |
| 条件分岐でサイレント無視 | `if (!x) return;` で本来エラーをスキップ | REJECT |
検証アプローチ:
1. 変更差分で `??``||``= defaultValue``catch` を grep
2. 各フォールバック・デフォルト引数について:
- 必須データか? → REJECT
- 全呼び出し元が省略しているか? → REJECT
- 上位から値を渡す経路があるか? → なければ REJECT
3. 理由なしのフォールバック・デフォルト引数が1つでもあれば REJECT
### 未使用コードの検出
AIは「将来の拡張性」「対称性」「念のため」で不要なコードを生成しがちである。現時点で呼ばれていないコードは削除する。
| 判定 | 基準 |
|------|------|
| REJECT | 現在どこからも呼ばれていないpublic関数・メソッド |
| REJECT | 「対称性のため」に作られたが使われていないsetter/getter |
| REJECT | 将来の拡張のために用意されたインターフェースやオプション |
| REJECT | exportされているが、grep で使用箇所が見つからない |
| OK | フレームワークが暗黙的に呼び出す(ライフサイクルフック等) |
| OK | 公開パッケージのAPIとして意図的に公開している |
検証アプローチ:
1. 変更・削除されたコードを参照している箇所がないか grep で確認
2. 公開モジュールindex ファイル等)のエクスポート一覧と実体が一致しているか確認
3. 新規追加されたコードに対応する古いコードが残っていないか確認
### 不要な後方互換コードの検出
AIは「後方互換のために」不要なコードを残しがちである。これを見逃さない。
削除すべき後方互換コード:
| パターン | 例 | 判定 |
|---------|-----|------|
| deprecated + 使用箇所なし | `@deprecated` アノテーション付きで誰も使っていない | 即削除 |
| 新APIと旧API両方存在 | 新関数があるのに旧関数も残っている | 旧を削除 |
| 移行済みのラッパー | 互換のために作ったが移行完了済み | 削除 |
| コメントで「将来削除」 | `// TODO: remove after migration` が放置 | 今すぐ削除 |
| Proxy/アダプタの過剰使用 | 後方互換のためだけに複雑化 | シンプルに置換 |
残すべき後方互換コード:
| パターン | 例 | 判定 |
|---------|-----|------|
| 外部公開API | npm パッケージのエクスポート | 慎重に検討 |
| 設定ファイル互換 | 旧形式の設定を読める | メジャーバージョンまで維持 |
| データ移行中 | DBスキーマ移行の途中 | 移行完了まで維持 |
判断基準:
1. 使用箇所があるか? → grep/検索で確認。なければ削除
2. 外部に公開しているか? → 内部のみなら即削除可能
3. 移行は完了したか? → 完了なら削除
AIが「後方互換のため」と言ったら疑う。本当に必要か確認せよ。
### 決定トレーサビリティレビュー
Coderの決定ログが妥当か検証する。
| 確認項目 | 質問 |
|---------|------|
| 決定が文書化されている | 自明でない選択は説明されているか? |
| 理由が妥当 | 理由は理にかなっているか? |
| 代替案が検討されている | 他のアプローチは評価されたか? |
| 仮定が明示されている | 仮定は明示的で合理的か? |

View File

@ -23,32 +23,3 @@
- テストを最優先。テストがなければ、それが他の何よりも優先事項
- 完璧を求めない。80%カバレッジの良いテストは、100%を目指して何もないよりはるかに価値がある
- 既存の未テストコードはあなたの問題ではない。今回の変更に対するテストカバレッジのみをレビューする
## ドメイン知識
### エラーハンドリングとログ
| 基準 | 判定 |
|------|------|
| エラーの握りつぶし空のcatch | REJECT |
| ユーザー向けエラーメッセージが不明確 | 修正が必要 |
| システム境界でのバリデーション欠如 | 警告 |
| 新しいコードパスにデバッグログがない | 警告 |
| ログへの機密情報の出力 | REJECT |
### 保守性
| 基準 | 判定 |
|------|------|
| 関数/ファイルが複雑すぎる(追いにくい) | 警告 |
| 重複コードが多い | 警告 |
| 命名が不明確 | 修正が必要 |
### 技術的負債
| パターン | 判定 |
|---------|------|
| TODO/FIXMEの放置 | 警告 |
| 理由なしの @ts-ignore, @ts-expect-error | 警告 |
| 理由なしの eslint-disable | 警告 |
| 非推奨APIの使用 | 警告 |

View File

@ -4,12 +4,13 @@
name: coding-hybrid-codex
description: Lightweight development piece with planning and parallel reviews (plan -> implement -> parallel review -> complete)
max_iterations: 20
stances:
coding: ../stances/coding.md
review: ../stances/review.md
testing: ../stances/testing.md
policies:
coding: ../policies/coding.md
review: ../policies/review.md
testing: ../policies/testing.md
knowledge:
architecture: ../knowledge/architecture.md
ai-antipattern: ../knowledge/ai-antipattern.md
personas:
architect-planner: ../personas/architect-planner.md
coder: ../personas/coder.md
@ -21,10 +22,10 @@ instructions:
ai-review: ../instructions/ai-review.md
review-arch: ../instructions/review-arch.md
fix: ../instructions/fix.md
report_formats:
plan: ../report-formats/plan.md
ai-review: ../report-formats/ai-review.md
architecture-review: ../report-formats/architecture-review.md
output_contracts:
plan: ../output-contracts/plan.md
ai-review: ../output-contracts/ai-review.md
architecture-review: ../output-contracts/architecture-review.md
initial_movement: plan
movements:
- name: plan
@ -52,7 +53,7 @@ movements:
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
session: refresh
@ -87,7 +88,8 @@ movements:
- name: ai_review
edit: false
persona: ai-antipattern-reviewer
stance: review
policy: review
knowledge: ai-antipattern
report:
name: 04-ai-review.md
format: ai-review
@ -104,7 +106,7 @@ movements:
- name: arch-review
edit: false
persona: architecture-reviewer
stance: review
policy: review
knowledge: architecture
report:
name: 05-architect-review.md
@ -128,7 +130,7 @@ movements:
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
knowledge: architecture

View File

@ -32,10 +32,11 @@ description: Lightweight development piece with planning and parallel reviews (p
max_iterations: 20
stances:
coding: ../stances/coding.md
review: ../stances/review.md
testing: ../stances/testing.md
policies:
coding: ../policies/coding.md
review: ../policies/review.md
testing: ../policies/testing.md
ai-antipattern: ../policies/ai-antipattern.md
knowledge:
architecture: ../knowledge/architecture.md
@ -53,10 +54,10 @@ instructions:
review-arch: ../instructions/review-arch.md
fix: ../instructions/fix.md
report_formats:
plan: ../report-formats/plan.md
ai-review: ../report-formats/ai-review.md
architecture-review: ../report-formats/architecture-review.md
output_contracts:
plan: ../output-contracts/plan.md
ai-review: ../output-contracts/ai-review.md
architecture-review: ../output-contracts/architecture-review.md
initial_movement: plan
@ -86,7 +87,7 @@ movements:
- name: implement
edit: true
persona: coder
stance:
policy:
- coding
- testing
session: refresh
@ -122,7 +123,9 @@ movements:
- name: ai_review
edit: false
persona: ai-antipattern-reviewer
stance: review
policy:
- review
- ai-antipattern
report:
name: 04-ai-review.md
format: ai-review
@ -140,7 +143,7 @@ movements:
- name: arch-review
edit: false
persona: architecture-reviewer
stance: review
policy: review
knowledge: architecture
report:
name: 05-architect-review.md
@ -165,7 +168,7 @@ movements:
- name: fix
edit: true
persona: coder
stance:
policy:
- coding
- testing
knowledge: architecture

View File

@ -4,13 +4,15 @@
name: default-hybrid-codex
description: Standard development piece with planning and specialized reviews
max_iterations: 30
stances:
coding: ../stances/coding.md
review: ../stances/review.md
testing: ../stances/testing.md
policies:
coding: ../policies/coding.md
review: ../policies/review.md
testing: ../policies/testing.md
knowledge:
architecture: ../knowledge/architecture.md
backend: ../knowledge/backend.md
ai-antipattern: ../knowledge/ai-antipattern.md
qa: ../knowledge/qa.md
personas:
planner: ../personas/planner.md
architect-planner: ../personas/architect-planner.md
@ -30,14 +32,14 @@ instructions:
review-qa: ../instructions/review-qa.md
fix: ../instructions/fix.md
supervise: ../instructions/supervise.md
report_formats:
plan: ../report-formats/plan.md
architecture-design: ../report-formats/architecture-design.md
ai-review: ../report-formats/ai-review.md
architecture-review: ../report-formats/architecture-review.md
qa-review: ../report-formats/qa-review.md
validation: ../report-formats/validation.md
summary: ../report-formats/summary.md
output_contracts:
plan: ../output-contracts/plan.md
architecture-design: ../output-contracts/architecture-design.md
ai-review: ../output-contracts/ai-review.md
architecture-review: ../output-contracts/architecture-review.md
qa-review: ../output-contracts/qa-review.md
validation: ../output-contracts/validation.md
summary: ../output-contracts/summary.md
initial_movement: plan
loop_monitors:
- cycle:
@ -114,7 +116,7 @@ movements:
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
session: refresh
@ -149,7 +151,8 @@ movements:
- name: ai_review
edit: false
persona: ai-antipattern-reviewer
stance: review
policy: review
knowledge: ai-antipattern
report:
name: 04-ai-review.md
format: ai-review
@ -169,7 +172,7 @@ movements:
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
session: refresh
@ -197,7 +200,7 @@ movements:
- name: ai_no_fix
edit: false
persona: architecture-reviewer
stance: review
policy: review
allowed_tools:
- Read
- Glob
@ -213,7 +216,7 @@ movements:
- name: arch-review
edit: false
persona: architecture-reviewer
stance: review
policy: review
knowledge:
- architecture
- backend
@ -233,7 +236,8 @@ movements:
- name: qa-review
edit: false
persona: qa-reviewer
stance: review
policy: review
knowledge: qa
report:
name: 06-qa-review.md
format: qa-review
@ -256,7 +260,7 @@ movements:
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
knowledge:
@ -281,7 +285,7 @@ movements:
- name: supervise
edit: false
persona: supervisor
stance: review
policy: review
report:
- Validation: 07-supervisor-validation.md
- Summary: summary.md

View File

@ -15,10 +15,12 @@ description: Standard development piece with planning and specialized reviews
max_iterations: 30
stances:
coding: ../stances/coding.md
review: ../stances/review.md
testing: ../stances/testing.md
policies:
coding: ../policies/coding.md
review: ../policies/review.md
testing: ../policies/testing.md
ai-antipattern: ../policies/ai-antipattern.md
qa: ../policies/qa.md
knowledge:
architecture: ../knowledge/architecture.md
@ -45,14 +47,14 @@ instructions:
fix: ../instructions/fix.md
supervise: ../instructions/supervise.md
report_formats:
plan: ../report-formats/plan.md
architecture-design: ../report-formats/architecture-design.md
ai-review: ../report-formats/ai-review.md
architecture-review: ../report-formats/architecture-review.md
qa-review: ../report-formats/qa-review.md
validation: ../report-formats/validation.md
summary: ../report-formats/summary.md
output_contracts:
plan: ../output-contracts/plan.md
architecture-design: ../output-contracts/architecture-design.md
ai-review: ../output-contracts/ai-review.md
architecture-review: ../output-contracts/architecture-review.md
qa-review: ../output-contracts/qa-review.md
validation: ../output-contracts/validation.md
summary: ../output-contracts/summary.md
initial_movement: plan
@ -131,7 +133,7 @@ movements:
- name: implement
edit: true
persona: coder
stance:
policy:
- coding
- testing
session: refresh
@ -165,7 +167,9 @@ movements:
- name: ai_review
edit: false
persona: ai-antipattern-reviewer
stance: review
policy:
- review
- ai-antipattern
report:
name: 04-ai-review.md
format: ai-review
@ -185,7 +189,7 @@ movements:
- name: ai_fix
edit: true
persona: coder
stance:
policy:
- coding
- testing
session: refresh
@ -212,7 +216,7 @@ movements:
- name: ai_no_fix
edit: false
persona: architecture-reviewer
stance: review
policy: review
allowed_tools:
- Read
- Glob
@ -229,7 +233,7 @@ movements:
- name: arch-review
edit: false
persona: architecture-reviewer
stance: review
policy: review
knowledge: [architecture, backend]
report:
name: 05-architect-review.md
@ -248,7 +252,9 @@ movements:
- name: qa-review
edit: false
persona: qa-reviewer
stance: review
policy:
- review
- qa
report:
name: 06-qa-review.md
format: qa-review
@ -271,7 +277,7 @@ movements:
- name: fix
edit: true
persona: coder
stance:
policy:
- coding
- testing
knowledge: [backend, architecture]
@ -295,7 +301,7 @@ movements:
- name: supervise
edit: false
persona: supervisor
stance: review
policy: review
report:
- Validation: 07-supervisor-validation.md
- Summary: summary.md

View File

@ -4,16 +4,18 @@
name: expert-cqrs-hybrid-codex
description: CQRS+ES・フロントエンド・セキュリティ・QA専門家レビュー
max_iterations: 30
stances:
coding: ../stances/coding.md
review: ../stances/review.md
testing: ../stances/testing.md
policies:
coding: ../policies/coding.md
review: ../policies/review.md
testing: ../policies/testing.md
knowledge:
frontend: ../knowledge/frontend.md
backend: ../knowledge/backend.md
cqrs-es: ../knowledge/cqrs-es.md
security: ../knowledge/security.md
architecture: ../knowledge/architecture.md
ai-antipattern: ../knowledge/ai-antipattern.md
qa: ../knowledge/qa.md
personas:
planner: ../personas/planner.md
coder: ../personas/coder.md
@ -37,15 +39,15 @@ instructions:
fix: ../instructions/fix.md
supervise: ../instructions/supervise.md
fix-supervisor: ../instructions/fix-supervisor.md
report_formats:
plan: ../report-formats/plan.md
ai-review: ../report-formats/ai-review.md
cqrs-es-review: ../report-formats/cqrs-es-review.md
frontend-review: ../report-formats/frontend-review.md
security-review: ../report-formats/security-review.md
qa-review: ../report-formats/qa-review.md
validation: ../report-formats/validation.md
summary: ../report-formats/summary.md
output_contracts:
plan: ../output-contracts/plan.md
ai-review: ../output-contracts/ai-review.md
cqrs-es-review: ../output-contracts/cqrs-es-review.md
frontend-review: ../output-contracts/frontend-review.md
security-review: ../output-contracts/security-review.md
qa-review: ../output-contracts/qa-review.md
validation: ../output-contracts/validation.md
summary: ../output-contracts/summary.md
initial_movement: plan
movements:
- name: plan
@ -71,7 +73,7 @@ movements:
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
session: refresh
@ -108,7 +110,8 @@ movements:
- name: ai_review
edit: false
persona: ai-antipattern-reviewer
stance: review
policy: review
knowledge: ai-antipattern
report:
name: 03-ai-review.md
format: ai-review
@ -128,7 +131,7 @@ movements:
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
session: refresh
@ -158,7 +161,7 @@ movements:
- name: ai_no_fix
edit: false
persona: architecture-reviewer
stance: review
policy: review
allowed_tools:
- Read
- Glob
@ -174,7 +177,7 @@ movements:
- name: cqrs-es-review
edit: false
persona: cqrs-es-reviewer
stance: review
policy: review
knowledge:
- cqrs-es
- backend
@ -194,7 +197,7 @@ movements:
- name: frontend-review
edit: false
persona: frontend-reviewer
stance: review
policy: review
knowledge: frontend
report:
name: 05-frontend-review.md
@ -212,7 +215,7 @@ movements:
- name: security-review
edit: false
persona: security-reviewer
stance: review
policy: review
knowledge: security
report:
name: 06-security-review.md
@ -230,7 +233,8 @@ movements:
- name: qa-review
edit: false
persona: qa-reviewer
stance: review
policy: review
knowledge: qa
report:
name: 07-qa-review.md
format: qa-review
@ -253,7 +257,7 @@ movements:
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
knowledge:
@ -281,7 +285,7 @@ movements:
- name: supervise
edit: false
persona: expert-supervisor
stance: review
policy: review
report:
- Validation: 08-supervisor-validation.md
- Summary: summary.md
@ -301,7 +305,7 @@ movements:
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
knowledge:

View File

@ -32,10 +32,12 @@ description: CQRS+ES・フロントエンド・セキュリティ・QA専門家
max_iterations: 30
stances:
coding: ../stances/coding.md
review: ../stances/review.md
testing: ../stances/testing.md
policies:
coding: ../policies/coding.md
review: ../policies/review.md
testing: ../policies/testing.md
ai-antipattern: ../policies/ai-antipattern.md
qa: ../policies/qa.md
knowledge:
frontend: ../knowledge/frontend.md
@ -69,15 +71,15 @@ instructions:
supervise: ../instructions/supervise.md
fix-supervisor: ../instructions/fix-supervisor.md
report_formats:
plan: ../report-formats/plan.md
ai-review: ../report-formats/ai-review.md
cqrs-es-review: ../report-formats/cqrs-es-review.md
frontend-review: ../report-formats/frontend-review.md
security-review: ../report-formats/security-review.md
qa-review: ../report-formats/qa-review.md
validation: ../report-formats/validation.md
summary: ../report-formats/summary.md
output_contracts:
plan: ../output-contracts/plan.md
ai-review: ../output-contracts/ai-review.md
cqrs-es-review: ../output-contracts/cqrs-es-review.md
frontend-review: ../output-contracts/frontend-review.md
security-review: ../output-contracts/security-review.md
qa-review: ../output-contracts/qa-review.md
validation: ../output-contracts/validation.md
summary: ../output-contracts/summary.md
initial_movement: plan
@ -111,7 +113,7 @@ movements:
- name: implement
edit: true
persona: coder
stance:
policy:
- coding
- testing
session: refresh
@ -147,7 +149,9 @@ movements:
- name: ai_review
edit: false
persona: ai-antipattern-reviewer
stance: review
policy:
- review
- ai-antipattern
report:
name: 03-ai-review.md
format: ai-review
@ -167,7 +171,7 @@ movements:
- name: ai_fix
edit: true
persona: coder
stance:
policy:
- coding
- testing
session: refresh
@ -193,7 +197,7 @@ movements:
- name: ai_no_fix
edit: false
persona: architecture-reviewer
stance: review
policy: review
allowed_tools:
- Read
- Glob
@ -213,7 +217,7 @@ movements:
- name: cqrs-es-review
edit: false
persona: cqrs-es-reviewer
stance: review
policy: review
knowledge: [cqrs-es, backend]
report:
name: 04-cqrs-es-review.md
@ -233,7 +237,7 @@ movements:
- name: frontend-review
edit: false
persona: frontend-reviewer
stance: review
policy: review
knowledge: frontend
report:
name: 05-frontend-review.md
@ -253,7 +257,7 @@ movements:
- name: security-review
edit: false
persona: security-reviewer
stance: review
policy: review
knowledge: security
report:
name: 06-security-review.md
@ -273,7 +277,9 @@ movements:
- name: qa-review
edit: false
persona: qa-reviewer
stance: review
policy:
- review
- qa
report:
name: 07-qa-review.md
format: qa-review
@ -297,7 +303,7 @@ movements:
- name: fix
edit: true
persona: coder
stance:
policy:
- coding
- testing
knowledge: [frontend, backend, cqrs-es, security, architecture]
@ -324,7 +330,7 @@ movements:
- name: supervise
edit: false
persona: expert-supervisor
stance: review
policy: review
report:
- Validation: 08-supervisor-validation.md
- Summary: summary.md
@ -344,7 +350,7 @@ movements:
- name: fix_supervisor
edit: true
persona: coder
stance:
policy:
- coding
- testing
knowledge: [frontend, backend, cqrs-es, security, architecture]

View File

@ -4,15 +4,17 @@
name: expert-hybrid-codex
description: アーキテクチャ・フロントエンド・セキュリティ・QA専門家レビュー
max_iterations: 30
stances:
coding: ../stances/coding.md
review: ../stances/review.md
testing: ../stances/testing.md
policies:
coding: ../policies/coding.md
review: ../policies/review.md
testing: ../policies/testing.md
knowledge:
frontend: ../knowledge/frontend.md
backend: ../knowledge/backend.md
security: ../knowledge/security.md
architecture: ../knowledge/architecture.md
ai-antipattern: ../knowledge/ai-antipattern.md
qa: ../knowledge/qa.md
personas:
planner: ../personas/planner.md
coder: ../personas/coder.md
@ -35,15 +37,15 @@ instructions:
fix: ../instructions/fix.md
supervise: ../instructions/supervise.md
fix-supervisor: ../instructions/fix-supervisor.md
report_formats:
plan: ../report-formats/plan.md
ai-review: ../report-formats/ai-review.md
architecture-review: ../report-formats/architecture-review.md
frontend-review: ../report-formats/frontend-review.md
security-review: ../report-formats/security-review.md
qa-review: ../report-formats/qa-review.md
validation: ../report-formats/validation.md
summary: ../report-formats/summary.md
output_contracts:
plan: ../output-contracts/plan.md
ai-review: ../output-contracts/ai-review.md
architecture-review: ../output-contracts/architecture-review.md
frontend-review: ../output-contracts/frontend-review.md
security-review: ../output-contracts/security-review.md
qa-review: ../output-contracts/qa-review.md
validation: ../output-contracts/validation.md
summary: ../output-contracts/summary.md
initial_movement: plan
movements:
- name: plan
@ -69,7 +71,7 @@ movements:
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
session: refresh
@ -105,7 +107,8 @@ movements:
- name: ai_review
edit: false
persona: ai-antipattern-reviewer
stance: review
policy: review
knowledge: ai-antipattern
report:
name: 03-ai-review.md
format: ai-review
@ -125,7 +128,7 @@ movements:
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
session: refresh
@ -154,7 +157,7 @@ movements:
- name: ai_no_fix
edit: false
persona: architecture-reviewer
stance: review
policy: review
allowed_tools:
- Read
- Glob
@ -170,7 +173,7 @@ movements:
- name: arch-review
edit: false
persona: architecture-reviewer
stance: review
policy: review
knowledge:
- architecture
- backend
@ -190,7 +193,7 @@ movements:
- name: frontend-review
edit: false
persona: frontend-reviewer
stance: review
policy: review
knowledge: frontend
report:
name: 05-frontend-review.md
@ -208,7 +211,7 @@ movements:
- name: security-review
edit: false
persona: security-reviewer
stance: review
policy: review
knowledge: security
report:
name: 06-security-review.md
@ -226,7 +229,8 @@ movements:
- name: qa-review
edit: false
persona: qa-reviewer
stance: review
policy: review
knowledge: qa
report:
name: 07-qa-review.md
format: qa-review
@ -249,7 +253,7 @@ movements:
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
knowledge:
@ -276,7 +280,7 @@ movements:
- name: supervise
edit: false
persona: expert-supervisor
stance: review
policy: review
report:
- Validation: 08-supervisor-validation.md
- Summary: summary.md
@ -296,7 +300,7 @@ movements:
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
knowledge:

View File

@ -23,10 +23,12 @@ description: アーキテクチャ・フロントエンド・セキュリティ
max_iterations: 30
stances:
coding: ../stances/coding.md
review: ../stances/review.md
testing: ../stances/testing.md
policies:
coding: ../policies/coding.md
review: ../policies/review.md
testing: ../policies/testing.md
ai-antipattern: ../policies/ai-antipattern.md
qa: ../policies/qa.md
knowledge:
frontend: ../knowledge/frontend.md
@ -58,15 +60,15 @@ instructions:
supervise: ../instructions/supervise.md
fix-supervisor: ../instructions/fix-supervisor.md
report_formats:
plan: ../report-formats/plan.md
ai-review: ../report-formats/ai-review.md
architecture-review: ../report-formats/architecture-review.md
frontend-review: ../report-formats/frontend-review.md
security-review: ../report-formats/security-review.md
qa-review: ../report-formats/qa-review.md
validation: ../report-formats/validation.md
summary: ../report-formats/summary.md
output_contracts:
plan: ../output-contracts/plan.md
ai-review: ../output-contracts/ai-review.md
architecture-review: ../output-contracts/architecture-review.md
frontend-review: ../output-contracts/frontend-review.md
security-review: ../output-contracts/security-review.md
qa-review: ../output-contracts/qa-review.md
validation: ../output-contracts/validation.md
summary: ../output-contracts/summary.md
initial_movement: plan
@ -100,7 +102,7 @@ movements:
- name: implement
edit: true
persona: coder
stance:
policy:
- coding
- testing
session: refresh
@ -136,7 +138,9 @@ movements:
- name: ai_review
edit: false
persona: ai-antipattern-reviewer
stance: review
policy:
- review
- ai-antipattern
report:
name: 03-ai-review.md
format: ai-review
@ -156,7 +160,7 @@ movements:
- name: ai_fix
edit: true
persona: coder
stance:
policy:
- coding
- testing
session: refresh
@ -182,7 +186,7 @@ movements:
- name: ai_no_fix
edit: false
persona: architecture-reviewer
stance: review
policy: review
allowed_tools:
- Read
- Glob
@ -202,7 +206,7 @@ movements:
- name: arch-review
edit: false
persona: architecture-reviewer
stance: review
policy: review
knowledge: [architecture, backend]
report:
name: 04-architect-review.md
@ -222,7 +226,7 @@ movements:
- name: frontend-review
edit: false
persona: frontend-reviewer
stance: review
policy: review
knowledge: frontend
report:
name: 05-frontend-review.md
@ -242,7 +246,7 @@ movements:
- name: security-review
edit: false
persona: security-reviewer
stance: review
policy: review
knowledge: security
report:
name: 06-security-review.md
@ -262,7 +266,9 @@ movements:
- name: qa-review
edit: false
persona: qa-reviewer
stance: review
policy:
- review
- qa
report:
name: 07-qa-review.md
format: qa-review
@ -286,7 +292,7 @@ movements:
- name: fix
edit: true
persona: coder
stance:
policy:
- coding
- testing
knowledge: [frontend, backend, security, architecture]
@ -313,7 +319,7 @@ movements:
- name: supervise
edit: false
persona: expert-supervisor
stance: review
policy: review
report:
- Validation: 08-supervisor-validation.md
- Summary: summary.md
@ -333,7 +339,7 @@ movements:
- name: fix_supervisor
edit: true
persona: coder
stance:
policy:
- coding
- testing
knowledge: [frontend, backend, security, architecture]

View File

@ -4,10 +4,12 @@
name: minimal-hybrid-codex
description: Minimal development piece (implement -> parallel review -> fix if needed -> complete)
max_iterations: 20
stances:
coding: ../stances/coding.md
review: ../stances/review.md
testing: ../stances/testing.md
policies:
coding: ../policies/coding.md
review: ../policies/review.md
testing: ../policies/testing.md
knowledge:
ai-antipattern: ../knowledge/ai-antipattern.md
personas:
coder: ../personas/coder.md
ai-antipattern-reviewer: ../personas/ai-antipattern-reviewer.md
@ -18,15 +20,15 @@ instructions:
ai-fix: ../instructions/ai-fix.md
supervise: ../instructions/supervise.md
fix-supervisor: ../instructions/fix-supervisor.md
report_formats:
ai-review: ../report-formats/ai-review.md
output_contracts:
ai-review: ../output-contracts/ai-review.md
initial_movement: implement
movements:
- name: implement
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
report:
@ -57,7 +59,8 @@ movements:
- name: ai_review
edit: false
persona: ai-antipattern-reviewer
stance: review
policy: review
knowledge: ai-antipattern
report:
name: 03-ai-review.md
format: ai-review
@ -74,7 +77,7 @@ movements:
- name: supervise
edit: false
persona: supervisor
stance: review
policy: review
report:
- Validation: 05-supervisor-validation.md
- Summary: summary.md
@ -104,7 +107,7 @@ movements:
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
allowed_tools:
@ -125,7 +128,7 @@ movements:
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
allowed_tools:
@ -150,7 +153,7 @@ movements:
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
allowed_tools:
@ -175,7 +178,7 @@ movements:
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
allowed_tools:

View File

@ -16,10 +16,11 @@ description: Minimal development piece (implement -> parallel review -> fix if n
max_iterations: 20
stances:
coding: ../stances/coding.md
review: ../stances/review.md
testing: ../stances/testing.md
policies:
coding: ../policies/coding.md
review: ../policies/review.md
testing: ../policies/testing.md
ai-antipattern: ../policies/ai-antipattern.md
personas:
coder: ../personas/coder.md
@ -33,8 +34,8 @@ instructions:
supervise: ../instructions/supervise.md
fix-supervisor: ../instructions/fix-supervisor.md
report_formats:
ai-review: ../report-formats/ai-review.md
output_contracts:
ai-review: ../output-contracts/ai-review.md
initial_movement: implement
@ -42,7 +43,7 @@ movements:
- name: implement
edit: true
persona: coder
stance:
policy:
- coding
- testing
report:
@ -74,7 +75,9 @@ movements:
- name: ai_review
edit: false
persona: ai-antipattern-reviewer
stance: review
policy:
- review
- ai-antipattern
report:
name: 03-ai-review.md
format: ai-review
@ -93,7 +96,7 @@ movements:
- name: supervise
edit: false
persona: supervisor
stance: review
policy: review
report:
- Validation: 05-supervisor-validation.md
- Summary: summary.md
@ -125,7 +128,7 @@ movements:
- name: ai_fix_parallel
edit: true
persona: coder
stance:
policy:
- coding
- testing
allowed_tools:
@ -147,7 +150,7 @@ movements:
- name: supervise_fix_parallel
edit: true
persona: coder
stance:
policy:
- coding
- testing
allowed_tools:
@ -174,7 +177,7 @@ movements:
- name: ai_fix
edit: true
persona: coder
stance:
policy:
- coding
- testing
allowed_tools:
@ -199,7 +202,7 @@ movements:
- name: supervise_fix
edit: true
persona: coder
stance:
policy:
- coding
- testing
allowed_tools:

View File

@ -4,9 +4,9 @@
name: passthrough-hybrid-codex
description: Single-agent thin wrapper. Pass task directly to coder as-is.
max_iterations: 10
stances:
coding: ../stances/coding.md
testing: ../stances/testing.md
policies:
coding: ../policies/coding.md
testing: ../policies/testing.md
personas:
coder: ../personas/coder.md
initial_movement: execute
@ -15,7 +15,7 @@ movements:
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
report:

View File

@ -11,9 +11,9 @@ description: Single-agent thin wrapper. Pass task directly to coder as-is.
max_iterations: 10
stances:
coding: ../stances/coding.md
testing: ../stances/testing.md
policies:
coding: ../policies/coding.md
testing: ../policies/testing.md
personas:
coder: ../personas/coder.md
@ -24,7 +24,7 @@ movements:
- name: execute
edit: true
persona: coder
stance:
policy:
- coding
- testing
report:

View File

@ -4,10 +4,12 @@
name: review-fix-minimal-hybrid-codex
description: 既存コードのレビューと修正ピース(レビュー開始、実装なし)
max_iterations: 20
stances:
coding: ../stances/coding.md
review: ../stances/review.md
testing: ../stances/testing.md
policies:
coding: ../policies/coding.md
review: ../policies/review.md
testing: ../policies/testing.md
knowledge:
ai-antipattern: ../knowledge/ai-antipattern.md
personas:
coder: ../personas/coder.md
ai-antipattern-reviewer: ../personas/ai-antipattern-reviewer.md
@ -18,15 +20,15 @@ instructions:
ai-fix: ../instructions/ai-fix.md
supervise: ../instructions/supervise.md
fix-supervisor: ../instructions/fix-supervisor.md
report_formats:
ai-review: ../report-formats/ai-review.md
output_contracts:
ai-review: ../output-contracts/ai-review.md
initial_movement: reviewers
movements:
- name: implement
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
report:
@ -57,7 +59,8 @@ movements:
- name: ai_review
edit: false
persona: ai-antipattern-reviewer
stance: review
policy: review
knowledge: ai-antipattern
report:
name: 03-ai-review.md
format: ai-review
@ -74,7 +77,7 @@ movements:
- name: supervise
edit: false
persona: supervisor
stance: review
policy: review
report:
- Validation: 05-supervisor-validation.md
- Summary: summary.md
@ -104,7 +107,7 @@ movements:
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
allowed_tools:
@ -125,7 +128,7 @@ movements:
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
allowed_tools:
@ -150,7 +153,7 @@ movements:
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
allowed_tools:
@ -175,7 +178,7 @@ movements:
edit: true
persona: coder
provider: codex
stance:
policy:
- coding
- testing
allowed_tools:

View File

@ -16,10 +16,11 @@ description: 既存コードのレビューと修正ピース(レビュー開
max_iterations: 20
stances:
coding: ../stances/coding.md
review: ../stances/review.md
testing: ../stances/testing.md
policies:
coding: ../policies/coding.md
review: ../policies/review.md
testing: ../policies/testing.md
ai-antipattern: ../policies/ai-antipattern.md
personas:
coder: ../personas/coder.md
@ -33,8 +34,8 @@ instructions:
supervise: ../instructions/supervise.md
fix-supervisor: ../instructions/fix-supervisor.md
report_formats:
ai-review: ../report-formats/ai-review.md
output_contracts:
ai-review: ../output-contracts/ai-review.md
initial_movement: reviewers
@ -42,7 +43,7 @@ movements:
- name: implement
edit: true
persona: coder
stance:
policy:
- coding
- testing
report:
@ -74,7 +75,9 @@ movements:
- name: ai_review
edit: false
persona: ai-antipattern-reviewer
stance: review
policy:
- review
- ai-antipattern
report:
name: 03-ai-review.md
format: ai-review
@ -93,7 +96,7 @@ movements:
- name: supervise
edit: false
persona: supervisor
stance: review
policy: review
report:
- Validation: 05-supervisor-validation.md
- Summary: summary.md
@ -125,7 +128,7 @@ movements:
- name: ai_fix_parallel
edit: true
persona: coder
stance:
policy:
- coding
- testing
allowed_tools:
@ -147,7 +150,7 @@ movements:
- name: supervise_fix_parallel
edit: true
persona: coder
stance:
policy:
- coding
- testing
allowed_tools:
@ -174,7 +177,7 @@ movements:
- name: ai_fix
edit: true
persona: coder
stance:
policy:
- coding
- testing
allowed_tools:
@ -199,7 +202,7 @@ movements:
- name: supervise_fix
edit: true
persona: coder
stance:
policy:
- coding
- testing
allowed_tools:

View File

@ -24,8 +24,9 @@ description: レビュー専用ピース - コードをレビューするだけ
max_iterations: 10
stances:
review: ../stances/review.md
policies:
review: ../policies/review.md
ai-antipattern: ../policies/ai-antipattern.md
knowledge:
architecture: ../knowledge/architecture.md
@ -44,11 +45,11 @@ instructions:
review-security: ../instructions/review-security.md
review-ai: ../instructions/review-ai.md
report_formats:
architecture-review: ../report-formats/architecture-review.md
security-review: ../report-formats/security-review.md
ai-review: ../report-formats/ai-review.md
review-summary: ../report-formats/review-summary.md
output_contracts:
architecture-review: ../output-contracts/architecture-review.md
security-review: ../output-contracts/security-review.md
ai-review: ../output-contracts/ai-review.md
review-summary: ../output-contracts/review-summary.md
initial_movement: plan
@ -93,7 +94,7 @@ movements:
- name: arch-review
edit: false
persona: architecture-reviewer
stance: review
policy: review
knowledge: architecture
report:
name: 01-architect-review.md
@ -113,7 +114,7 @@ movements:
- name: security-review
edit: false
persona: security-reviewer
stance: review
policy: review
knowledge: security
report:
name: 02-security-review.md
@ -133,7 +134,9 @@ movements:
- name: ai-review
edit: false
persona: ai-antipattern-reviewer
stance: review
policy:
- review
- ai-antipattern
report:
name: 03-ai-review.md
format: ai-review
@ -157,7 +160,7 @@ movements:
- name: supervise
edit: false
persona: supervisor
stance: review
policy: review
report:
- Review Summary: 04-review-summary.md
allowed_tools:
@ -191,7 +194,7 @@ movements:
- ローカルレビューのみ → COMPLETEcondition: "approved"
- 重大な問題が見つかった場合 → ABORTcondition: "rejected"
**Review Summaryレポートフォーマット:**
**Review Summary出力契約:**
```markdown
# レビューサマリー

View File

@ -0,0 +1,204 @@
# AI Antipattern 検出基準
## 仮定の検証
AIはしばしば仮定を行う。それを検証する。
| 確認項目 | 質問 |
|---------|------|
| 要件 | 実装は実際に要求されたものと一致しているか? |
| コンテキスト | 既存のコードベースの規則に合っているか? |
| ドメイン | ビジネスルールは正しく理解されているか? |
| エッジケース | AIは現実的なエッジケースを考慮したか? |
危険信号:
- 実装が異なる質問に答えているように見える
- コードベースの他の場所にないパターンを使用
- 特定の問題に対して過度に汎用的な解決策
## もっともらしいが間違っている検出
AIは正しく見えるが間違っているコードを生成する。
| パターン | 例 |
|---------|-----|
| 構文は正しいが意味が間違っている | 形式をチェックするがビジネスルールを見落とすバリデーション |
| 幻覚API | 使用しているライブラリバージョンに存在しないメソッドの呼び出し |
| 古いパターン | 学習データからの非推奨アプローチの使用 |
| 過剰エンジニアリング | タスクに不要な抽象化レイヤーの追加 |
| 過小エンジニアリング | 現実的なシナリオのエラーハンドリングの欠如 |
| 配線忘れ | 機構は実装されているが、エントリポイントから渡されていない |
検証アプローチ:
1. このコードは実際にコンパイル/実行できるか?
2. インポートされたモジュール/関数は存在するか?
3. このライブラリバージョンでAPIは正しく使用されているか?
4. 新しいパラメータ/フィールドが追加された場合、呼び出し元から実際に渡されているか?
- AIは個々のファイル内では正しく実装するが、ファイル横断の結合を忘れがち
- `options.xxx ?? fallback` で常にフォールバックが使われていないか grep で確認
## コピペパターン検出
AIは同じパターンを、間違いも含めて繰り返すことが多い。
| 確認項目 | アクション |
|---------|----------|
| 繰り返される危険なパターン | 複数の場所で同じ脆弱性 |
| 一貫性のない実装 | ファイル間で異なる方法で実装された同じロジック |
| ボイラープレートの爆発 | 抽象化できる不要な繰り返し |
## コンテキスト適合性評価
コードはこの特定のプロジェクトに合っているか?
| 側面 | 検証 |
|------|------|
| 命名規則 | 既存のコードベースのスタイルに一致 |
| エラーハンドリングスタイル | プロジェクトのパターンと一貫性 |
| ログ出力アプローチ | プロジェクトのログ規則を使用 |
| テストスタイル | 既存のテストパターンに一致 |
確認すべき質問:
- このコードベースに精通した開発者ならこう書くか?
- ここに属しているように感じるか?
- プロジェクト規則からの説明のない逸脱はないか?
## スコープクリープ検出
AIは過剰に提供する傾向がある。不要な追加をチェック。
| 確認項目 | 問題 |
|---------|------|
| 追加機能 | 要求されていない機能 |
| 早すぎる抽象化 | 単一実装のためのインターフェース/抽象化 |
| 過剰設定 | 設定可能にする必要のないものを設定可能に |
| ゴールドプレーティング | 求められていない「あると良い」追加 |
| 不要なLegacy対応 | 明示的な指示がないのに旧値のマッピング・正規化ロジックを追加 |
最良のコードは、問題を解決する最小限のコード。
Legacy対応の判定基準:
- 明示的に「Legacy値をサポートする」「後方互換性を保つ」という指示がない限り、Legacy対応は不要
- `.transform()` による正規化、`LEGACY_*_MAP` のようなマッピング、`@deprecated` な型定義は追加しない
- 新しい値のみをサポートし、シンプルに保つ
## デッドコード検出
AIは新しいコードを追加するが、不要になったコードの削除を忘れることが多い。
| パターン | 例 |
|---------|-----|
| 未使用の関数・メソッド | リファクタリング後に残った旧実装 |
| 未使用の変数・定数 | 条件変更で不要になった定義 |
| 到達不能コード | 早期returnの後に残った処理、常に真/偽になる条件分岐 |
| 論理的に到達不能な防御コード | 呼び出し元の制約で絶対に通らない分岐 |
| 未使用のインポート・依存 | 削除された機能のimport文やパッケージ依存 |
| 孤立したエクスポート・公開API | 実体が消えたのにre-exportやindex登録が残っている |
| 未使用のインターフェース・型定義 | 実装側が変更されたのに残った古い型 |
| 無効化されたコード | コメントアウトされたまま放置されたコード |
論理的デッドコードの検出:
AIは「念のため」の防御コードを追加しがちだが、呼び出し元の制約を考慮すると到達不能な場合がある。構文的には到達可能でも、呼び出しチェーンの前提条件により論理的に到達しないコードは削除する。
```typescript
// REJECT - 呼び出し元がTTY必須のインタラクティブメニュー経由のみ
// TTYがない環境からこの関数が呼ばれることはない
function showFullDiff(cwd: string, branch: string): void {
const usePager = process.stdin.isTTY === true;
// usePager は常に true呼び出し元がTTYを前提としている
const pager = usePager ? 'less -R' : 'cat'; // else節は到達不能
}
// OK - 呼び出し元の制約を理解し、不要な分岐を排除
function showFullDiff(cwd: string, branch: string): void {
// インタラクティブメニューからのみ呼ばれるためTTYは常に存在する
spawnSync('git', ['diff', ...], { env: { GIT_PAGER: 'less -R' } });
}
```
検証アプローチ:
1. 防御的な分岐を見つけたら、grep でその関数の全呼び出し元を確認
2. 全呼び出し元が既にその条件を満たしている場合、防御は不要
3. 変更・削除されたコードを参照している箇所がないか grep で確認
4. 公開モジュールindex ファイル等)のエクスポート一覧と実体が一致しているか確認
5. 新規追加されたコードに対応する古いコードが残っていないか確認
## フォールバック・デフォルト引数の濫用検出
AIは不確実性を隠すためにフォールバックやデフォルト引数を多用する。
| パターン | 例 | 判定 |
|---------|-----|------|
| 必須データへのフォールバック | `user?.id ?? 'unknown'` | REJECT |
| デフォルト引数の濫用 | `function f(x = 'default')` で全呼び出し元が省略 | REJECT |
| null合体で渡す口がない | `options?.cwd ?? process.cwd()` で上位から渡す経路なし | REJECT |
| try-catch で空値返却 | `catch { return ''; }` | REJECT |
| 多段フォールバック | `a ?? b ?? c ?? d` | REJECT |
| 条件分岐でサイレント無視 | `if (!x) return;` で本来エラーをスキップ | REJECT |
検証アプローチ:
1. 変更差分で `??``||``= defaultValue``catch` を grep
2. 各フォールバック・デフォルト引数について:
- 必須データか? → REJECT
- 全呼び出し元が省略しているか? → REJECT
- 上位から値を渡す経路があるか? → なければ REJECT
3. 理由なしのフォールバック・デフォルト引数が1つでもあれば REJECT
## 未使用コードの検出
AIは「将来の拡張性」「対称性」「念のため」で不要なコードを生成しがちである。現時点で呼ばれていないコードは削除する。
| 判定 | 基準 |
|------|------|
| REJECT | 現在どこからも呼ばれていないpublic関数・メソッド |
| REJECT | 「対称性のため」に作られたが使われていないsetter/getter |
| REJECT | 将来の拡張のために用意されたインターフェースやオプション |
| REJECT | exportされているが、grep で使用箇所が見つからない |
| OK | フレームワークが暗黙的に呼び出す(ライフサイクルフック等) |
| OK | 公開パッケージのAPIとして意図的に公開している |
検証アプローチ:
1. 変更・削除されたコードを参照している箇所がないか grep で確認
2. 公開モジュールindex ファイル等)のエクスポート一覧と実体が一致しているか確認
3. 新規追加されたコードに対応する古いコードが残っていないか確認
## 不要な後方互換コードの検出
AIは「後方互換のために」不要なコードを残しがちである。これを見逃さない。
削除すべき後方互換コード:
| パターン | 例 | 判定 |
|---------|-----|------|
| deprecated + 使用箇所なし | `@deprecated` アノテーション付きで誰も使っていない | 即削除 |
| 新APIと旧API両方存在 | 新関数があるのに旧関数も残っている | 旧を削除 |
| 移行済みのラッパー | 互換のために作ったが移行完了済み | 削除 |
| コメントで「将来削除」 | `// TODO: remove after migration` が放置 | 今すぐ削除 |
| Proxy/アダプタの過剰使用 | 後方互換のためだけに複雑化 | シンプルに置換 |
残すべき後方互換コード:
| パターン | 例 | 判定 |
|---------|-----|------|
| 外部公開API | npm パッケージのエクスポート | 慎重に検討 |
| 設定ファイル互換 | 旧形式の設定を読める | メジャーバージョンまで維持 |
| データ移行中 | DBスキーマ移行の途中 | 移行完了まで維持 |
判断基準:
1. 使用箇所があるか? → grep/検索で確認。なければ削除
2. 外部に公開しているか? → 内部のみなら即削除可能
3. 移行は完了したか? → 完了なら削除
AIが「後方互換のため」と言ったら疑う。本当に必要か確認せよ。
## 決定トレーサビリティレビュー
Coderの決定ログが妥当か検証する。
| 確認項目 | 質問 |
|---------|------|
| 決定が文書化されている | 自明でない選択は説明されているか? |
| 理由が妥当 | 理由は理にかなっているか? |
| 代替案が検討されている | 他のアプローチは評価されたか? |
| 仮定が明示されている | 仮定は明示的で合理的か? |

View File

@ -1,4 +1,4 @@
# コーディングスタンス
# コーディングポリシー
速さより丁寧さ、実装の楽さよりコードの正確さを優先する。

View File

@ -0,0 +1,28 @@
# QA 検出基準
## エラーハンドリングとログ
| 基準 | 判定 |
|------|------|
| エラーの握りつぶし空のcatch | REJECT |
| ユーザー向けエラーメッセージが不明確 | 修正が必要 |
| システム境界でのバリデーション欠如 | 警告 |
| 新しいコードパスにデバッグログがない | 警告 |
| ログへの機密情報の出力 | REJECT |
## 保守性
| 基準 | 判定 |
|------|------|
| 関数/ファイルが複雑すぎる(追いにくい) | 警告 |
| 重複コードが多い | 警告 |
| 命名が不明確 | 修正が必要 |
## 技術的負債
| パターン | 判定 |
|---------|------|
| TODO/FIXMEの放置 | 警告 |
| 理由なしの @ts-ignore, @ts-expect-error | 警告 |
| 理由なしの eslint-disable | 警告 |
| 非推奨APIの使用 | 警告 |

View File

@ -1,4 +1,4 @@
# レビュースタンス
# レビューポリシー
全レビュアーが共有する判断基準と行動原則を定義する。

View File

@ -1,4 +1,4 @@
# テストスタンス
# テストポリシー
全ての振る舞いの変更には対応するテストが必要であり、全てのバグ修正にはリグレッションテストが必要。

View File

@ -30,7 +30,7 @@ Piece Contextに示されたReport Directory内のファイルのみ参照して
- テストファイルの配置: プロジェクトの規約に従う
- テスト実行は必須。実装完了後、必ずテストを実行して結果を確認
**Scopeレポートフォーマット(実装開始時に作成):**
**Scope出力契約(実装開始時に作成):**
```markdown
# 変更スコープ宣言
@ -50,7 +50,7 @@ Small / Medium / Large
- {影響するモジュールや機能}
```
**Decisionsレポートフォーマット(実装完了時、決定がある場合のみ):**
**Decisions出力契約(実装完了時、決定がある場合のみ):**
```markdown
# 決定ログ

View File

@ -26,7 +26,7 @@
**レポートの確認:** Report Directory内の全レポートを読み、
未対応の改善提案がないか確認してください。
**Validationレポートフォーマット:**
**Validation出力契約:**
```markdown
# 最終検証結果
@ -50,7 +50,7 @@
| 1 | {項目} | {理由} |
```
**SummaryレポートフォーマットAPPROVEの場合のみ:**
**Summary出力契約APPROVEの場合のみ:**
```markdown
# タスク完了サマリー

View File

@ -1,4 +1,4 @@
# {スタンス名}
# {ポリシー名}
{1文の目的説明。体言止めまたは「〜する。」}

View File

@ -84,11 +84,11 @@ $ARGUMENTS を以下のように解析する:
YAMLから以下を抽出する→ references/yaml-schema.md 参照):
- `name`, `max_iterations`, `initial_movement`, `movements` 配列
- セクションマップ: `personas`, `stances`, `instructions`, `report_formats`, `knowledge`
- セクションマップ: `personas`, `policies`, `instructions`, `output_contracts`, `knowledge`
### 手順 2: セクションリソースの事前読み込み
ピースYAMLのセクションマップ`personas:`, `stances:`, `instructions:`, `report_formats:`, `knowledge:`)から全ファイルパスを収集する。
ピースYAMLのセクションマップ`personas:`, `policies:`, `instructions:`, `output_contracts:`, `knowledge:`)から全ファイルパスを収集する。
パスは **ピースYAMLファイルのディレクトリからの相対パス** で解決する。
例: ピースが `~/.claude/skills/takt/pieces/default.yaml` にあり、`personas:``coder: ../personas/coder.md` がある場合
@ -128,7 +128,7 @@ current_movement のプロンプトを構築する(→ references/engine.md
プロンプト構築の要素:
1. **ペルソナ**: `persona:` キー → `personas:` セクション → .md ファイル内容
2. **スタンス**: `stance:` キー → `stances:` セクション → .md ファイル内容(複数可、末尾にリマインダー再掲)
2. **ポリシー**: `policy:` キー → `policies:` セクション → .md ファイル内容(複数可、末尾にリマインダー再掲)
3. **実行コンテキスト**: cwd, ピース名, movement名, イテレーション情報
4. **ナレッジ**: `knowledge:` キー → `knowledge:` セクション → .md ファイル内容
5. **インストラクション**: `instruction:` キー → `instructions:` セクション → .md ファイル内容(テンプレート変数展開済み)

View File

@ -58,7 +58,7 @@ Task tool:
## セクションマップの解決
ピースYAMLのトップレベルにある `personas:`, `stances:`, `instructions:`, `report_formats:`, `knowledge:` はキーとファイルパスの対応表。movement 内ではキー名で参照する。
ピースYAMLのトップレベルにある `personas:`, `policies:`, `instructions:`, `output_contracts:`, `knowledge:` はキーとファイルパスの対応表。movement 内ではキー名で参照する。
### 解決手順
@ -68,7 +68,7 @@ Task tool:
例: ピースが `~/.claude/skills/takt/pieces/default.yaml` の場合
- `personas.coder: ../personas/coder.md``~/.claude/skills/takt/personas/coder.md`
- `stances.coding: ../stances/coding.md` → `~/.claude/skills/takt/stances/coding.md`
- `policies.coding: ../policies/coding.md` → `~/.claude/skills/takt/policies/coding.md`
- `instructions.plan: ../instructions/plan.md``~/.claude/skills/takt/instructions/plan.md`
## プロンプト構築
@ -80,7 +80,7 @@ Task tool:
```
1. ペルソナプロンプトpersona: で参照される .md の全内容)
2. ---(区切り線)
3. スタンスstance: で参照される .md の内容。複数ある場合は結合)
3. ポリシーpolicy: で参照される .md の内容。複数ある場合は結合)
4. ---(区切り線)
5. 実行コンテキスト情報
6. ナレッジknowledge: で参照される .md の内容)
@ -89,28 +89,28 @@ Task tool:
9. 前の movement の出力pass_previous_response: true の場合、自動追加)
10. レポート出力指示report フィールドがある場合、自動追加)
11. ステータスタグ出力指示rules がある場合、自動追加)
12. スタンスリマインダー(スタンスがある場合、末尾に再掲)
12. ポリシーリマインダー(ポリシーがある場合、末尾に再掲)
```
### ペルソナプロンプト
movement の `persona:` キーからセクションマップを経由して .md ファイルを解決し、その全内容をプロンプトの冒頭に配置する。ペルソナはドメイン知識と行動原則のみを含む(ピース固有の手順は含まない)。
### スタンス注入
### ポリシー注入
movement の `stance:` キー(単一または配列)からスタンスファイルを解決し、内容を結合する。スタンスは行動ルール(コーディング規約、レビュー基準等)を定義する。
movement の `policy:` キー(単一または配列)からポリシーファイルを解決し、内容を結合する。ポリシーは行動ルール(コーディング規約、レビュー基準等)を定義する。
**Lost in the Middle 対策**: スタンスはプロンプトの前半に配置し、末尾にリマインダーとして再掲する。
**Lost in the Middle 対策**: ポリシーはプロンプトの前半に配置し、末尾にリマインダーとして再掲する。
```
(プロンプト冒頭付近)
## スタンス(行動ルール)
{スタンスの内容}
## ポリシー(行動ルール)
{ポリシーの内容}
(プロンプト末尾)
---
**リマインダー**: 以下のスタンスに従ってください。
{スタンスの内容(再掲)}
**リマインダー**: 以下のポリシーに従ってください。
{ポリシーの内容(再掲)}
```
### ナレッジ注入
@ -171,20 +171,20 @@ movement に `report` フィールドがある場合、プロンプト末尾に
```yaml
report:
name: 01-plan.md
format: plan # report_formats セクションのキー
format: plan # output_contracts セクションのキー
```
`report_formats:` セクションの `plan` キーから .md ファイルを解決し、Read で読んだ内容をフォーマット指示に使う:
`output_contracts:` セクションの `plan` キーから .md ファイルを解決し、Read で読んだ内容を出力契約指示に使う:
```
---
## レポート出力(必須)
作業完了後、以下のフォーマットに従ってレポートを出力してください。
作業完了後、以下の出力契約に従ってレポートを出力してください。
レポートは ```markdown ブロックで囲んで出力してください。
ファイル名: 01-plan.md
フォーマット:
{report_formats の plan キーの .md ファイル内容}
出力契約:
{output_contracts の plan キーの .md ファイル内容}
```
### 形式2: 配列(複数レポート)
@ -388,7 +388,7 @@ loop_monitors:
```
[開始]
ピースYAML読み込み + セクションマップ解決personas, stances, instructions, report_formats, knowledge
ピースYAML読み込み + セクションマップ解決personas, policies, instructions, output_contracts, knowledge
TeamCreate でチーム作成
@ -398,9 +398,9 @@ initial_movement を取得
┌─→ Task tool でチームメイト起動
│ ├── 通常: 1つの Task tool 呼び出し
│ │ prompt = persona + stance + context + knowledge
│ │ prompt = persona + policy + context + knowledge
│ │ + instruction + task + previous_response
│ │ + レポート指示 + タグ指示 + スタンスリマインダー
│ │ + レポート指示 + タグ指示 + ポリシーリマインダー
│ └── parallel: 複数の Task tool を1メッセージで並列呼び出し
│ 各サブステップを別々のチームメイトとして起動
│ ↓

View File

@ -11,18 +11,18 @@ max_iterations: 10 # 最大イテレーション数(必須)
initial_movement: plan # 最初に実行する movement 名(必須)
# セクションマップ(キー → ファイルパスの対応表)
stances: # スタンス定義(任意)
coding: ../stances/coding.md
review: ../stances/review.md
policies: # ポリシー定義(任意)
coding: ../policies/coding.md
review: ../policies/review.md
personas: # ペルソナ定義(任意)
coder: ../personas/coder.md
reviewer: ../personas/architecture-reviewer.md
instructions: # 指示テンプレート定義(任意)
plan: ../instructions/plan.md
implement: ../instructions/implement.md
report_formats: # レポートフォーマット定義(任意)
plan: ../report-formats/plan.md
review: ../report-formats/architecture-review.md
output_contracts: # 出力契約定義(任意)
plan: ../output-contracts/plan.md
review: ../output-contracts/architecture-review.md
knowledge: # ナレッジ定義(任意)
architecture: ../knowledge/architecture.md
@ -46,8 +46,8 @@ movement 内では**キー名**で参照する(パスを直接書かない)
```yaml
- name: movement-name # movement 名(必須、一意)
persona: coder # ペルソナキーpersonas マップを参照、任意)
stance: coding # スタンスキーstances マップを参照、任意)
stance: [coding, testing] # 複数指定も可(配列)
policy: coding # ポリシーキーpolicies マップを参照、任意)
policy: [coding, testing] # 複数指定も可(配列)
instruction: implement # 指示テンプレートキーinstructions マップを参照、任意)
knowledge: architecture # ナレッジキーknowledge マップを参照、任意)
edit: true # ファイル編集可否(必須)
@ -70,7 +70,7 @@ movement 内では**キー名**で参照する(パスを直接書かない)
parallel: # 並列サブステップ配列(これがあると parallel movement
- name: arch-review
persona: architecture-reviewer
stance: review
policy: review
knowledge: architecture
edit: false
instruction: review-arch
@ -83,7 +83,7 @@ movement 内では**キー名**で参照する(パスを直接書かない)
- name: qa-review
persona: qa-reviewer
stance: review
policy: review
edit: false
instruction: review-qa
rules:
@ -136,10 +136,10 @@ rules:
```yaml
report:
name: 01-plan.md
format: plan # report_formats マップのキーを参照
format: plan # output_contracts マップのキーを参照
```
`format` がキー文字列の場合、トップレベル `report_formats:` セクションから対応する .md ファイルを読み込み、フォーマット指示として使用する。
`format` がキー文字列の場合、トップレベル `output_contracts:` セクションから対応する .md ファイルを読み込み、出力契約指示として使用する。
### 形式1b: 単一レポートname + format インライン)

View File

@ -783,7 +783,7 @@ export TAKT_OPENAI_API_KEY=sk-...
## ドキュメント
- [Faceted Prompting](./prompt-composition.ja.md) - AIプロンプトへの関心の分離Persona, Stance, Instruction, Knowledge, Report Format
- [Faceted Prompting](./prompt-composition.ja.md) - AIプロンプトへの関心の分離Persona, Policy, Instruction, Knowledge, Output Contract
- [Piece Guide](./pieces.md) - ピースの作成とカスタマイズ
- [Agent Guide](./agents.md) - カスタムエージェントの設定
- [Changelog](../CHANGELOG.md) - バージョン履歴

View File

@ -20,32 +20,32 @@ Faceted Promptingはプロンプトを5つの直交する関心に分解する
| 関心 | 答える問い | 例 |
|------|-----------|-----|
| **Persona** | エージェントは*誰*か? | 役割定義、専門性、判断基準 |
| **Stance** | *どう*振る舞うべきか? | コーディング規約、レビュー基準、行動規範 |
| **Instruction** | *何を*すべきか? | ステップ固有の手順、変数付きテンプレート |
| **Knowledge** | *何を*知っているか? | アーキテクチャ文書、API仕様、例示、参照資料 |
| **Report Format** | *何を*出力すべきか? | 出力構造、レポートテンプレート |
| **Persona** | *誰*として判断するか? | 役割定義、専門性 |
| **Policy** | *何を*守るか? | 禁止事項、品質基準、優先順位 |
| **Instruction** | *何を*するか? | 目標、ステップ固有の手順 |
| **Knowledge** | *何を*参照するか? | 前提知識、ドメイン資料、API仕様 |
| **Output Contract** | *どう*出すか? | 出力構造、レポートテンプレート |
各関心はそれぞれのディレクトリに独立したファイルMarkdownまたはテンプレートとして格納される。
```
workflows/ # ワークフロー定義
personas/ # WHO — 役割定義
stances/ # HOW — 行動規範
policies/ # RULES — 禁止事項・品質基準
instructions/ # WHAT — ステップ手順
knowledge/ # CONTEXT — ドメイン情報
report-formats/ # OUTPUT — レポートテンプレート
knowledge/ # CONTEXT — 前提知識・参照資料
output-contracts/ # OUTPUT — 出力契約テンプレート
```
### なぜこの5つか
**Persona** と **Instruction** は最低限必要なもの — エージェントが誰で、何をすべきかを定義する必要がある。しかし実際には、さらに3つの関心が独立した軸として現れる。
- **Stance** はタスクをまたがって適用される行動規範を捉える。「コーディングスタンス」(命名規則、エラーハンドリングのルール、テスト要件)は、機能実装でもバグ修正でも同じように適用される。スタンスは「横断的関心事」であり、作業内容に関係なく作業の*やり方*を規定する。
- **Policy** はタスクをまたがって適用される規約・基準を捉える。「何を守るか」を定義する関心であり、禁止事項フォールバック濫用の禁止、未使用コードの禁止、品質基準REJECT/APPROVE判定、優先順位正確性 > 速度)を含む。コーディングポリシーは機能実装でもバグ修正でも同じように適用される。ポリシーは「横断的関心事」であり、作業内容に関係なく守るべきルールを規定する。
- **Knowledge**複数のエージェントが必要とするドメイン知識を捉える。アーキテクチャ文書はプランナーにもレビュアーにも関係がある。ナレッジをインストラクションから分離することで重複を防ぎ、インストラクションを手順に集中させる。
- **Knowledge**エージェントが判断の前提として参照する情報を捉える。アーキテクチャ文書はプランナーにもレビュアーにも関係がある。ナレッジをインストラクションから分離することで重複を防ぎ、インストラクションを手順に集中させる。ナレッジは記述的「このドメインはこうなっている」であり、規範的「こうすべき」なルールはPolicyに属する。
- **Report Format** は作業そのものとは独立した出力構造を捉える。同じレビューフォーマットをアーキテクチャレビュアーとセキュリティレビュアーの両方で使える。出力形式の変更がエージェントの振る舞いに影響しない。
- **Output Contract** は作業そのものとは独立した出力構造を捉える。同じレビューフォーマットをアーキテクチャレビュアーとセキュリティレビュアーの両方で使える。出力形式の変更がエージェントの振る舞いに影響しない。
## 宣言的な合成
@ -55,8 +55,8 @@ Faceted Promptingの中核メカニズムは**宣言的な合成**である。
- **各ファイルは1つの関心だけを持つ。** ペルソナファイルには役割と専門性のみを記述し、ステップ固有の手順は書かない。
- **合成は宣言的。** ワークフローは*どの*関心を組み合わせるかを記述し、プロンプトを*どう*組み立てるかは記述しない。
- **自由に組み合わせ可能。** 同じ `coder` ペルソナを異なるスタンスとインストラクションで異なるステップに使える。
- **ファイルが再利用の単位。** 同じファイルを指すことでスタンスをワークフロー間で共有する。
- **自由に組み合わせ可能。** 同じ `coder` ペルソナを異なるポリシーとインストラクションで異なるステップに使える。
- **ファイルが再利用の単位。** 同じファイルを指すことでポリシーをワークフロー間で共有する。
### TAKTでの実装例
@ -72,9 +72,9 @@ personas:
coder: ../personas/coder.md
reviewer: ../personas/architecture-reviewer.md
stances:
coding: ../stances/coding.md
review: ../stances/review.md
policies:
coding: ../policies/coding.md
review: ../policies/review.md
instructions:
plan: ../instructions/plan.md
@ -83,13 +83,13 @@ instructions:
knowledge:
architecture: ../knowledge/architecture.md
report_formats:
review: ../report-formats/review.md
output_contracts:
review: ../output-contracts/review.md
movements:
- name: implement
persona: coder # WHO — personas.coder を参照
stance: coding # HOW — stances.coding を参照
policy: coding # RULES — policies.coding を参照
instruction: implement # WHAT — instructions.implement を参照
knowledge: architecture # CONTEXT — knowledge.architecture を参照
edit: true
@ -99,12 +99,12 @@ movements:
- name: review
persona: reviewer # 異なる WHO
stance: review # 異なる HOW
policy: review # 異なる RULES
instruction: review # 異なる WHAT共有も可能
knowledge: architecture # 同じ CONTEXT — 再利用
report:
name: review.md
format: review # OUTPUT — report_formats.review を参照
format: review # OUTPUT — output_contracts.review を参照
edit: false
rules:
- condition: Approved
@ -123,27 +123,27 @@ movements:
| **Modular Prompting** | XML/HTMLタグを使った単一プロンプト内のセクション分け | 関心を*独立ファイル*に分離し、宣言的に合成する |
| **Prompt Layering** (Airia) | エンタープライズ向けのスタック可能なプロンプトセグメント | 管理ツールであり、プロンプト設計のデザインパターンではない |
| **PDL** (IBM) | データパイプライン向けのYAMLベースプロンプトプログラミング言語 | 制御フローif/for/model呼び出しが焦点で、関心の分離ではない |
| **Role/Persona Prompting** | 役割を割り当ててレスポンスを方向付ける | ペルソナは5つの関心の1つにすぎない — スタンス、インストラクション、ナレッジ、出力形式も分離する |
| **Role/Persona Prompting** | 役割を割り当ててレスポンスを方向付ける | ペルソナは5つの関心の1つにすぎない — ポリシー、インストラクション、ナレッジ、出力契約も分離する |
核心的な違いは次の点にある。既存手法は*タスク*(何をするか)を分解するか、*プロンプトの構造*どう書式化するかを整理する。Faceted Promptingは*プロンプトの関心*(各部分がなぜ存在するか)を独立した再利用可能な単位に分解する。
## 実用上の利点
**ワークフロー作者にとって:**
- コーディング規約を1つのスタンスファイルで変更すれば、それを使うすべてのワークフローに反映される
- 既存のペルソナ、スタンス、インストラクションを組み合わせて新しいワークフローを作れる
- コーディングポリシーを1つのファイルで変更すれば、それを使うすべてのワークフローに反映される
- 既存のペルソナ、ポリシー、インストラクションを組み合わせて新しいワークフローを作れる
- 各ファイルを単一の責務に集中させられる
**チームにとって:**
- プロンプトを複製せずにプロジェクト間で振る舞い(スタンス)を標準化できる
- プロンプトを複製せずにプロジェクト間でポリシー(品質基準・禁止事項)を標準化できる
- ドメイン専門家がナレッジファイルを管理し、ワークフロー設計者がインストラクションを管理する分業ができる
- 個々の関心を独立してレビューできる
**エンジンにとって:**
- プロンプト組み立ては決定的 — 同じワークフロー定義とファイルからは同じプロンプトが構築される
- スタンスの配置を最適化できる(例: 「Lost in the Middle」効果に対抗するためプロンプトの先頭と末尾に配置
- ポリシーの配置を最適化できる(例: 「Lost in the Middle」効果に対抗するためプロンプトの先頭と末尾に配置
- 各関心を他の部分に影響を与えずにステップごとに注入・省略・上書きできる
## まとめ
Faceted Promptingは、関心の分離Separation of ConcernsをAIプロンプト工学に適用するデザインパターンである。プロンプトを5つの独立した関心 — Persona、Stance、Instruction、Knowledge、Report Format — に分解し、宣言的に合成することで、再利用可能で保守しやすく透明なマルチエージェントワークフローを実現する。
Faceted Promptingは、関心の分離Separation of ConcernsをAIプロンプト工学に適用するデザインパターンである。プロンプトを5つの独立した関心 — Persona、Policy、Instruction、Knowledge、Output Contract — に分解し、宣言的に合成することで、再利用可能で保守しやすく透明なマルチエージェントワークフローを実現する。

View File

@ -20,32 +20,32 @@ Faceted Prompting decomposes prompts into five orthogonal concerns:
| Concern | Question it answers | Example |
|---------|-------------------|---------|
| **Persona** | *Who* is the agent? | Role definition, expertise, judgment criteria |
| **Stance** | *How* should it behave? | Coding standards, review criteria, behavioral rules |
| **Instruction** | *What* should it do? | Step-specific procedures, templates with variables |
| **Knowledge** | *What* does it know? | Architecture docs, API specs, examples, references |
| **Report Format** | *What* should it output? | Output structure, report templates |
| **Persona** | *Who* makes the judgment? | Role definition, expertise |
| **Policy** | *What* to uphold? | Prohibitions, quality standards, priorities |
| **Instruction** | *What* to do? | Goals, step-specific procedures |
| **Knowledge** | *What* to reference? | Domain context, reference materials, API specs |
| **Output Contract** | *How* to output? | Output structure, report templates |
Each concern is a standalone file (Markdown or template) stored in its own directory:
```
workflows/ # Workflow definitions
personas/ # WHO — role definitions
stances/ # HOW — behavioral rules
policies/ # RULES — prohibitions, quality standards
instructions/ # WHAT — step procedures
knowledge/ # CONTEXT — domain information
report-formats/ # OUTPUT — report templates
knowledge/ # CONTEXT — reference materials
output-contracts/ # OUTPUT — output contract templates
```
### Why These Five?
**Persona** and **Instruction** are the minimum — you need to define who the agent is and what it should do. But in practice, three more concerns emerge as independent axes:
- **Stance** captures behavioral rules that apply across different tasks. A "coding stance" (naming conventions, error handling rules, test requirements) applies whether the agent is implementing a feature or fixing a bug. Stances are *cross-cutting concerns* — they modify how work is done regardless of what the work is.
- **Policy** captures rules and standards that apply across different tasks. A "coding policy" (naming conventions, error handling rules, prohibitions) applies whether the agent is implementing a feature or fixing a bug. Policies define *what to uphold* — prohibitions, quality standards (REJECT/APPROVE criteria), and priorities. They are *cross-cutting concerns* that constrain work regardless of what the work is.
- **Knowledge** captures domain context that multiple agents may need. An architecture document is relevant to both the planner and the reviewer. Separating knowledge from instructions prevents duplication and keeps instructions focused on procedures.
- **Knowledge** captures reference information that agents consult as premises for their judgment. An architecture document is relevant to both the planner and the reviewer. Separating knowledge from instructions prevents duplication and keeps instructions focused on procedures. Knowledge is descriptive ("this is how the domain works"), while prescriptive rules ("you must do this") belong in Policy.
- **Report Format** captures output structure independently of the work itself. The same review format can be used by an architecture reviewer and a security reviewer. Separating it allows format changes without touching agent behavior.
- **Output Contract** captures output structure independently of the work itself. The same review format can be used by an architecture reviewer and a security reviewer. Separating it allows format changes without touching agent behavior.
## Declarative Composition
@ -55,8 +55,8 @@ Key properties:
- **Each file has one concern.** A persona file contains only role and expertise — never step-specific procedures.
- **Composition is declarative.** The workflow says *which* concerns to combine, not *how* to assemble the prompt.
- **Mix and match.** The same `coder` persona can appear with different stances and instructions in different steps.
- **Files are the unit of reuse.** Share a stance across workflows by pointing to the same file.
- **Mix and match.** The same `coder` persona can appear with different policies and instructions in different steps.
- **Files are the unit of reuse.** Share a policy across workflows by pointing to the same file.
### Implementation Example: TAKT
@ -72,9 +72,9 @@ personas:
coder: ../personas/coder.md
reviewer: ../personas/architecture-reviewer.md
stances:
coding: ../stances/coding.md
review: ../stances/review.md
policies:
coding: ../policies/coding.md
review: ../policies/review.md
instructions:
plan: ../instructions/plan.md
@ -83,13 +83,13 @@ instructions:
knowledge:
architecture: ../knowledge/architecture.md
report_formats:
review: ../report-formats/review.md
output_contracts:
review: ../output-contracts/review.md
movements:
- name: implement
persona: coder # WHO — references personas.coder
stance: coding # HOW — references stances.coding
policy: coding # RULES — references policies.coding
instruction: implement # WHAT — references instructions.implement
knowledge: architecture # CONTEXT — references knowledge.architecture
edit: true
@ -99,12 +99,12 @@ movements:
- name: review
persona: reviewer # Different WHO
stance: review # Different HOW
policy: review # Different RULES
instruction: review # Different WHAT (but could share)
knowledge: architecture # Same CONTEXT — reused
report:
name: review.md
format: review # OUTPUT — references report_formats.review
format: review # OUTPUT — references output_contracts.review
edit: false
rules:
- condition: Approved
@ -123,27 +123,27 @@ The engine resolves each key to its file, reads the content, and assembles the f
| **Modular Prompting** | Sections within a single prompt using XML/HTML tags | We separate concerns into *independent files* with declarative composition |
| **Prompt Layering** (Airia) | Stackable prompt segments for enterprise management | A management tool, not a design pattern for prompt architecture |
| **PDL** (IBM) | YAML-based prompt programming language for data pipelines | Focuses on control flow (if/for/model calls), not concern separation |
| **Role/Persona Prompting** | Assigns a role to shape responses | Persona is one of five concerns — we also separate stance, instruction, knowledge, and output format |
| **Role/Persona Prompting** | Assigns a role to shape responses | Persona is one of five concerns — we also separate policy, instruction, knowledge, and output contract |
The key distinction: existing approaches either decompose *tasks* (what to do) or *structure prompts* (how to format). Faceted Prompting decomposes *prompt concerns* (why each part exists) into independent, reusable units.
## Practical Benefits
**For workflow authors:**
- Change a coding standard in one stance file; every workflow using it gets the update
- Create a new workflow by combining existing personas, stances, and instructions
- Change a coding policy in one file; every workflow using it gets the update
- Create a new workflow by combining existing personas, policies, and instructions
- Focus each file on a single responsibility
**For teams:**
- Standardize behavior (stances) across projects without duplicating prompts
- Standardize policies (quality standards, prohibitions) across projects without duplicating prompts
- Domain experts maintain knowledge files; workflow designers maintain instructions
- Review individual concerns independently
**For the engine:**
- Prompt assembly is deterministic — given the same workflow definition and files, the same prompt is built
- Stance placement can be optimized (e.g., placed at top and bottom to counter the "Lost in the Middle" effect)
- Policy placement can be optimized (e.g., placed at top and bottom to counter the "Lost in the Middle" effect)
- Concerns can be injected, omitted, or overridden per step without touching other parts
## Summary
Faceted Prompting is a design pattern that applies Separation of Concerns to AI prompt engineering. By decomposing prompts into five independent concerns — Persona, Stance, Instruction, Knowledge, and Report Format — and composing them declaratively, it enables reusable, maintainable, and transparent multi-agent workflows.
Faceted Prompting is a design pattern that applies Separation of Concerns to AI prompt engineering. By decomposing prompts into five independent concerns — Persona, Policy, Instruction, Knowledge, and Output Contract — and composing them declaratively, it enables reusable, maintainable, and transparent multi-agent workflows.

View File

@ -56,7 +56,6 @@ const { confirm } = await import('../shared/prompt/index.js');
describe('deploySkill', () => {
let skillDir: string;
let commandDir: string;
beforeEach(() => {
// Create fake resources directory with skill files
@ -66,8 +65,6 @@ describe('deploySkill', () => {
const skillResourcesDir = join(fakeResourcesDir, 'skill');
mkdirSync(skillResourcesDir, { recursive: true });
writeFileSync(join(skillResourcesDir, 'SKILL.md'), '# SKILL');
writeFileSync(join(skillResourcesDir, 'takt-command.md'), '# Command');
// Create skill/references/ directory
const refsDir = join(skillResourcesDir, 'references');
mkdirSync(refsDir, { recursive: true });
@ -78,26 +75,24 @@ describe('deploySkill', () => {
const langDir = join(fakeResourcesDir, 'en');
mkdirSync(join(langDir, 'pieces'), { recursive: true });
mkdirSync(join(langDir, 'personas'), { recursive: true });
mkdirSync(join(langDir, 'stances'), { recursive: true });
mkdirSync(join(langDir, 'policies'), { recursive: true });
mkdirSync(join(langDir, 'instructions'), { recursive: true });
mkdirSync(join(langDir, 'knowledge'), { recursive: true });
mkdirSync(join(langDir, 'report-formats'), { recursive: true });
mkdirSync(join(langDir, 'output-contracts'), { recursive: true });
mkdirSync(join(langDir, 'templates'), { recursive: true });
// Add sample files
writeFileSync(join(langDir, 'pieces', 'default.yaml'), 'name: default');
writeFileSync(join(langDir, 'personas', 'coder.md'), '# Coder');
writeFileSync(join(langDir, 'stances', 'coding.md'), '# Coding');
writeFileSync(join(langDir, 'policies', 'coding.md'), '# Coding');
writeFileSync(join(langDir, 'instructions', 'init.md'), '# Init');
writeFileSync(join(langDir, 'knowledge', 'patterns.md'), '# Patterns');
writeFileSync(join(langDir, 'report-formats', 'summary.md'), '# Summary');
writeFileSync(join(langDir, 'output-contracts', 'summary.md'), '# Summary');
writeFileSync(join(langDir, 'templates', 'task.md'), '# Task');
// Create target directories
skillDir = join(testHomeDir, '.claude', 'skills', 'takt');
commandDir = join(testHomeDir, '.claude', 'commands');
mkdirSync(skillDir, { recursive: true });
mkdirSync(commandDir, { recursive: true });
// Reset mocks
vi.clearAllMocks();
@ -123,13 +118,6 @@ describe('deploySkill', () => {
expect(readFileSync(join(skillDir, 'SKILL.md'), 'utf-8')).toBe('# SKILL');
});
it('should copy command file to commands directory', async () => {
await deploySkill();
expect(existsSync(join(commandDir, 'takt.md'))).toBe(true);
expect(readFileSync(join(commandDir, 'takt.md'), 'utf-8')).toBe('# Command');
});
it('should copy references directory', async () => {
await deploySkill();
@ -145,10 +133,10 @@ describe('deploySkill', () => {
// Verify each resource directory is copied
expect(existsSync(join(skillDir, 'pieces', 'default.yaml'))).toBe(true);
expect(existsSync(join(skillDir, 'personas', 'coder.md'))).toBe(true);
expect(existsSync(join(skillDir, 'stances', 'coding.md'))).toBe(true);
expect(existsSync(join(skillDir, 'policies', 'coding.md'))).toBe(true);
expect(existsSync(join(skillDir, 'instructions', 'init.md'))).toBe(true);
expect(existsSync(join(skillDir, 'knowledge', 'patterns.md'))).toBe(true);
expect(existsSync(join(skillDir, 'report-formats', 'summary.md'))).toBe(true);
expect(existsSync(join(skillDir, 'output-contracts', 'summary.md'))).toBe(true);
expect(existsSync(join(skillDir, 'templates', 'task.md'))).toBe(true);
});
});

View File

@ -575,7 +575,7 @@ describe('instruction-builder', () => {
expect(result).not.toContain('**Report output:**');
});
it('should NOT include report format in buildInstruction', () => {
it('should NOT include output contract in buildInstruction', () => {
const step = createMinimalStep('Do work');
step.report = { name: '00-plan.md', format: '**Format:**\n# Plan' };
const context = createMinimalContext({

View File

@ -240,13 +240,13 @@ describe('interactiveMode', () => {
// When
await interactiveMode('/project');
// Then: each call receives user input with stance injected (session maintains context)
// Then: each call receives user input with policy injected (session maintains context)
const mockProvider = mockGetProvider.mock.results[0]!.value as { _call: ReturnType<typeof vi.fn> };
expect(mockProvider._call.mock.calls[0]?.[0]).toContain('first msg');
expect(mockProvider._call.mock.calls[1]?.[0]).toContain('second msg');
});
it('should inject stance into user messages', async () => {
it('should inject policy into user messages', async () => {
// Given
setupInputSequence(['test message', '/cancel']);
setupMockProvider(['response']);
@ -254,12 +254,12 @@ describe('interactiveMode', () => {
// When
await interactiveMode('/project');
// Then: the prompt should contain stance section
// Then: the prompt should contain policy section
const mockProvider = mockGetProvider.mock.results[0]!.value as { _call: ReturnType<typeof vi.fn> };
const prompt = mockProvider._call.mock.calls[0]?.[0] as string;
expect(prompt).toContain('## Stance');
expect(prompt).toContain('Interactive Mode Stance');
expect(prompt).toContain('Stance Reminder');
expect(prompt).toContain('## Policy');
expect(prompt).toContain('Interactive Mode Policy');
expect(prompt).toContain('Policy Reminder');
expect(prompt).toContain('test message');
});
@ -271,11 +271,11 @@ describe('interactiveMode', () => {
// When
const result = await interactiveMode('/project', 'a');
// Then: AI should have been called with initialInput (with stance injected)
// Then: AI should have been called with initialInput (with policy injected)
const mockProvider = mockGetProvider.mock.results[0]!.value as { _call: ReturnType<typeof vi.fn> };
expect(mockProvider._call).toHaveBeenCalledTimes(2);
const firstPrompt = mockProvider._call.mock.calls[0]?.[0] as string;
expect(firstPrompt).toContain('## Stance');
expect(firstPrompt).toContain('## Policy');
expect(firstPrompt).toContain('a');
// /go should work because initialInput already started conversation
@ -291,7 +291,7 @@ describe('interactiveMode', () => {
// When
const result = await interactiveMode('/project', 'a');
// Then: each call receives only its own input with stance (session handles history)
// Then: each call receives only its own input with policy (session handles history)
const mockProvider = mockGetProvider.mock.results[0]!.value as { _call: ReturnType<typeof vi.fn> };
expect(mockProvider._call).toHaveBeenCalledTimes(3);
const firstPrompt = mockProvider._call.mock.calls[0]?.[0] as string;

Some files were not shown because too many files have changed in this diff Show More