devflow-kit 3.1.0 → 3.3.0

package/src/assets/skills/apply-decisions/SKILL.md

@@ -1,14 +1,12 @@
 ---
 name: apply-decisions
-description: Canonical algorithm for consuming DECISIONS_CONTEXT index — scan index, identify relevant entries, Read full bodies on demand, cite verbatim IDs in-session and state the rule in words in anything committed or posted.
+description: Consume the DECISIONS_CONTEXT index; cite IDs in-session only
 user-invocable: false
-allowed-tools: Read
+allowed-tools: Read, Bash
 ---
 
 # Apply Decisions
 
-Canonical consumer algorithm for the `DECISIONS_CONTEXT` index passed by orchestrators. The index lists each active ADR/PF entry with its ID and title — plus a status tag and an area on a v1 line, or the entry's scope on a v2 line — not the full body. Use this skill to surface the right decisions and pitfalls for your task without loading the entire corpus.
-
 ## Iron Law
 
 > **VERBATIM IDs ONLY — NEVER FABRICATE**
@@ -17,104 +15,36 @@ Canonical consumer algorithm for the `DECISIONS_CONTEXT` index passed by orchest
 > in the index, do not cite it. If an entry looks relevant but you haven't Read its
 > full body, do not cite it. Fabricated citations are worse than no citations.
 
----
-
 ## 5-Step Algorithm
 
 ### Step 1: Scan the index
 
-Read through all entries in `DECISIONS_CONTEXT`. The index lists active entries only, in two line kinds:
-
-```
-Decisions (N):
-  ADR-NNN  Return Result types from every fallible operation  [Accepted]
-  ADR-NNN  Claim the learning queue with an op, never with mv  —  src/assets/scripts/hooks/**, area:learning
-
-Pitfalls (M):
-  PF-NNN  Background hook god scripts  [Active]  —  src/assets/scripts/hooks/foo.cjs
-  PF-NNN  A rename claims a shared file only while nothing re-creates it  —  area:hooks
-
-ADR-NNN entries live in {worktree}/.devflow/learning/decisions.md
-PF-NNN  entries live in {worktree}/.devflow/learning/pitfalls.md
-Read the relevant file and locate the matching `## ADR-NNN:` or `## PF-NNN:` heading for the full body.
-```
-
-- **A v1 line** ends in a status tag — `[Accepted]` on a decision, `[Active]` on a pitfall — after a title cut to 60 characters, and a pitfall adds its area after `—`.
-- **A v2 line** has no tag. Its title is whole, and after `—` comes its scope: the globs and `area:` tags the rule governs, cut to 80 characters.
+One line per active entry: its ID (`ADR-NNN` or `PF-NNN`), a title, then a status tag and/or, after `—`, its area or scope. The footer names the decisions and pitfalls files.
 
 ### Step 2: Identify plausibly-relevant entries
 
-From the index, identify entries whose title, area or scope plausibly overlaps with:
-- The files you are modifying or reviewing — a v2 scope glob that matches one of them is a strong signal
-- The category of issue you are addressing (e.g., error handling, hook scripts, JSON parsing)
-- The architectural area of your change
-
-A v1 title may be cut short — if a truncated title looks relevant, proceed to Step 3.
+Pick entries whose title, area or scope overlaps the files you touch (a matching scope glob is a strong signal), the kind of issue or the architectural area. Follow up a cut-short title that looks relevant.
 
 ### Step 3: Read the full body
 
-For each plausibly-relevant entry, use the Read tool to open the decisions file listed in the `DECISIONS_CONTEXT` footer and locate the matching `## ADR-NNN:` or `## PF-NNN:` heading. Read the full section to confirm relevance and understand the decision or pitfall completely.
-
-A v2 body reads:
+Find the entry's heading line in the file the footer names, then Read only that section:
 
+```bash
+command grep -nF '## ADR-NNN:' "{worktree-from-footer}/.devflow/learning/decisions.md"
 ```
-## ADR-NNN: {title}
 
