cc-codeconductor 1.4.2 → 1.5.1

package/presets/codex/skills/cc-prototype/SKILL.md

@@ -15,11 +15,10 @@ Prototype request: $ARGUMENTS
 
 Command: `prototype` (fixed for this workflow — do not infer from user text)
 
-1. Run: `npx cc-codeconductor ccep parse --command prototype "$ARGUMENTS" --output json`
-2. Run: `npx cc-codeconductor ccep resolve --command prototype "$ARGUMENTS" --output json`
-3. Run: `npx cc-codeconductor ccep profile prototype --output json`
-4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command prototype --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
-5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+1. Run: `npx cc-codeconductor ccep profile prototype --output json` to get the phases and their roles.
+2. For each delegated phase, run: `npx cc-codeconductor ccep compile --command prototype --phase <phase-id> "$ARGUMENTS" --view prompt --output json`
+3. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command prototype --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+4. Pass each subagent only the compiled `prompt` for its phase — never forward raw `$ARGUMENTS` to planners.
 
 ---
 

package/presets/codex/skills/cc-refactor/SKILL.md

@@ -40,11 +40,10 @@ If coverage is insufficient:
 
 Command: `refactor` (fixed for this workflow — do not infer from user text)
 
-1. Run: `npx cc-codeconductor ccep parse --command refactor "$ARGUMENTS" --output json`
-2. Run: `npx cc-codeconductor ccep resolve --command refactor "$ARGUMENTS" --output json`
-3. Run: `npx cc-codeconductor ccep profile refactor --output json`
-4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command refactor --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
-5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+1. Run: `npx cc-codeconductor ccep profile refactor --output json` to get the phases and their roles.
+2. For each delegated phase, run: `npx cc-codeconductor ccep compile --command refactor --phase <phase-id> "$ARGUMENTS" --view prompt --output json`
+3. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command refactor --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+4. Pass each subagent only the compiled `prompt` for its phase — never forward raw `$ARGUMENTS` to planners.
 
 ---
 

package/presets/codex/skills/cc-review/SKILL.md

@@ -46,11 +46,10 @@ unavailable visual or emulator checks remain pending rather than claimed complet
 
 Command: `review` (fixed for this workflow — do not infer from user text)
 
-1. Run: `npx cc-codeconductor ccep parse --command review "$ARGUMENTS" --output json`
-2. Run: `npx cc-codeconductor ccep resolve --command review "$ARGUMENTS" --output json`
-3. Run: `npx cc-codeconductor ccep profile review --output json`
-4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command review --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
-5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+1. Run: `npx cc-codeconductor ccep profile review --output json` to get the phases and their roles.
+2. For each delegated phase, run: `npx cc-codeconductor ccep compile --command review --phase <phase-id> "$ARGUMENTS" --view prompt --output json`
+3. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command review --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+4. Pass each subagent only the compiled `prompt` for its phase — never forward raw `$ARGUMENTS` to planners.
 
 ---
 
@@ -116,6 +115,37 @@ Evaluate the diff against the following checklist:
 
 ---
 
+## Severity Rubric
+
+Classify every finding using these concrete anchors — not general judgment —
+so the same finding gets the same category on any run.
+
+**CRITICAL** (always):
+
+- Unauthenticated access to a protected resource
+- Injection (SQL, command, XSS) reachable from untrusted input
+- A secret or credential present in the diff
+- A destructive operation with no confirmation
+- The build or test suite is broken
+- A direct contradiction of an explicit acceptance criterion
+
+**WARNING**:
+
+- Missing test for a new branch or edge case
+- An error is silently swallowed — no log, no propagation
+- A change outside the declared scope
+- Inconsistent with an established pattern already in the module
+- Missing input validation in an internal function (not exposed at a trust boundary)
+
+**SUGGESTION**:
+
+- Style or naming
+- Minor readability
+- Speculative refactor that wasn't requested
+- Non-blocking micro-optimization
+
+---
+
 ## Step 3 — Review Report
 
 Produce a structured Review Report with findings in three categories:

package/presets/codex/skills/cc-scorecard/SKILL.md

@@ -17,11 +17,10 @@ Scope: $ARGUMENTS
 
 Command: `scorecard` (fixed for this workflow — do not infer from user text)
 
