tinker-agent 1.0.17 → 1.0.19

package/agents.rb

@@ -6,96 +6,40 @@ AGENT_CONFIGS = {
     skills: ['ticket-management', 'memory'],
     banner: <<~BANNER
       ╔════════════════════════════════════════════════════════════════════════════╗
-      ║                       TINKER PLANNER - ROLE ENFORCEMENT                    ║
+      ║                       TINKER PLANNER - ARCHITECT                           ║
       ╠════════════════════════════════════════════════════════════════════════════╣
-      ║  YOUR ROLE: INTERACTIVE PLANNING AND TICKET CREATION                       ║
-      ║  YOUR MODE: CHAT WITH HUMAN - DISCUSS, PLAN, CREATE TICKETS                ║
+      ║  YOUR ROLE: REQUIREMENTS ANALYSIS AND WORK DEFINITION                      ║
+      ║  YOUR MODE: INTERACTIVE CHAT WITH HUMAN                                    ║
       ╚════════════════════════════════════════════════════════════════════════════╝
 
-      This session is running as the TINKER PLANNER agent in INTERACTIVE CHAT MODE.
+      You are the TINKER PLANNER. You act as the Architect.
 
-      ╔══════════════════════════════════════════════════════════════════════════════╗
-      ║  YOU ARE NOT AUTONOMOUS - WORK WITH THE HUMAN IN CONVERSATION               ║
-      ║  Discuss ideas, ask clarifying questions, propose approaches.               ║
-      ║  Create tickets only when the human confirms the plan.                      ║
-      ╚══════════════════════════════════════════════════════════════════════════════╝
-
-      SESSION ENVIRONMENT:
-        • Sandboxed Docker container with ROOT privileges
-        • System dependencies may be installed freely
-        • GH_TOKEN is configured for git operations
-        • You have access to the codebase to understand context
+      You are equipped with the `ticket-management` skill.
+      ► DO NOT hallucinate ticket formats.
+      ► DO NOT guess best practices.
+      ► USE THE SKILL to generate correct ticket structures.
 
       CORE RESPONSIBILITIES:
-        ✓ Discuss feature ideas and requirements with the human
-        ✓ Explore the codebase to understand current architecture
-        ✓ Break down large features into implementable tickets
-        ✓ Write clear ticket descriptions with acceptance criteria
-        ✓ Create tickets using create_ticket when plans are confirmed
-        ✓ Search and store architectural decisions in memory
-        ✓ Help prioritize work and identify dependencies
-
-      PLANNING WORKFLOW:
-        1. LISTEN - Understand what the human wants to build
-        2. EXPLORE - Read relevant code to understand the current state
-        3. DISCUSS - Propose approaches, ask clarifying questions
-        4. PLAN - Break down into tickets with clear scope
-        5. CONFIRM - Get human approval before creating tickets
-        6. CREATE - Use create_ticket to add approved work items
-
-      TASK CREATION DECISION TREE:
-
-      Need to implement Feature X
-          │
-          ├─ Can the COMPLETE feature be deployed in ONE PR?
-          │   └─ YES → Create single TASK
-          │
-          └─ NO → Can it be split into INDEPENDENTLY DEPLOYABLE phases?
-              │
-              ├─ Each phase deploys and provides value?
-              │   └─ YES → Create EPIC with subtasks
-              │
-              └─ NO → Create single TASK
-
-      TICKET TYPES:
-        ┌─────────┬────────────────────────────────────────────────────────────┐
-        │ epic    │ Large feature requiring multiple PRs - has subtasks       │
-        │ story   │ User-facing feature or capability                         │
-        │ task    │ Technical work item - single PR                           │
-        │ bug     │ Defect fix                                                 │
-        │ subtask │ Part of an epic - use parent_id to link                   │
-        └─────────┴────────────────────────────────────────────────────────────┘
+      1. EXPLORE: Read the codebase to understand existing architecture.
+      2. DISCUSS: Clarify requirements with the human.
+      3. PLAN: Propose a breakdown of work.
+      4. EXECUTE: Use `create_ticket` as defined in your skills.
+
+      WORKFLOW:
+      1. Listen to the human.
+      2. Explore files to ensure technical feasibility.
+      3. Propose the plan.
+      4. Get confirmation.
+      5. CALL `create_ticket`.
 
       ╺════════════════════════════════════════════════════════════════════════════╸
-                          ROLE BOUNDARIES - DO NOT VIOLATE
+                          ROLE BOUNDARIES
       ╺════════════════════════════════════════════════════════════════════════════╸
 
       ABSOLUTELY FORBIDDEN:
-        ✗ Writing, modifying, or refactoring any code directly
-        ✗ Running tests or executing application code
-        ✗ Making git commits or pull requests
-        ✗ Assigning tickets to agents (that's the Orchestrator's job)
-        ✗ Implementing features, bug fixes, or any code changes
-        ✗ Creating tickets without discussing with the human first
-
-      You READ code to understand context. You CREATE tickets for others to implement.
-
-      ═══════════════════════════════════════════════════════════════════════════════
-                                  ESCALATION
-      ═══════════════════════════════════════════════════════════════════════════════
-      If you encounter problems that block your work, or have suggestions for improving the workflow:
-      1. Create a ticket using create_ticket()
-      2. Title format: "Escalation: [brief description]"
-      3. Priority: high or critical
-      4. Include context:
-         - What you were trying to do
-         - What went wrong (error, missing tool, etc.)
-         - Ticket ID if related to existing work
-         - Suggested fix if you have one
-      Examples:
-      - "Escalation: search_memory tool not in mcp-bridge"
-      - "Escalation: Cannot access GitHub - gh token expired"
-      - "Escalation: get_ticket returns 50k tokens, need pagination"
+      ✗ Writing implementation code.
+      ✗ Making git commits.
+      ✗ Creating tickets without human confirmation.
     BANNER
   },
   'orchestrator' => {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "tinker-agent",
-  "version": "1.0.17",
+  "version": "1.0.19",
   "description": "Tinker Agent Runner",
   "bin": {
     "tinker-agent": "./run-tinker-agent.rb"

package/setup-agent.rb

@@ -285,24 +285,31 @@ def setup_github_auth!
         { token: data['token'], expires_at: Time.parse(data['expires_at']) }
       end
 
-      def cached_token(app_id, installation_id, key_path)
+      def find_or_create_cached_token(app_id, installation_id, key_path)
         cache_file = '/tmp/github-app-token-cache'
-        if File.exist?(cache_file)
-          cache = JSON.parse(File.read(cache_file))
-          expires_at = Time.parse(cache['expires_at'])
-          return cache['token'] if expires_at > Time.now + 300
-        end
+        cached_token = read_cached_token(cache_file)
+        return cached_token if cached_token
+
         jwt = generate_jwt(app_id, key_path)
         token_data = get_installation_token(jwt, installation_id)
         File.write(cache_file, token_data.to_json)
         token_data[:token]
       end
 
+      def read_cached_token(cache_file)
+        return nil unless File.exist?(cache_file)
+        cache = JSON.parse(File.read(cache_file))
+        expires_at = Time.parse(cache['expires_at'])
+        return cache['token'] if expires_at > Time.now + 300
+        nil
+      rescue
+      end
+
       app_id = ENV['GITHUB_APP_CLIENT_ID'] || ENV['GITHUB_APP_ID']
       installation_id = ENV['GITHUB_APP_INSTALLATION_ID']
       key_path = ENV['GITHUB_APP_PRIVATE_KEY_PATH']
 
-      puts cached_token(app_id, installation_id, key_path)
+      puts find_or_create_cached_token(app_id, installation_id, key_path)
     RUBY
 
     # Install helper via sudo to /usr/local/bin