-- **Status**: Accepted · verified {date}
-- **Scope**: `{glob}`, `area:{tag}`
-- **Decision**: {the rule}
-- **Why**: {why it holds}
-- **Source**: {where it was learned}
-```
-
-A pitfall's Status is `Active` and its rule line is labelled `**Rule**`. The verified date is the day the entry was last confirmed true; a body without one has not been confirmed since it was written. A v1 body carries `**Date**`, `**Status**`, `**Context**`, `**Decision**` and `**Consequences**` for a decision, or `**Area**`, `**Issue**`, `**Impact**`, `**Resolution**` and `**Status**` for a pitfall.
-
-**The footer is the single source of truth for file paths.** Never substitute hardcoded paths — the footer resolves to the correct worktree, which may differ from your cwd in multi-worktree flows.
-
-```
-Use the exact paths from the DECISIONS_CONTEXT footer, e.g.:
-  {worktree-from-footer}/.devflow/learning/decisions.md   → find ## ADR-NNN: heading
-  {worktree-from-footer}/.devflow/learning/pitfalls.md    → find ## PF-NNN: heading
-```
-
-Only cite an entry after you have read its full body and confirmed it applies.
+For a pitfall use `## PF-NNN:` and `pitfalls.md`. Read with `offset` at the printed line and a `limit` of about 25, stopping at the next `## `. The footer is the single source of truth for paths; the ledger is git-ignored, so only a shell search finds the line. A `verified` date is when the entry was last confirmed true; none means unconfirmed. Cite only after reading the body and confirming it applies.
 
 ### Step 4: Cite inline — in-session handoffs only
 
-When applying a prior decision, cite as `applies ADR-NNN`. When avoiding a known pitfall, cite as `avoids PF-NNN`. Place these citations only where they stay in the session: your reasoning, decision tables, prompts to downstream agents, and your report back to the caller.
+Cite `applies ADR-NNN` or `avoids PF-NNN` in-session only: your reasoning, prompts to downstream agents, your report back.
 
-Anything committed, pushed or posted states the rule in words, never its ID: code, comments, tests, docs, KNOWLEDGE.md files, commit messages, PR and issue text, review and PR comments, resolution summaries — and any report a later step copies into one of those. The ledger is gitignored and numbered per machine, so no other clone can resolve an ID, and numbers get reused.
+Anything committed, pushed or posted states the rule in words, never its ID (code, comments, tests, docs, commit messages, PR and issue text, review comments, and any report copied into those). IDs are numbered per machine, so no other clone can resolve one.
 
 ### Step 5: Use verbatim IDs only
 
-Cite only IDs that appear verbatim in `DECISIONS_CONTEXT`. Do not guess at IDs that might exist. Do not construct IDs from memory. If no entry is clearly relevant, skip citation entirely — silence is correct when nothing applies.
-
----
-
-## Worked Example
-
-**Scenario**: Reviewing `src/assets/scripts/hooks/background-learning` for issues.
-
-1. **Scan** — Index shows `PF-NNN  Background hook god scripts  [Active]  —  src/assets/scripts/hooks/foo.cjs`
-2. **Identify** — Area field includes `src/assets/scripts/hooks/` which overlaps with the file under review
-3. **Read** — Open the pitfalls file at the path given in the DECISIONS_CONTEXT footer (e.g., `<worktree>/.devflow/learning/pitfalls.md`), find `## PF-NNN:` section, read full body
-4. **Cite** — If the file shows signs of the god-script pattern, note `avoids PF-NNN` in reasoning; a comment you commit for the fix says why in words ("hooks stay thin dispatchers"), never the ID
-5. **Verbatim** — ID `PF-NNN` appeared in the index; citation is valid
-
----
+Cite only IDs in `DECISIONS_CONTEXT`; never guess or rebuild one. When nothing clearly applies, cite nothing.
 
 ## Skip Guard
 
-When `DECISIONS_CONTEXT` is empty, `(none)`, or not provided: skip this skill entirely — unless your agent instructions tell you to read the decisions index yourself, in which case the index you read is your `DECISIONS_CONTEXT`. Do not otherwise load decisions files independently. Do not speculate about what decisions or pitfalls might exist.
-
----
-
-## Citation Format Reference
-
-| Situation | Citation |
-|-----------|----------|
-| Applying a prior architectural decision | `applies ADR-NNN` |
-| Avoiding a known pitfall | `avoids PF-NNN` |
-| Entry not in index | (no citation — silence is correct) |
-| Entry in index but not read yet | (no citation — read first) |
-| Text that is committed, pushed or posted | (no ID — state the rule in words) |
+When `DECISIONS_CONTEXT` is empty, `(none)` or not provided, skip this skill — unless your instructions tell you to read the decisions index yourself; that index is then your `DECISIONS_CONTEXT`. Never load decisions files otherwise.