-1. Run: `npx cc-codeconductor ccep parse --command scorecard "$ARGUMENTS" --output json`
-2. Run: `npx cc-codeconductor ccep resolve --command scorecard "$ARGUMENTS" --output json`
-3. Run: `npx cc-codeconductor ccep profile scorecard --output json`
-4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command scorecard --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
-5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+1. Run: `npx cc-codeconductor ccep profile scorecard --output json` to get the phases and their roles.
+2. For each delegated phase, run: `npx cc-codeconductor ccep compile --command scorecard --phase <phase-id> "$ARGUMENTS" --view prompt --output json`
+3. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command scorecard --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+4. Pass each subagent only the compiled `prompt` for its phase — never forward raw `$ARGUMENTS` to planners.
 
 ---
 

package/presets/codex/skills/cc-security/SKILL.md

@@ -50,11 +50,10 @@ payloads, malware, or attack procedures.
 
 Command: `security` (fixed for this workflow — do not infer from user text)
 
-1. Run: `npx cc-codeconductor ccep parse --command security "$ARGUMENTS" --output json`
-2. Run: `npx cc-codeconductor ccep resolve --command security "$ARGUMENTS" --output json`
-3. Run: `npx cc-codeconductor ccep profile security --output json`
-4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command security --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
-5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+1. Run: `npx cc-codeconductor ccep profile security --output json` to get the phases and their roles.
+2. For each delegated phase, run: `npx cc-codeconductor ccep compile --command security --phase <phase-id> "$ARGUMENTS" --view prompt --output json`
+3. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command security --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+4. Pass each subagent only the compiled `prompt` for its phase — never forward raw `$ARGUMENTS` to planners.
    Canonical delivery order is test-before-implement whenever both phases apply.
 
 ---
@@ -65,7 +64,7 @@ If `graphify-out/graph.json` exists, run `graphify query "$ARGUMENTS"` (and
 `graphify path` / `graphify explain` when needed). Then invoke `repo-explorer`
 to map modules, conventions, and impact radius. Do not write code in this step.
 Record a Repo Map artifact before intake. Load the matching `security-*` skill
-for the named domain (see `.claude/skills/security-*/SKILL.md`). Keep the OWASP
+for the named domain (see `.codex/skills/security-*/SKILL.md`). Keep the OWASP
 `security` skill for application-security reviews.
 
 ---

package/presets/codex/skills/cc-spec-mutation/SKILL.md

@@ -24,11 +24,10 @@ Describe what behavior you want to implement. Include:
 
 Command: `spec-mutation` (fixed for this workflow — do not infer from user text)
 
-1. Run: `npx cc-codeconductor ccep parse --command spec-mutation "$ARGUMENTS" --output json`
-2. Run: `npx cc-codeconductor ccep resolve --command spec-mutation "$ARGUMENTS" --output json`
-3. Run: `npx cc-codeconductor ccep profile spec-mutation --output json`
-4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command spec-mutation --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
-5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+1. Run: `npx cc-codeconductor ccep profile spec-mutation --output json` to get the phases and their roles.
+2. For each delegated phase, run: `npx cc-codeconductor ccep compile --command spec-mutation --phase <phase-id> "$ARGUMENTS" --view prompt --output json`
+3. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command spec-mutation --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+4. Pass each subagent only the compiled `prompt` for its phase — never forward raw `$ARGUMENTS` to planners.
    Canonical delivery order is test-before-implement whenever both phases apply.
 
 ---

package/presets/codex/skills/cc-tdd-cycle/SKILL.md

@@ -24,11 +24,10 @@ Describe what behavior you want to implement. Include:
 
 Command: `tdd-cycle` (fixed for this workflow — do not infer from user text)
 
-1. Run: `npx cc-codeconductor ccep parse --command tdd-cycle "$ARGUMENTS" --output json`
-2. Run: `npx cc-codeconductor ccep resolve --command tdd-cycle "$ARGUMENTS" --output json`
-3. Run: `npx cc-codeconductor ccep profile tdd-cycle --output json`
-4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command tdd-cycle --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
-5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+1. Run: `npx cc-codeconductor ccep profile tdd-cycle --output json` to get the phases and their roles.
+2. For each delegated phase, run: `npx cc-codeconductor ccep compile --command tdd-cycle --phase <phase-id> "$ARGUMENTS" --view prompt --output json`
+3. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command tdd-cycle --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+4. Pass each subagent only the compiled `prompt` for its phase — never forward raw `$ARGUMENTS` to planners.
    Canonical delivery order is test-before-implement whenever both phases apply.
 
 ---

package/presets/codex/skills/cc-test-plan/SKILL.md

