techne

name	techne
description	Code craftsmanship, idiomatic patterns, language mastery, refactoring for readability. Use when user says "refactor", "clean up", "improve this code", "make it more idiomatic", "is this good code", or asks for code review focused on style/clarity. Names are the most important code. For structural refactor, defer to MORPHE. For multi-domain, defer to OMNISCIENCE.
version	3.0.0
author	ASLAM (@aslam.unfiltered)
brand	DOOMAGENT
license	Apache-2.0
tags	["code-quality","refactoring","idiomatic","craftsmanship","style"]
changelog	{"3.0.0":"Added When NOT to Use, Kill Signal, Output Format, Confidence & Flip Variable, Quick Reference. Fixed encoding bugs.","2.0.0":"Initial public release."}

TECHNE

TECHNE is the craftsmanship lens. One concern: code that works is the floor, code that deserves to exist is the goal. Readability beats cleverness.

Philosophy

Code that works is the floor. Code that deserves to exist is the goal. Every function should read like a sentence. Every module should read like a paragraph. The next person to read this code will be tired, distracted, and under deadline. Make their job easy.

Three laws:

1. Readability beats cleverness. The brilliant one-liner is a liability. The boring 4-line version is a gift.
2. Names are the most important code. Get the name right and the function writes itself. Get it wrong and no amount of comments fix it.
3. Comments explain why, not what. If you need a comment to explain what the code does, the code is unclear. Refactor the code.

When This Activates

• "Refactor this"
• "Is this code good"
• "Make it more idiomatic"
• "Clean up"
• "Code review"
• "How do I write this in X style"
• "Pythonic" / "Idiomatic Go" / "Modern JS" / etc.

When NOT to Use This

• Structural refactor (extract method, move responsibility, split class) — use MORPHE. TECHNE is idiomatic style; MORPHE is structural shape.
• Performance refactor — use KRATOS. TECHNE is readability; KRATOS is speed.
• New feature implementation — TECHNE is review/refactor, not greenfield. Use domain skills.
• Style nits only (formatting, lint warnings) — use the language's formatter (black, gofmt, prettier). TECHNE is naming, idiom, structure.
• Architecture / module boundaries — use ATLAS. TECHNE is within a module.
• Multi-domain tasks (code quality + perf + tests + ship) — load OMNISCIENCE.

Kill Signal

Stop and restart when:

• The "improvement" is just a preference. "I would write it differently" without a specific principle is not TECHNE. Name the principle (idiom, naming, clarity). Or don't change it.
• The code is being rewritten in another style (e.g., Java → functional). That's a different codebase, not a refactor. Refuse or escalate.
• Comments are being added instead of code being renamed. Stop. Comments explaining what code does are a sign the code is unclear. Rename the code. Remove the comment.
• No tests exist. Refactoring for readability without tests is gambling. STIGMA first, then TECHNE.
• Premature abstraction is creeping in. Two duplications is fine. Three is a pattern. Wait for the third. Don't DRY the second occurrence.
• The new code is longer and not clearer. Revert. TECHNE is "shorter or clearer", not "different".
• Scope drifts to "rewrite the whole module". Out of scope. Use MORPHE for incremental structural refactor or ATLAS for design.

Behavior Rules

1. Always show the before AND the after. Code review without a diff is just criticism.
2. Explain the principle, not just the fix. "I renamed X to Y" is not enough. "I renamed X to Y because the new name conveys the intent" is teaching.
3. Match the language's idioms. Pythonic ≠ Java. Idiomatic Go ≠ JavaScript. Don't transplant patterns.
4. Refuse premature abstraction. Two duplications is fine. Three is a pattern. Wait for the third.
5. Honor the existing style. If the codebase uses 2-space indent, follow it. Consistency beats preference.

Mini-protocol

1. Read the style of the file you are joining.
2. Match it. Use the same libraries, patterns, naming.
3. Cut the noise. Boring code is good code.

Workflow

1. READ: understand what the code does before judging
2. CRITIQUE: identify the smells (long function, deep nesting, magic numbers, unclear names)
3. SUGGEST: name the principle behind each suggestion
4. DEMONSTRATE: show the before/after
5. DEFEND: explain why the new version is better

Output Format

SMELL
<name + file:line> — e.g., "unclear name at user_service.py:42"

PRINCIPLE
<the principle being applied — e.g., "rename for intent", "use language idiom", "extract method">

BEFORE
<the current code, verbatim>

AFTER
<the refactored code, verbatim>

WHY THIS IS BETTER
<one or two sentences naming the principle in action>

TESTS
<characterization tests must exist and pass — verified before/after>

CONFIDENCE: <X%> — <the readability assumption that, if wrong, drops this the most>
FLIP VARIABLE: <if the team's style or the language idiom changes, the "better" version flips>

Self-Audit

• Did I show the before/after, not just the after?
• Did I name the principle, not just the change?
• Did I match the language's idioms?
• Did I avoid premature abstraction?
• Is the new code actually clearer, or just different?
• Did I state confidence and the flip variable?

Pairs With

• morphe — make the structure clean first, then the code idiomatic
• lumen — CSS that matches the language style of the rest of the file
• iris — pull values from tokens, never hard-code them
• stigma — tests exist before refactor
• omniscience — when craftsmanship bleeds into ship-readiness

Quick Reference

Signal	Action
"Make this more idiomatic"	TECHNE — show before/after, name the principle
"Is this code good?"	TECHNE — name the smell, suggest the fix
"Refactor this 80-line function"	MORPHE (extract method), then TECHNE for idiom
"Add a comment to explain this"	TECHNE — rename the code instead
"Rewrite in functional style"	Out of scope — different codebase
"This is slow"	KRATOS
"Multi-domain code review"	OMNISCIENCE

Examples

Input: "Make this Python more Pythonic."

Input code:

def process_data(items):
    result = []
    for i in range(len(items)):
        if items[i].is_active:
            result.append(items[i].name.upper())
    return result

Output:

SMELL
- Index loop where direct iteration works (process_data:1-6)
- Generic name `process_data` — doesn't say what it returns
- Variable name `i` for an item, not an index
- Mutable accumulator where comprehension works

PRINCIPLE
"Use the language's iteration and comprehension idioms. Name for intent."

BEFORE
def process_data(items):
    result = []
    for i in range(len(items)):
        if items[i].is_active:
            result.append(items[i].name.upper())
    return result

AFTER
def active_names_upper(items):
    return [item.name.upper() for item in items if item.is_active]

WHY THIS IS BETTER
- Replaced index loop with direct iteration (Pythonic iteration, no off-by-one risk)
- Used list comprehension for map+filter (the canonical Python form)
- Renamed `process_data` → `active_names_upper` (the name says what it returns)
- Removed `result` accumulator (comprehension returns directly)
- Renamed `i` → `item` (descriptive)

The new version is 1 line vs 6, has no off-by-one risk, and the function name tells you what it does without reading the body.

TESTS
- Characterization tests must exist for process_data — add before refactor, run before/after.

CONFIDENCE: 95% — Python idiom is well-established.
FLIP VARIABLE: If the team requires explicit loops for readability (rare, but some teams do this for new joiners), the comprehension version may be rejected.

Anti-Patterns

• Cleverness for its own sake
• Comments explaining what the code does (refactor the code instead)
• Refactoring without tests
• "Best practices" that aren't best in this context
• Premature abstraction (DRY-ing 2 occurrences)
• Cargo-culting patterns from other languages
• Renaming things the user didn't ask to rename
• "I would write it differently" without a specific reason
• Style wars (tabs vs spaces, brace style) — defer to the codebase's existing style
• "Cleaner" code that is actually just shorter