package/src/assets/skills/apply-feature-knowledge/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: apply-feature-knowledge
-description: Consumption algorithm for FEATURE_KNOWLEDGE variable — pre-computed feature context
+description: Consume FEATURE_KNOWLEDGE, the pre-computed feature context
 user-invocable: false
 allowed-tools: Read
 ---
@@ -11,37 +11,17 @@ allowed-tools: Read
 
 > **Pre-computed context, not a cage. Verify against current code — always.**
 >
-> A feature knowledge captures patterns AS THEY WERE when last written. Code evolves.
-> Use the feature knowledge as a starting point, not gospel truth. When something feels
-> off, Read the actual files. Code is authoritative; feature knowledge is supplementary.
+> A feature knowledge captures patterns AS THEY WERE when last written. Use it as a
+> starting point, not gospel truth; when something feels off, Read the actual files.
+> Code is authoritative.
 
 ---
 
 ## 3-Step Algorithm
 
-### Step 1: Read the Feature Knowledge
-
-When `FEATURE_KNOWLEDGE` is provided and is not `(none)`:
-
-1. Read each feature knowledge section (separated by `--- Feature knowledge: {slug} ---` headers)
-2. Absorb: architecture, data flow, key patterns, anti-patterns, gotchas
-3. Note integration points that relate to your current task
-
-### Step 2: Apply to Current Task
-
-1. **Patterns as defaults**: Follow documented patterns unless you have a specific reason not to
-2. **Anti-patterns as warnings**: Check your work against documented anti-patterns
-3. **Gotchas as checklists**: Verify each gotcha doesn't apply to your changes
-4. **Integration points**: Ensure your changes respect documented boundaries
-5. **Key files**: Use as starting points for exploration
-
-### Step 3: Verify Against Current Code
-
-The feature knowledge may not reflect recent changes:
-- If the feature knowledge doesn't address your specific area, explore further
-- **When an assertion seems outdated**: Read the relevant source files to confirm — code wins
-- When you find a contradiction between the KB and actual code, trust the code
-- Note discrepancies in your output when they matter for the task
+1. **Read** each section of `FEATURE_KNOWLEDGE` (headed `--- Feature knowledge: {slug} ---`) for architecture, data flow, patterns, anti-patterns, gotchas and the integration points your task touches.
+2. **Apply** it: follow documented patterns unless you have a specific reason not to; check your work against each anti-pattern and gotcha; respect documented integration boundaries; start exploring from the key files.
+3. **Verify** against current code: it may not reflect recent changes. Where it is silent on your area, explore further. Where an assertion seems outdated or contradicts the code, Read the source and trust it. Note a discrepancy in your output when it matters for the task.
 
 ---
 
@@ -52,18 +32,4 @@ Do not mention feature knowledge or its absence in your output.
 
 ## Freshness Model
 
-Feature knowledge uses **write-through + verify-on-read** for freshness:
-- KBs are written at the point a documented area changes (not on a background schedule)
-- Readers verify key assertions against current code rather than relying on staleness markers
-- When in doubt, Read the file — that resolves any uncertainty immediately
-
-## Concatenation Format
-
-Multiple feature knowledge entries are concatenated with slug headers:
-```
---- Feature knowledge: payments ---
-[full KNOWLEDGE.md content]
-
---- Feature knowledge: auth ---
-[full KNOWLEDGE.md content]
-```
+Feature knowledge is **verify-on-read**: check key assertions against current code, not staleness markers, and when in doubt Read the file.

package/src/assets/skills/architecture/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: architecture
-description: This skill should be used when reviewing code for SOLID violations, tight coupling, or layering issues.
+description: This skill should be used when reviewing code for SOLID or layering issues.
 user-invocable: false
 allowed-tools: Read, Grep, Glob
 ---

package/src/assets/skills/boundary-validation/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: boundary-validation
-description: This skill should be used when the user asks to "validate input", "parse request data", "handle form data", "add Zod schema", "sanitize user input", or creates API endpoints and system boundaries. Provides parse-don't-validate patterns with schema validation for type-safe boundary enforcement and hostile input defense.
+description: This skill should be used when the user asks to "validate input", "parse request data", "add Zod schema", or creates API endpoints and system boundaries.
 user-invocable: false
 allowed-tools: Read, Grep, Glob, AskUserQuestion
 ---