@@ -27,11 +27,10 @@ proceeding.
 
 Command: `test-plan` (fixed for this workflow — do not infer from user text)
 
-1. Run: `npx cc-codeconductor ccep parse --command test-plan "$ARGUMENTS" --output json`
-2. Run: `npx cc-codeconductor ccep resolve --command test-plan "$ARGUMENTS" --output json`
-3. Run: `npx cc-codeconductor ccep profile test-plan --output json`
-4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command test-plan --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
-5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+1. Run: `npx cc-codeconductor ccep profile test-plan --output json` to get the phases and their roles.
+2. For each delegated phase, run: `npx cc-codeconductor ccep compile --command test-plan --phase <phase-id> "$ARGUMENTS" --view prompt --output json`
+3. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command test-plan --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+4. Pass each subagent only the compiled `prompt` for its phase — never forward raw `$ARGUMENTS` to planners.
 
 ---
 

package/presets/codex/skills/cc-triage/SKILL.md

@@ -15,11 +15,10 @@ Triage request: $ARGUMENTS
 
 Command: `triage` (fixed for this workflow — do not infer from user text)
 
-1. Run: `npx cc-codeconductor ccep parse --command triage "$ARGUMENTS" --output json`
-2. Run: `npx cc-codeconductor ccep resolve --command triage "$ARGUMENTS" --output json`
-3. Run: `npx cc-codeconductor ccep profile triage --output json`
-4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command triage --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
-5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+1. Run: `npx cc-codeconductor ccep profile triage --output json` to get the phases and their roles.
+2. For each delegated phase, run: `npx cc-codeconductor ccep compile --command triage --phase <phase-id> "$ARGUMENTS" --view prompt --output json`
+3. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command triage --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+4. Pass each subagent only the compiled `prompt` for its phase — never forward raw `$ARGUMENTS` to planners.
 
 ---
 

package/presets/codex/skills/code-review/SKILL.md

