Origami Assessment Playbook

Origami Assessment Playbook

Purpose: Run your own origami plot self-assessment and calibrate your scores interactively. Time required: ~15–20 minutes Frequency: As part of your 360 review, or quarterly as a self-check between cycles. Related: Origami Framework

---

Overview

The assessment has three phases:

1. Data collection and scoring — automated by the /origami skill
2. Interactive calibration — you review each domain score and adjust based on context the data might miss
3. Growth targets — identify where to push next

---

How to Run It

Open Claude Code in the team-pulse repo and run:

/origami yourname

Pass your GitHub username or name as the argument. If you leave it blank, it detects from git config user.name.

What the skill does

1. Ensures the database is up to date — pulls from the team-pulse SQLite database, running extraction if needed
2. Identifies you and your aliases — resolves your GitHub handles via config/identity-map.yaml
3. Sets the assessment period to the most recent completed quarter
4. Queries your data — commits, PRs, issues authored, issues assigned, PR reviews
5. Classifies your work into the 6 domains, asking for each item:
   • Was this assigned or self-generated?
   • Reactive or proactive?
   • Individual or team impact?
   • Does it show domain knowledge?
6. Scores each domain (1–4) using sustained patterns (3+ instances), not one-offs
7. Writes an initial assessment with an origami plot to origami-assessments/

Interactive calibration

After the initial assessment, the skill walks you through each domain one at a time:

• Shows you the score and the evidence behind it
• Asks whether you agree or disagree, and why
• Pushes back with evidence if the data supports the score, or adjusts if your reasoning is sound
• Records your response and any adjusted score

The data-driven scores are never overwritten — they stay as the automated baseline. Your calibration goes in a separate section.

Output

The skill produces:

• Markdown assessment: origami-assessments/[firstname-lastname_YYYY-QN].md
• Initial SVG chart: origami-assessments/[firstname-lastname_YYYY-QN]_initial.svg
• Calibrated SVG chart: origami-assessments/[firstname-lastname_YYYY-QN]_calibrated.svg

The final file includes a calibrated results table, growth targets, and a starfish self-eval for the domains you most want to grow in.

---

Scoring Decision Tree

For each domain, the skill asks these questions in order:

Q1: Do you complete assigned work in this domain reliably?

• Not consistently → Score 1 (Following) — but consider whether you’ve had opportunity
• Yes → at least 1, continue

Q2: Do you find and fix problems in this domain without being assigned tickets?

• No, only assigned tickets → Score 1 (Following)
• Yes, self-author issues or pick up unassigned work → at least 2 (Owning), continue

Q3: Does your work in this domain multiply the team — preventing classes of problems, setting standards others follow, or generating work streams for others?

• No, self-directed work benefits mainly your own output → Score 2 (Owning)
• Yes, create reusable mechanisms or review others’ work with depth → at least 3 (Driving), continue

Q4: Do you define the team’s approach in this domain — writing the methodology, making strategic decisions about direction?

• No, drive standards within the existing approach → Score 3 (Driving)
• Yes, shape how the team thinks about this domain → Score 4 (Shaping)

Tiebreaker guidance

• Ticket authorship ratio matters. If most of your work in a domain is self-authored, that’s a signal to round up. If mostly assigned, round down.
• One-off behaviors don’t define a level. Look for 3+ instances over the assessment period.
• The “(emerging)” qualifier. If you show a clear growth signal but it’s not yet a pattern, note the score as “2 (emerging)” to flag it for next time.

---

Domain-Specific Scoring Notes

Engineering Craft: Score based on complexity, independence, and soundness — not volume. One complex feature you scoped yourself, with sound architecture and no security issues, scores higher than five features from detailed specs.

Infrastructure & Quality Systems: LOC metrics dramatically undercount this domain. A 10-line Cloudflare config change can be higher-impact than a 1000-line feature. Score based on ownership and judgment, not volume.

Domain Knowledge: The hardest domain to score from data alone. Look for: PR descriptions that explain why (not just what), correct domain modeling decisions, pushback on specs that misunderstand the business, Sentry tickets filed because you understood the expected behavior. This is where calibration matters most.

Decomposition: The question is authorship and quality of breakdown. Implementing phases from someone else’s spec = 1. Writing phase breakdowns of a vague requirement = 2. Writing the spec that defines work for others = 3. Creating the spec process = 4.

Team Systems: The rarest domain for high scores. Most engineers score 1. Look for: proposing measurements, identifying team bottlenecks, designing workflows that change how others work, evaluating tools strategically.

Peer Development: Review count is necessary but not sufficient. High count + substantive feedback = 3. High count + post-merge review pipeline + evidence of others growing from the interaction = 3–4. Low count regardless of quality = 1.

---

Using Your Assessment

For 360 reviews

Bring your calibrated assessment to your 360 review. It gives your consent and advice stakeholders a structured view of how you see your own contributions, and a starting point for discussion.

As a quarterly self-check

Between 360 cycles, run /origami to track your own trajectory. Compare quarter over quarter: are your growth signals becoming sustained patterns? Are you expanding into new domains or deepening existing ones?

Starfish format for growth conversations

For the domains you most want to grow in, the assessment includes a starfish:

• Keep doing: Behaviors that are working
• More of: Growth signals to lean into
• Less of: Habits not serving you at the next level
• Stop: Patterns that hold you back
• Start: Specific new behaviors to try this quarter

This separates the conversation about growth from the assessment of level. The origami plot shows where you are. The starfish shows where you’re going.

---

Important Notes

• The data-driven scores are never modified after initial write. They’re the automated baseline. Calibration goes in the self-calibration section.
• Scores describe what levels look like, not what to target. Don’t game the rubric.
• One-off behaviors don’t count. 3+ instances over the assessment period.
• Domain Knowledge is hardest to score from data. Be honest about what you know vs. what the code shows.
• The goal is an accurate shape, not a high score.