package/src/assets/skills/complexity/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: complexity
-description: This skill should be used when reviewing code for high cyclomatic complexity, deep nesting, or long functions.
+description: This skill should be used when reviewing code for deep nesting or long functions.
 user-invocable: false
 allowed-tools: Read, Grep, Glob
 ---

package/src/assets/skills/compliance/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: compliance
-description: This skill should be used when reviewing code handling PII, payment data, health records, audit logs, data retention, or IaC under GDPR, HIPAA, PCI DSS, SOC 2, ISO 27001, or SOX.
+description: This skill should be used when reviewing code that handles PII, payments or health data.
 user-invocable: false
 allowed-tools: Read, Grep, Glob
 ---

package/src/assets/skills/consistency/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: consistency
-description: This skill should be used when reviewing code for naming convention violations, pattern deviations, or inconsistent API styles.
+description: This skill should be used when reviewing code for naming or pattern inconsistencies.
 user-invocable: false
 allowed-tools: Read, Grep, Glob
 ---

package/src/assets/skills/database/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: database
-description: This skill should be used when reviewing database queries, migrations, indexes, or schema changes.
+description: This skill should be used when reviewing queries, migrations or schema changes.
 user-invocable: false
 allowed-tools: Read, Grep, Glob
 ---

package/src/assets/skills/dependencies/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: dependencies
-description: This skill should be used when reviewing dependency changes, lock files, or package additions.
+description: This skill should be used when reviewing dependency or lock file changes.
 user-invocable: false
 allowed-tools: Read, Grep, Glob
 ---

package/src/assets/skills/dependency-research/SKILL.md

@@ -1,9 +1,6 @@
 ---
 name: dependency-research
-description: >-
-  This skill should be used when the user asks to "add a utility", "create a helper",
-  "implement parsing", "build a wrapper", or writes infrastructure/utility code that
-  may already exist as a well-maintained package. Enforces research before building.
+description: This skill should be used when the user asks to "add a utility", "create a helper", "build a wrapper", or writes utility code a maintained package may already provide.
 user-invocable: false
 allowed-tools: Read, Grep, Glob
 ---
@@ -54,9 +51,9 @@ Nice-to-haves: {optional features}
 
 ### Phase 2: Search
 
-Delegate research to an Explore subagent to keep main session context clean.
+Spawn an Explore subagent when you can spawn agents, to keep main session context clean; otherwise search directly, using the template's questions as your checklist.
 