@@ -0,0 +1,207 @@
+---
+id: code-review
+name: code-review
+description: >
+  Provides a structured framework for conducting thorough code reviews covering correctness, security, architecture alignment, performance, and technical debt.
+
+user-invokable: true
+license: MIT
+metadata:
+  author: lgzarturo
+  category: review
+
+compatibility:
+  tools: [claude, codex, gemini, agy, opencode]
+  stacks:
+    languages: []
+    frameworks: []
+
+risk:
+  level: low
+  can_execute_shell: false
+  can_modify_files: true
+  requires_network: false
+
+inputs: []
+
+outputs: []
+
+quality:
+  reviewed_by: codeconductor-core
+  version: 0.1.0
+---
+
+
+
+# Code Review
+
+## Review Axes
+
+Every finding must reference exactly one axis. This prevents vague feedback and
+makes it actionable.
+
+| Axis | What to check |
+|------|--------------|
+| **Correctness** | Does the logic handle all cases in the acceptance criteria? |
+| **Security** | Injection vectors, secret exposure, auth bypasses, insecure defaults |
+| **Architecture** | Does the code follow existing patterns and module boundaries? |
+| **Performance** | N+1 queries, unnecessary allocations, blocking I/O in hot paths |
+| **Error handling** | Are failure cases handled explicitly and safely? |
+| **Test coverage** | Do tests verify the acceptance criteria, not just happy paths? |
+| **Scope** | Are there changes outside the stated task boundary? |
+| **Technical debt** | Does the implementation introduce debt without acknowledging it? |
+
+## Finding Categories
+
+### CRITICAL — must be resolved before merge
+
+- Logic failures that violate acceptance criteria
+- Security vulnerabilities (injection, auth bypass, secret exposure)
+- Data loss or corruption risk
+- Breaking changes to public API or shared contracts
+- Missing error handling that causes silent failures
+
+### WARNING — should be resolved before merge
+
+- Missing edge case coverage in tests
+- Scope creep (changes outside the task boundary)
+- Pattern inconsistency that will confuse future maintainers
+- Performance issue that will degrade under load
+- Missing input validation at system boundaries
+
+### SUGGESTION — optional improvement
+
+- Naming clarity improvements
+- Extracting a reusable abstraction
+- Test readability
+- Documentation gaps on non-obvious behavior
+
+## Review Report Format
+
+```markdown
+## Review Report
+
+**Task**: [objective from task card]
+**Verdict**: [approved | approved with warnings | blocked]
+
+---
+
+### CRITICAL
+
+- [ ] [C1] `path/to/file:line` — [description]
+  Axis: [axis] | Evidence: `[quoted code]` | Required action: [what must change]
+
+_(none)_ if no critical findings
+
+### WARNING
+
+- [ ] [W1] `path/to/file:line` — [description]
+  Axis: [axis] | Recommended action: [what should change]
+
+_(none)_ if no warning findings
+
+### SUGGESTION
+
+- [ ] [S1] — [description] | Rationale: [brief reason]
+
+_(none)_ if no suggestions
+
+### Summary
+
+- Critical: [count] | Warning: [count] | Suggestion: [count]
+- **Verdict justification**: [one sentence]
+```
+
+**Verdict rules:**
+
+- `blocked` — any CRITICAL finding present
+- `approved with warnings` — no CRITICAL, at least one WARNING
+- `approved` — no CRITICAL, no WARNING
+
+## What to Check — by Axis
+
+### Correctness
+
+- Does every acceptance criterion have a corresponding code path?
+- Are null/empty/zero values handled explicitly?
+- Are boundary conditions checked (off-by-one, empty collections, max values)?
+- Do conditional branches cover all cases (exhaustive when/switch)?
+
+### Security
+
+```text
+Injection: SQL, command, LDAP, XML — is input sanitized or parameterized?
+Auth: is the endpoint protected? are role checks correct?
+Secrets: no hardcoded credentials, tokens, or keys in source
+Headers: are security headers set (CSP, HSTS, X-Frame-Options)?
+CORS: is the origin whitelist explicit, not wildcard?
+Dependencies: are new dependencies from trusted sources?
+```
+
+### Performance
+
+```text
+N+1 queries: does a loop call the database per iteration?
+Eager loading: are JOINs or includes used where needed?
+Pagination: are all list endpoints paginated?
+Caching: is expensive computation cached at an appropriate layer?
+Index: do new query filters have corresponding DB indexes?
+```
+
+### Error Handling
+
+```text
+Are exceptions caught at the right layer (not swallowed silently)?
+Is the error response format consistent with the rest of the API?
+Is the original exception logged before translating to a user-facing error?
+Are transient failures retried with backoff, or propagated immediately?
+```
+
+## What NOT to Flag
+
+**Personal style preferences.** If the code follows the project's established
+conventions, do not flag it because you would have written it differently.
+
+**Trivial naming.** Variable names are a SUGGESTION at most, never a WARNING.
+Do not block a PR over naming unless the name is genuinely misleading.
+
+**Tests for trivial code.** Do not demand tests for getters, setters, or data
+class construction. Test behavior, not boilerplate.
+
+**Refactors not in scope.** If you notice an improvement opportunity outside
+the task boundary, log it as a SUGGESTION. Do not block the PR for work that
+was not requested.
+
+**Framework defaults.** Do not second-guess framework conventions (Spring
+dependency injection, Next.js file-based routing). Trust the framework.
+
+## Exact Diff Recommendations
+
+When a finding requires a code change, provide the exact replacement:
+
+```text
+# Current code (path/to/file:42)
+val user = userRepository.findById(id)
+return user.name   // NPE if not found
+
+# Recommended fix
+val user = userRepository.findById(id)
+  ?: throw NotFoundException("User $id not found")
+return user.name
+```
+
+Vague instructions ("handle the null case") force the author to guess your
+intent. Exact diffs remove ambiguity and speed up the review cycle.
+
+## Prioritization Order
+
+When multiple findings exist, address them in this order:
+
+1. Security — security issues can silently compromise users or data
+2. Correctness — broken behavior defeats the purpose of the change
+3. Error handling — silent failures are hard to debug in production
+4. Test coverage — gaps mean regressions will be invisible
+5. Performance — degrade gradually; fix before it causes incidents
+6. Architecture — inconsistency compounds over time
+7. Technical debt — acknowledge and track; do not always block for it
+8. Suggestions — apply at author's discretion

package/presets/codex/skills/django-orm/SKILL.md

@@ -1,6 +1,6 @@
 ---
 id: django-orm
-name: Django ORM
+name: django-orm
 description: >
   Django ORM patterns for multi-tenant POS projects: efficient queries,
   bulk operations, transactions, and multi-schema upload paths.

package/presets/codex/skills/django-testing/SKILL.md

@@ -1,6 +1,6 @@
 ---
 id: django-testing
-name: Django Testing
+name: django-testing
 description: >
   Testing patterns for multi-tenant Django POS projects using pytest-django,
   RequestFactory, and mocks. No factories, no complex conftest.