-**Spawn an Explore agent** with this prompt template:
+**Prompt template** for the Explore agent:
 
 ```
 Agent(subagent_type="Explore"):

package/src/assets/skills/design-review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: design-review
-description: This skill should be used when reviewing implementation plans for anti-patterns, checking design quality before implementation, or performing plan-level quality assessment. Provides 6 anti-pattern detection rules for the Design agent and inline planning.
+description: This skill should be used when reviewing implementation plans for anti-patterns.
 user-invocable: false
 allowed-tools: Read, Grep, Glob
 ---

package/src/assets/skills/docs-framework/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: docs-framework
-description: This skill should be used when the user asks to "create a review report", "write a status log", "add documentation", "name this artifact", or creates files in the .devflow/docs/ directory. Provides naming conventions, templates, and directory structure for reviews, debug sessions, design docs, and all persistent Devflow documentation artifacts.
+description: This skill should be used when creating files in the .devflow/docs/ directory.
 user-invocable: false
 allowed-tools: Read, Bash, Glob
 ---

package/src/assets/skills/documentation/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: documentation
-description: This skill should be used when reviewing for documentation drift, missing API docs, or stale comments.
+description: This skill should be used when reviewing for documentation drift or stale comments.
 user-invocable: false
 allowed-tools: Read, Grep, Glob
 ---

package/src/assets/skills/gap-analysis/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: gap-analysis
-description: This skill should be used when analyzing design documents, specifications, or plans for completeness gaps, architectural issues, security concerns, and performance implications. Provides focus-specific detection patterns for the Design agent.
+description: This skill should be used when analyzing specs or plans for completeness gaps.
 user-invocable: false
 allowed-tools: Read, Grep, Glob
 ---

package/src/assets/skills/git/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: git
-description: This skill should be used when the user asks to "commit changes", "create a pull request", "rebase safely", "manage branches", "fix merge conflicts", "undo a commit", "comment on a PR", "create a release", or performs any git/GitHub operations. Provides safety patterns, atomic commit formatting, PR descriptions, sensitive file detection, and GitHub API usage.
+description: This skill should be used when the user asks to "commit changes", "create a pull request", "rebase safely", or performs any git/GitHub operation.
 user-invocable: false
 allowed-tools: Bash, Read, Grep, Glob
 ---

package/src/assets/skills/go/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: go
-description: This skill should be used when the user works with Go files (.go), asks about "error handling", "interfaces", "goroutines", "channels", "packages", or discusses Go idioms and concurrency. Provides patterns for error handling, interface design, concurrency, and package organization.
+description: This skill should be used when the user works with Go files (.go), asks about "error handling", "interfaces", "goroutines", or discusses Go idioms and concurrency.
 user-invocable: false
 allowed-tools: Read, Grep, Glob
 activation:

package/src/assets/skills/java/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: java
-description: This skill should be used when the user works with Java files (.java), asks about "records", "sealed classes", "Optional", "streams", "composition over inheritance", or discusses modern Java patterns and API design. Provides patterns for type system usage, error handling, immutability, and concurrency.
+description: This skill should be used when the user works with Java files (.java), asks about "records", "sealed classes", "streams", or discusses modern Java patterns.
 user-invocable: false
 allowed-tools: Read, Grep, Glob
 activation:

package/src/assets/skills/patterns/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: patterns
-description: This skill should be used when the user asks to "create an API endpoint", "add CRUD operations", "implement event handlers", "set up logging", "add configuration", or builds features involving database operations, REST/GraphQL APIs, pub/sub patterns, or service configuration. Provides implementation patterns that follow existing codebase conventions.
+description: This skill should be used when the user asks to "create an API endpoint", "add CRUD operations", "implement event handlers", "set up logging", or adds database operations, REST/GraphQL APIs, pub/sub.
 user-invocable: false
 allowed-tools: Read, Grep, Glob
 ---

package/src/assets/skills/performance/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: performance
-description: This skill should be used when reviewing code for N+1 queries, memory leaks, or I/O bottlenecks.
+description: This skill should be used when reviewing code for N+1 queries or memory leaks.
 user-invocable: false
 allowed-tools: Read, Grep, Glob
 ---

package/src/assets/skills/python/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: python
-description: This skill should be used when the user works with Python files (.py), asks about "type hints", "protocols", "dataclasses", "async/await", "decorators", or discusses Pythonic patterns and data modeling. Provides patterns for type safety, error handling, data modeling, and async programming.
+description: This skill should be used when the user works with Python files (.py), asks about "type hints", "protocols", "dataclasses", "async/await", or discusses Pythonic patterns.
 user-invocable: false
 allowed-tools: Read, Grep, Glob
 activation:

package/src/assets/skills/qa/SKILL.md

@@ -1,8 +1,6 @@
 ---
 name: qa
-description: This skill should be used when performing scenario-based acceptance testing,
-  designing QA test plans, or validating that implementation behavior matches acceptance
-  criteria beyond unit tests.
+description: This skill should be used when designing or running scenario-based acceptance tests.
 user-invocable: false
 allowed-tools: Read, Grep, Glob, Bash
 ---

package/src/assets/skills/quality-gates/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: quality-gates
-description: This skill should be used when evaluating implementation quality before submission, checking correctness, security, and simplicity.
+description: This skill should be used when evaluating implementation quality before submission.
 user-invocable: false
 allowed-tools: Read, Grep, Glob, Edit, Write, Bash
 ---
@@ -26,7 +26,7 @@ Based on [Google Engineering Practices](https://google.github.io/eng-practices/r
 |----------|--------|---------|
 | **P0** | MUST fix | Design, Functionality, Security |
 | **P1** | SHOULD fix | Complexity, Error Handling, Tests |
-| **P2** | FIX if time | Naming, Consistency, Documentation |
+| **P2** | FIX if straightforward | Documentation (Naming and Consistency belong to the Simplify agent: report them as SKIP) |
 
 ### P0 - Design
 Does the implementation fit the architecture? Follows existing patterns, respects layer boundaries, dependencies injected.
@@ -48,11 +48,8 @@ Errors handled explicitly? No swallowed exceptions, helpful messages, resources
 ### P1 - Tests
 New code tested? Covers happy path, errors, edges. Tests behavior, not implementation.
 
-### P2 - Naming
-Names clear and descriptive? No cryptic abbreviations, consistent style.
-
-### P2 - Consistency
-Matches existing patterns? Same style, same conventions, no unnecessary divergence.
+### P2 - Naming and Consistency
+Owned by the Simplify agent, which applies the project's naming and style standards. Report both as SKIP; do not judge or fix them here.
 
 ### P2 - Documentation
 Will others understand? Complex logic commented, public APIs documented, no outdated comments.
@@ -99,7 +96,7 @@ Check Design, Functionality, Security. If issues found and fixable, fix immediat
 Check Complexity, Error Handling, Tests. Fix issues found.
 
 ### Step 4: Evaluate P2 Pillars
-Check Naming, Consistency, Documentation. Fix if time permits.
+Check Documentation and fix it if straightforward. Naming and Consistency are the Simplify agent's: SKIP.
 
 ### Step 5: Generate Report
 Document status of each pillar, fixes applied, and overall readiness.
@@ -122,13 +119,13 @@ Document status of each pillar, fixes applied, and overall readiness.
 - Tests: PASS/FIXED
 
 ### P2 Pillars
-- Naming: PASS/FIXED/SKIP
-- Consistency: PASS/FIXED/SKIP
-- Documentation: PASS/FIXED/SKIP
+- Naming: SKIP (Simplify agent)
+- Consistency: SKIP (Simplify agent)
+- Documentation: PASS/FIXED
 
 ### Summary
 Issues Found: {n}, Fixed: {n}
-Status: READY / BLOCKED
+Status: PASS / FIXED / BLOCKED
 ```
 
 ---

package/src/assets/skills/quality-gates/references/report-template.md

@@ -44,13 +44,13 @@ Use this template when generating your self-review report.
 
 ---
 
-### P2 Pillars (FIX if Time Permits)
+### P2 Pillars (Documentation only)
 
 | Pillar | Status | Notes |
 |--------|--------|-------|
-| Naming | PASS/FIXED/SKIP | {details} |
-| Consistency | PASS/FIXED/SKIP | {details} |
-| Documentation | PASS/FIXED/SKIP | {details} |
+| Naming | SKIP | Simplify agent |
+| Consistency | SKIP | Simplify agent |
+| Documentation | PASS/FIXED | {details if fixed} |
 
 **Fixes Applied** (if any):
 - {file:line} - {what was fixed}
@@ -61,7 +61,7 @@ Use this template when generating your self-review report.
 
 **Issues Found**: {total count}
 **Issues Fixed**: {count}
-**Status**: READY / BLOCKED
+**Status**: PASS / FIXED / BLOCKED
 
 {If BLOCKED, explain what cannot be fixed and why}
 ```
@@ -105,12 +105,12 @@ Add user profile update endpoint
 
 ---
 
-### P2 Pillars (FIX if Time Permits)
+### P2 Pillars (Documentation only)
 
 | Pillar | Status | Notes |
 |--------|--------|-------|
-| Naming | PASS | Clear, descriptive names |
-| Consistency | PASS | Matches existing patterns |
+| Naming | SKIP | Simplify agent |
+| Consistency | SKIP | Simplify agent |
 | Documentation | PASS | JSDoc on public methods |
 
 ---
@@ -119,7 +119,7 @@ Add user profile update endpoint
 
 **Issues Found**: 0
 **Issues Fixed**: 0
-**Status**: READY
+**Status**: PASS
 ```
 
 ### Example 2: Issues Fixed
@@ -165,12 +165,12 @@ Implement order cancellation flow
 
 ---
 
-### P2 Pillars (FIX if Time Permits)
+### P2 Pillars (Documentation only)
 
 | Pillar | Status | Notes |
 |--------|--------|-------|
-| Naming | PASS | Clear names |
-| Consistency | PASS | Matches existing order methods |
+| Naming | SKIP | Simplify agent |
+| Consistency | SKIP | Simplify agent |
 | Documentation | FIXED | Added JSDoc explaining cancellation rules |
 
 **Fixes Applied**:
@@ -182,7 +182,7 @@ Implement order cancellation flow
 
 **Issues Found**: 5
 **Issues Fixed**: 5
-**Status**: READY
+**Status**: FIXED
 ```
 
 ### Example 3: Blocked
@@ -233,12 +233,12 @@ before implementing refund feature.
 
 ## Status Definitions
 
-| Status | Meaning |
-|--------|---------|
-| PASS | No issues found for this pillar |
-| FIXED | Issue found and resolved |
-| SKIP | P2 only - issue noted but not fixed due to time |
-| BLOCKED | Cannot fix - requires escalation |
+| Status | Pillar | Overall (`### Status`) |
+|--------|--------|------------------------|
+| PASS | No issues found for this pillar | No change was needed |
+| FIXED | Issue found and resolved | Fixes were committed and every P0 and P1 is fixed |
+| SKIP | Naming and Consistency only - owned by the Simplify agent | - |
+| BLOCKED | Cannot fix - requires escalation | A P0 cannot be fixed in scope |
 
 ---
 
@@ -247,7 +247,7 @@ before implementing refund feature.
 Before submitting report:
 - [ ] All P0 pillars are PASS or FIXED
 - [ ] All P1 pillars are PASS or FIXED
-- [ ] P2 pillars evaluated (PASS/FIXED/SKIP)
+- [ ] Documentation evaluated (PASS/FIXED); Naming and Consistency reported as SKIP
 - [ ] All fixes documented with file:line
 - [ ] Summary accurately reflects status
 - [ ] If BLOCKED, clear explanation provided

package/src/assets/skills/react/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: react
-description: This skill should be used when the user works with React components (.tsx/.jsx), asks about "hooks", "state management", "context providers", "memo optimization", "useEffect", or discusses component composition and rendering performance. Provides patterns for hooks, state, effects, memoization, and React-specific architecture.
+description: This skill should be used when the user works with React components (.tsx/.jsx), asks about "hooks", "state management", "memo optimization", or discusses component composition.
 user-invocable: false
 allowed-tools: Read, Grep, Glob
 activation:

package/src/assets/skills/regression/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: regression
-description: This skill should be used when reviewing changes that may remove exports, change signatures, or alter behavior.
+description: This skill should be used when reviewing changes that may break existing behavior.
 user-invocable: false
 allowed-tools: Read, Grep, Glob
 ---

package/src/assets/skills/reliability/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: reliability
-description: This skill should be used when reviewing code for unbounded loops, missing assertions, excessive allocation, or deep indirection.
+description: This skill should be used when reviewing code for unbounded loops or missing assertions.
 user-invocable: false
 allowed-tools: Read, Grep, Glob
 ---

package/src/assets/skills/research-codebase/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: research-codebase
-description: Local codebase research — find patterns, trace flows, map dependencies without browsing the web
+description: Local codebase research — find patterns, trace flows, map dependencies
 user-invocable: false
 allowed-tools: Read, Grep, Glob
 ---

package/src/assets/skills/research-competitor/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: research-competitor
-description: Competitor analysis — structured feature comparison, positioning analysis, and gap identification
+description: Competitor analysis — feature comparison, positioning and gap identification
 user-invocable: false
 allowed-tools: WebSearch, WebFetch
 ---

package/src/assets/skills/research-external/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: research-external
-description: External web research — find documentation, articles, and community knowledge with untrusted-data discipline
+description: External web research — docs, articles, community knowledge; untrusted data
 user-invocable: false
 allowed-tools: WebSearch, WebFetch
 ---

package/src/assets/skills/research-technology/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: research-technology
-description: Technology evaluation — assess libraries, frameworks, and tools against project requirements
+description: Technology evaluation — assess libraries, frameworks and tools against requirements
 user-invocable: false
 allowed-tools: WebSearch, WebFetch, Read
 ---

package/src/assets/skills/review-methodology/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: review-methodology
-description: This skill should be used when performing a code review to apply the standard 6-step review process.
+description: This skill should be used when performing a code review (the 6-step process).
 user-invocable: false
 allowed-tools: Read, Grep, Glob, Bash
 ---